Summary:
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.
This immediately brought back bad memories of the issues with Bullseye compiling bad executable for Duet 2 MCU boards: Duet 2 firmware compilation broken on Debian 11.
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+.