Ender 3: Lost communication with MCU 'mcu'

General Discussion
1

Basic Information:

Printer Model: Ender 3
MCU / Printerboard: BTT SKR 3 EZ, EBB36 v1.2, Raspberry Pi 4
klippy.log (6.0 MB)

Describe your issue:

I keep getting the “Lost communication with MCU ‘mcu’” midway through a print. It’ll usually print for at least 30 minutes before Klipper reports: SHUTDOWN.

I’ve tried the following:

  • Changing Power Supplies
  • Changing SD Cards
  • Changing USB Cables
  • Changing USB Ports
  • Reflashing both the SKR 3 EZ and EBB36

At this point, I’m not sure what else to try, so any help would be greatly appreciated.

3

Refer to Timeout with MCU / Lost communication with MCU
Unfortunately, this error is hard to come by, as it can be difficult to find the root cause. Almost 100% surely the problem is somewhere in your hardware.

4

Might this be relevant?

5

No, this issue would cause the board not to connect at all via /dev/serial/by-id but not to drop an existing connection.

6

I admit I don’t know what host the Ender3 uses (just that it is nominally Open Src)
Its just that my Voron always works from a power on. However, if you make any changes such as change a config and do Firmware Restart (it sometimes dies until re-power) or hit the software Red Button and select Reboot (it never works until re-power)
And I definitely have the buggy Bullseye.
I haven’t been game to complete the upgrade because of errors as listed in:

7

Some additional information:

I have everything setup using a USB to CANbus bridge, so the Pi 4 is connected to the SKR via USB, and the EBB36 is connected to the SKR 3’s CAN FD pins.

The error is always Lost communication with MCU 'mcu', so the issue has to be between the Pi 4 and the SKR 3, correct? Otherwise, I would think it would output Lost communication with MCU 'mcu EBBCan'.

I ran sudo dmesg and the only thing that seemed relevant was the following, which repeats multiple times:

Dec  3 23:57:23 mainsailos kernel: [14259.518702] usb 1-1.2: USB disconnect, device number 11
Dec  3 23:57:23 mainsailos kernel: [14259.519228] gs_usb 1-1.2:1.0 can0: Couldn't shutdown device (err=-19)
Dec  3 23:57:24 mainsailos kernel: [14259.765049] usb 1-1.2: new full-speed USB device number 12 using xhci_hcd
Dec  3 23:57:24 mainsailos kernel: [14259.876533] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
Dec  3 23:57:24 mainsailos kernel: [14259.876547] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec  3 23:57:24 mainsailos kernel: [14259.876552] usb 1-1.2: Product: stm32h723xx
Dec  3 23:57:24 mainsailos kernel: [14259.876557] usb 1-1.2: Manufacturer: Klipper
Dec  3 23:57:24 mainsailos kernel: [14259.876562] usb 1-1.2: SerialNumber: 36000A000951313332353636
Dec  3 23:57:24 mainsailos kernel: [14259.887285] gs_usb 1-1.2:1.0: Configuring for 1 interfaces
Dec  3 23:57:24 mainsailos kernel: [14260.041172] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

I’ve read that if your USB cable is near a power cable or stepper motor, it could cause interference, which in turn could cause the loss in communication. I’ve made sure to run my USB cable way from any of these sources of interference, and I’m still getting the error.

The funny thing is that based on my Benchy graveyard, you can see that the loss in communication happens around the same time in the print, but not at the exact same time.

Photo
Photo1920×1080 399 KB

This is driving me nuts. I wish I could connect the Pi 4 to the SKR 3 via UART, however, then I wouldn’t be able to use the onboard CAN as I do not believe UART to CANbus bridge is an option at this time.

8

I don’t know if anyone has ever tried it but there is an SPI to canbus for the Arduino.

In theory since the standard way of using canbus via USB ignores the USB part and finds the MCU via its canbus ID, it might work even if it is not recommended. See CANBUS - Klipper documentation for detwails about the usb-canbus config.

9

I was able to track down what the issue was. Even though I could not possibly imagine how it could be a hardware issue because the prints always failed roughly an hour in, I admit I was wrong, and it was one of the issues @Sineos linked above.

It was a bad power supply, or more specifically, a power supply with a bad fan controller. My printer was powered by a Mean Well LRS-350-24, and when referencing the data sheet for this power supply, the fan is supposed to turn on when temps reach 50°C and remain on until temps drop back down below 40°C. They also state that in an over temperature condition, they go into hiccup mode and recover automatically after the fault condition is removed.

So essentially my power supply was overheating, and the power would flicker off for roughly a second and then come back on, but that was long enough for the Raspberry Pi to lose communication with the MCU. Once I realized the fan was never coming on, I ordered a replacement power supply, swapped it out, and I haven’t had any issues since.

Anyway, I wanted to post this in case anyone in the future might be experiencing the same issue so I can hopefully save them some time by providing a possible solution.

LRS-350-SPEC.PDF (645.3 KB)

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.