The two most recent releases of the Raspberry Pi OS, Bookworm & Trixie, both produce MCU executables for Duet3D Mini 5+ (SAME54P20) that experience communication integrity issues between the host and the MCU over the standard USB interface. This results in perpetually increasing counts of bytes_retransmit and bytes_invalid in the klippy.log file.
Background:
I recently completed some long outstanding maintenance on my oldest printer, which is a heavily modified CR-10S Pro running on a Duet 3D Mini 5+ MCU board with a Raspberry Pi 3B+ host. While already investing my time, I decided to upgrade the Pi to Trixie since it was still running on Bullseye. I previously attempted to upgrade this machine to Bookworm, but the Pi 3B+ experienced random OS freezes that forced me to revert to Bullseye. With the Pi upgraded to Trixie and the MCU code recompiled on Trixie and re-flashed, the machine started experiencing random shutdowns caused by Lost communication with MCU āmcuā errors.
It took many days to isolate this issue to the compiled MCU code. Inspecting the klippy.log from the CR-10S Pro revealed the first clue with increasing counts of bytes_retransmit and bytes_invalid, a significant deviation from years of constant bytes_retransmit=9 bytes_invalid=0in all previous releases of Pi OS. I involved my Voron that also runs on a Duet 3D Mini 5+ MCU board but with a Raspberry Pi 4B+ host running Bookworm. To my surprise and confusion I discovered that the Voron logs also showed similar increasing counts of bytes_retransmit and bytes_invalid (running on Bookworm). What made this even more confusing is that the comms errors would only increase when the stepper motors were active and in motion. I spent a few days chasing potential EMI issues and even looked at the power supply rails with my oscilloscope. Everything looked normal. I then decided to experiment with different versions of the Pi OS on the Voronā¦
Findings:
Bullseye, Bookworm & Trixie all work fine with no comms errors, but only if the Duet MCU firmware is compiled on Bullseye. Following is a handy matrix summarizing my test results. The two numbers in each cell represent the total count of bytes_retransmit and bytes_invalid after homing and a few seconds of the exact same XY movements run by a macro.
It seems that someone or something āout thereā just does not like the idea of Klipper running on Duet hardware . Having said that, I would venture a guess that in many cases people may not even realize that they have communication issues between the host and the MCU without specifically checking the klippy.log file. In my case the Voron has been running on Bookworm since March 2025 without any obvious functional effects of these communication issues.
I wonder if any other MCUs are perhaps experiencing similar issues, or whether this is specifically limited to the Duet3D Mini 5+.
This was really bugging me, no pun intended, so I spent some more time exploring. I think I can pretty conclusively confirm that this issue is caused by the compiler. Which likely means that many people running on Bookworm or Trixie, particularly on a Raspberry Pi, are likely seeing similar issues even on other non-Duet MCUs.
How have I reached this conclusion? I run three additional tests:
On my Ubuntu 25.10 VM I first removed the gcc-arm-none-eabi package.
I then installed the very latest toolchain arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi from Arm GNU Toolchain Downloads ā Arm Developer and I recompiled the MCU code and reflashed the MCU. This continued to produce MCU comms errors.
I then installed the pre gcc-12 based arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi and I recompiled the MCU code and reflashed the MCU. This produced stable MCU comms!
Finally, I removed the gcc-arm-none-eabi package and installed arm-gnu-toolchain-11.3.rel1-aarch64-arm-none-eabi on a test Raspberry Pi running Trixie. I recompiled the MCU code and reflashed the MCU. Predictably, this also produces stable MCU comms!
I was additionally going to install the most recent toolchain arm-gnu-toolchain-14.3.rel1 on a Raspberry Pi running on Bullseye to confirm that it breaks the MCU code again, but I run out of time. I think what I have done is pretty conclusive.
It is somewhat shocking that this type of a bug would persist in a compiler for so many years! Undoubtedly it must produce numerous other regressions outside of Klipper.
For what it is worth, it is possible that there is a subtle bug in the Klipper atsamd implementation that is only now being exposed by a minor change in the compiler. Unfortunately, tracking down these types of issues is challenging.
There is a gcc v15.1 version available. My Fedora desktop machine has that version (arm-none-eabi-gcc (Fedora 15.1.0-1.fc42) 15.1.0). It would probably be a good idea to check if the issue goes away with the very latest gcc version. (If it does go away, thereās a greater chance the issue is the compiler.) If you donāt have access to that gcc version I can compile a binary for you, or you can wait until Iām able to run tests on my atsamd test chips.
Iāve done just enough coding in the past, including some fiddling with gcc on an ancient m68k architecture, to understand that this is like finding the proverbial needle in a haystack.
If you compile a binary with gcc v15.1 for SAME54P20, I would be very happy to try it.
UPDATE: I set-up arm toolchain build environment in an Ubuntu VM using the instructions from Tooling / gnu-devtools-for-arm Ā· GitLab . This will allow me to assemble the toolchain with different versions of the required components. I am currently building a toolchain with the latest gcc-15.2 sources. Will provide additional updates when I have themā¦
UPDATE 2: Not good news, unfortunately. The comms errors persist with the latest gcc 15.2.0: bytes_retransmit=742 bytes_invalid=1246 send_seq=6503
. Having said that, I would venture a guess that in many cases people may not even realize that they have communication issues between the host and the MCU without specifically checking the