# Secondary MCU (for display) Works on Boot, Fails on FIRMWARE\_RESTART **URL:** \ **Category:** General Discussion\ **Created:** [December 18, 2022, 10:41pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440 "2022-12-18T22:41:10Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![adawalli](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@adawalli](https://klipper.discourse.group/u/adawalli)\ **Post date:** [December 18, 2022, 10:41pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/1 "2022-12-18T22:41:10Z")
### Basic Information: Printer Model: Voron v0.1 MCU / Printerboard: Primary MCU: SKR E3 v2.0 Secondary MCU (display): based on STM32F042 `klippy.log` ### Describe your issue: I have a secondary MCU (you can find it described as “mcu display” [klippy 2.log.zip](https://klipper.discourse.group/uploads/short-url/yPoWYO5J6cYE0RfKSvF4D36uZIE.zip) (1.1 MB) ). This works great on fresh powerup. however, if I issue a FIRMWARE\_RESTART, I believe it is failing the “COMMAND” restart and becomes unresponsive until I pull the USB cable (power provided this way as well) for the display and plug it back in - now, a FIRMWARE\_RESTART works as intended ---
**Author:** ![fwiffo](https://avatars.discourse-cdn.com/v4/letter/f/c37758/32.png) [@fwiffo](https://klipper.discourse.group/u/fwiffo)\ **Post date:** [December 20, 2022, 8:06pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/2 "2022-12-20T20:06:07Z")
I have the same problem. Using a restart\_method of “rpi\_usb” (Raspberry Pi 3B+) has the same problem as “command”. It’s also not 100% consistent for me; sometimes it resets just fine. As a workaround, I’m going to _try_ using uhubctl to power cycle the display external to klipper next time this happens. ---
**Author:** ![adawalli](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@adawalli](https://klipper.discourse.group/u/adawalli)\ **Post date:** [December 20, 2022, 8:14pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/3 "2022-12-20T20:14:38Z")
I have never heard of the “uhubctl” project, but I am definitely interested. Thanks for letting me know. I wish I could submit a proper bug report on klipper github, but we can’t do that anymore… **UPDATE** Unfortunately, this technique does not work for raspberry pi zero. ---
**Author:** ![fwiffo](https://avatars.discourse-cdn.com/v4/letter/f/c37758/32.png) [@fwiffo](https://klipper.discourse.group/u/fwiffo)\ **Post date:** [December 23, 2022, 6:06am UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/4 "2022-12-23T06:06:41Z")
As a follow-up to this, uhubctl _did_ work when I got in this situation again. I does let you power-cycle a USB port, which is basically a nicer version of the same workaround. The tool only works with some models of Raspberry Pi, and some “smart” USB hubs. I’ve also now had this happen to a Klipper Expander secondary MCU as well, so I don’t think it’s just a thing with that particular display. Next time it happens, if I have time, I will try to get more diagnostic info because the device does seem to be in some sort of wedged state. It only seems to happen when I don’t want it to. ---
**Author:** ![adawalli](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@adawalli](https://klipper.discourse.group/u/adawalli)\ **Post date:** [December 25, 2022, 12:40am UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/5 "2022-12-25T00:40:37Z")
I’m glad that it worked for you! Unfortunately, this doesn’t work on the pi zero (no actually hub on this device). I might have to buy one of the hubs from that project, but also wish we could hear from klipper on why the `restart_method: command` doesn’t work ---
**Author:** ![bart](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/bart/32/7623_2.png) [@bart](https://klipper.discourse.group/u/bart)\ **Post date:** [October 19, 2023, 11:37am UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/6 "2023-10-19T11:37:48Z")
HI, same situation. It happens almost every time. In this situation only helps reboot. It can be reproduced when i edit config and then save and restart. This voron displays are crap. have two of them and same bahavior. ---
**Author:** ![HitLuca](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/hitluca/32/7915_2.png) [@HitLuca](https://klipper.discourse.group/u/HitLuca)\ **Post date:** [November 4, 2023, 9:58pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/7 "2023-11-04T21:58:29Z")
Same problem here, dealing with a klipper-expander secondary mcu. @fwiffo have you ever been able to solve this? ---
**Author:** ![bart](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/bart/32/7623_2.png) [@bart](https://klipper.discourse.group/u/bart)\ **Post date:** [November 9, 2023, 5:16pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/8 "2023-11-09T17:16:36Z")
looks like serious problem, but none has idea how to solve this. Still facing problems with voron 0 display. worst thing that designed for it case. But plan throw to trash this trash. ---
**Author:** ![JassMan23](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/jassman23/32/8238_2.png) [@JassMan23](https://klipper.discourse.group/u/JassMan23)\ **Post date:** [November 23, 2023, 1:33am UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/9 "2023-11-23T01:33:20Z")
Just wasted all day trying to get my head round this as well. What I have discovered is that when you need to reboot the RasPi, it loses comms with all the rest of the printer hardware. No amount of _[Restart Firmware]_ will get it working again because the device tree entries for the hardware is lost during the reboot. You can prove this by re-running `ls /dev/serial/by-id` Without the hardware identifying itself with its serial number, klipper cannot find your mcus. Running `uhubctl` twice (with **-a 0** to switch the USB ports off and again several seconds later with **-a 1** to switch back on) works for some hardware but not all. eg the _v0display_ and _BTT SKR-pico_ both restart on a power cycle and reappear in the device tree, However if you have an _LDO Picobilical_ this doesn’t, simply because the mcu is permanently powered by a 24V to 3.3V convertor while the previous 2 are powered from the USB. There is a further problem in klipper in that unless ALL mcus listed in your cfg files have been found it won’t talk to any. I found that if you use uhubctl to restart USB powered mcus, then press the restart button on the _picobilical_, this makes all boards re-register their serial number and then you **can** do a _[Restart Firmware]_ satisfactorily. Being a total noob, I don’t know how any of the comms work but I believe it to be some sort of token passing. I wouldn’t dare to suggest that the most logical solution would be for the authors of klipper to run a watchdog on each board so that if they have had no comms for say 5 secs, they restart and offer their ID to the host again. If the host has no commands to send, it should send a dummy keep-alive to prevent the watchdog from triggering. FWIW, I think `uhubctl -l 1-1 -p 2 -a 2` would probably work to restart USB powered mcus if I knew how the -d option worked but the default cycle delay is too short to reliably force a restart on v0display and BTT SKR. ---
**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\ **Post date:** [January 25, 2024, 9:42pm UTC](https://klipper.discourse.group/t/secondary-mcu-for-display-works-on-boot-fails-on-firmware-restart/5440/10 "2024-01-25T21:42:23Z")