[Feature Request] MCU ID to prevent possibly dangerous configuration mismatch

Features
1

The concept: Create an MCU ID string that will be added to the board Firmware when it is compiled.
The ID would be matched to a variable string defined in the MCU configuration in printer.cfg on startup.
If the ID reported by the MCU on connection by the host does not match the configuration string klipper will shut down the MCU.

Reason: As demonstrated by Nero3d with the Sonic Pad recently some boards are close enough in design that a configuration intended for another manufactures board may unintentionally start and run in a dangerous configuration. In Neros case the Sonic Pad was shipped with a default configuration for a Creality printer unknown to him at the time. He had connected the sonic pad to an MKS Robin board that had already been configured for Klipper. The Creality silent board and the MKS Robin were close enough in design that Klipper was able to connect and run with the MKS board. Due to pin differences in the 2 systems the Creality configuration pulled pin PC3 high for an endstop. The MKS Robin uses PC3 for the hotend heater… That difference combined with the Creality thermistor pins being tied to a display in the MKS Robin lead to a dangerous thermal runaway condition.

Solution:
An MCU ID would be defined by the user during the makmenuconfig operation and incorporated into the compiled firmware.

A matching field would be added into the printer.cfg MCU definition
Possible Example

[mcu]
serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
mcuid:skrpico

On startup when the host connects to the MCU it will retrieve the MCU ID compiled in the firmware and compare it to the MCU ID string defined in the MCU config fie. If the MCU IDs do not match Klipper will post an error and not proceed with enabling any pin definitions.

2

It sounds like a good case for adding bench testing and setup before installing a controller board to the documentation.

Most boards, if tested at the manufacturer, will have some kind of firmware currently on the control board.

3

This sounds like another Darwin Award.
IMO you cannot foresee everything and adding unneeded complexity all over the place for some edge cases makes no sense at all.

4

This is 110% on creality, for starting up klipper with a unknown config without a single confirmation dialog. That’s just plain lazy on their part… Slappin someone elses work into box as quickly as possible to capitalize on the pi shortage. The fact that klipper is so flexible with hardware configurations is a huge feature, not a safety problem.

PS - Its gonna be fun getting OS updates in 2 yrs for these tablets. I’m sure that creality will keep putting out high quality tested updates such as these well into future. (This shade applies to all the printer vendor pi clones)

5

The name klipper generates is already unique isn’t it? For example the serial name for one of my boards is /dev/serial/by-id/usb-Klipper_stm32h723xx_17000F001551303531313638-if00 with 17000F001551303531313638 being the unique part (I assume some sort of hash).

Is creality just taking the first part and automatically updating the config with the full serial port without any sort of user interaction? If so that’s really dumb on their parts and it’s no surprise there were issues.

6
7

Sineos - I didn’t notice the knowledge base before. Great information - the architecture diagram is very useful! Thank you!

1 Like