MCU Connection Issue After Restart – Works Fine After Power Cycle

Basic Information:

Printer Model:
MCU / Printerboard: BTT Mnata m5p
Host / SBC - BTT CB2
klippy.log

I’m facing an issue with my Klipper setup where the connection to the MCU fails after a restart or reboot. Initially, when the system powers up, everything works perfectly—G-codes run, and the printer functions as expected. However, if I make any changes to printer.cfg or issue a restart command, I first get the error:
“Printer is not ready. The klippy host software is attempting to connect.
Please retry in a few moments.”

After a few minutes, it fails with the message:
“mcu ‘mcu’: Unable to connect. Once the underlying issue is corrected,
use the ‘FIRMWARE_RESTART’ command to reset the firmware, reload
the config, and restart the host software. Error configuring printer.”

Previously, the connection would automatically re-establish within seconds after a restart, but now it fails completely. I’ve reflashed both the Klipper firmware and the MCU firmware, checked all connections, and ensured that the configuration file is correct. The printer works fine after a complete power cycle, but the issue consistently occurs after a reboot or software restart. Could this be related to a recent Klipper or Mainsail update? Any help in resolving this would be greatly appreciated!

klippy (1).log (86.7 KB)

mcu 'mcu': Unable to open serial port: [Errno 2] could not open port /dev/serial/by-id/usb-Klipper_stm32g0b1xx_27000E001950425938323120-if00: [Errno 2] No such file or directory: '/dev/serial/by-id/usb-Klipper_stm32g0b1xx_27000E001950425938323120-if00'

Your log indicates that your MCU is either:

  • not correctly connected to the board
  • not correctly flashed
  • some host / Linux issues preventing the board to be correctly enumerated as USB device

But if I turn the power off and then turn it back on, the connection is restored. I checked the port using SSH, and it shows up the first time it’s powered on. However, if I run the restart command or any similar command, the port no longer appears.

Try:

[mcu]
serial = /dev/serial/by-id/usb-Klipper_stm32g0b1xx_27000E001950425938323120-if00
restart_method: command # <---- add this

(although in theory, it should not make a difference)

Hi,

Did the “add command as reset_method”-solution solve your issue or did you find a different solution?

I have a ATMega1280 based MCU together with a Raspberry Pi Zero 2 running klipper. I experience the same issue as you and is therefore interested to know what solution you found since adding “command” as reset_method didn’t solve the issue for me.

/Esben

Hello @esbenrug !

As far as I see, this thread is not marked solved. So there is no solution up to now.

You are right but I hoped that since the conversation ceased @Sineos may had found a solution even though it didn’t come out of this thread.
/Esben

For the ATMega you could try

restart_method: arduino

I tried that as well without luck.

in klippy.log I see the same error as others (see below).

I have tried multiple permutations of restart klipper service with or without the printer connected, with and without reset_method set to command or arduino etc.

The only pattern I can find is that it is not until the printer has been restarted that I can regain connection to it.

the printer is still in /dev/serial/by-id but apparently the klipper service can’t get in contact with the firmware

What to try next?

I am wondering if it is related to the fact that the USB-interface on the mightyboard is implemented in an ATmega8U2 as far as I know?

/Esben

mcu ‘mcu’: Timeout on connect
mcu ‘mcu’: Wait for identify_response
Traceback (most recent call last):
File “/home/esben/klipper/klippy/serialhdl.py”, line 68, in _get_identify_data
params = self.send_with_response(msg, ‘identify_response’)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/esben/klipper/klippy/serialhdl.py”, line 262, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/home/esben/klipper/klippy/serialhdl.py”, line 319, in get_response
self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
File “/home/esben/klipper/klippy/serialhdl.py”, line 254, in raw_send_wait_ack
self._error(“Serial connection closed”)
File “/home/esben/klipper/klippy/serialhdl.py”, line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu ‘mcu’: Serial connection closed

Please always format code as Preformatted Text:

Format

Sorry, not really any useful idea. Maybe:

  • Try different USB cable
  • Reflash board
  • Try /dev/ttyAMA0 as connection path and restart_method: command (or similar, whatever your board enumerates to)

I have tried to change USB cable which didn’t change anything. I have also reflashed the board multiple times

I also tried using the /dev/ttyACM0

I tried to connect using both the ‘console.py’ python script as well as avrdude to try alternative connections. I didn’t succeed. I reach the same result every time: It requires a power-cycle of the MCU to connect to it again.

One thing I found out though was that avrdude cannot connect to the MCU if the baud rate set as a avrdude commandline parameter exceeds 56700 baud.

I will try to see if that information can bring me anywhere.

Still, if you have any suggestions of how to proceed or new things to test I will appreciate them a lot.

Regards
Esben

I have solved my problem so far.

My assumption was that the connection issue had to do with the reset of the board and that it may had something to do with the way the reset is carried out maybe related to the bootloader. I thought that the bootloader on it was a standard Arduino bootloader since the board is based on a Arduino design but it seems not to be the case.

My printer is a Wanhao Duplicator 4 which is based on a variation of the mightyboard somewhere between rev E and rev G/H and it uses a special bootloader-mightyboard which the rep2/2x apparently also uses.

It turns out @dockterj has done a lot of work to get the replicator 2/2X to work which Wanhao Duplicator 4/4x printers can also benefit from. I came across this post How to connect klipper to Makerbot Replicator 2X? - #34 by dockterj where it is mentioned that @dockterj had implemented an additional reset method restart_method: mightyboard I tried to change to his klipper fork GitHub - dockterj/klipper: Adding support for MakerBot Replicator 2 and using his alternative reset method and this solved the problem :slight_smile:

Thank you @Sineos for you suggestions which kept me trying to find a solution and to @dockterj for your great mightyboard work. I hope you’ll get it into the main line soon :slight_smile:

I know that @Imesh_99 probably haven’t got a solution to his problem and won’ be able to use mine since he has a BTT board. So even though my problem is solved, the thread shouldn’t be make as solved.

Regards
Esben

Hello,

Just as reference, I want to add the following:

I came repeatedly to a point when using very cheap USB-Hubs/Switches that after a reset it wouldn’t be working.
The exact same problem as OP is describing.

In my experience the specific USB-Switch/Hub IC called “FE1.1s” from the manufacturer TerminusTech was the single source of my failures.

Once I switched to an (also cheap) Anker USB-Hub everything is working reliable.

  • cad435
1 Like