Duet 2 firmware compilation broken on Debian 11

Basic Information:

Printer Model: N/A
MCU / Printerboard: Duet 2
klippy.log is not generated

Describe your issue:

When compiling the Klipper firmware for Duet 2 (SAM4e8e) on Debian 11 (stable), the resulting binary does not work. Specifically, when plugging in via USB no serial device is seen on the host PC. Checking the udevadm monitor output reveals that the system does not even attempt to enumerate a new USB device. I can reliably reproduce this, both on arm64 (Raspberry Pi 4) and amd64 (personal laptop). The firmware still compiles correctly on Debian 10 (oldstable), and interestingly enough seems to compile appropriately on Debian 12 (unstable).

After some investigation on Discord with both Monkeh#1790 and @ReXT3D this issue does not appear to be isolated. It appears an issue was opened on Github here but closed for being ā€œ[a]pparently some OS issueā€. While it is technically OS-specific, this doesnā€™t seem like a good reason to ignore it as the OS at hand is the current stable release of what is probably the single most popular distribution of Linux used to run Linux (Raspberry Pi OS, essentially Debian 11). If a new user installs Klipper on the current release of Raspberry Pi OS and tries to use a Duet, it will fail. The current ā€œsolutionā€ is to use Debian 10, which luckily is still used by Mainsail OS. This isnā€™t a solution though, as the next release of Mainsail OS will be based on Debian 11.

I have tried some basic troubleshooting but unfortunately I donā€™t know enough about ARM embedded and USB enumeration in particular to figure it out. @ReXT3D was able to install the Debian 10 toolkit (gcc-arm-none-eabi, binutils-arm-none-eabi and libnewlib-arm-none-eabi plus dependencies) on Debian 11 and found that this worked correctly. It appears that Debian 10 uses GCC 7, while Debian 11 uses GCC 8, and apparently Debian 12 actually uses GCC 11. Personally, I feel like this is unlikely to be compiler bug, but obviously itā€™s not impossible.

What can be done here? Is there anything I can do to help? I have a spare Duet 2 Wifi available as well as both arm64 and amd64 development environments. I would like to get this fixed, whether itā€™s in Klipper, GCC, or somewhere else, for the benefit of all Duet 2 users.

1 Like

Thanks for reporting.

Unfortunately, itā€™s very difficult to track down these types of problems. To find the root cause it typically requires a developer to have the board in hand, connecting a remote debugger to it (eg, stlink with openocd and gdb), and tracing to the instructions that lead to the fault. With the faulting instructions, the developer would then backtrack to the corresponding code and determine if the code is at fault or the compiler translation.

-Kevin

My primary concern with this issue is that we are close to Mainsail and likely Fluidd distros shifting to Debian 11, which can create many confused Duet 2 users. The behaviour is quite difficult to understand and troubleshoot for anyone who is not already aware of the issue. It would be good to identify and document a workaround even if the exact root cause is not understood.

I have a Duet 2 board available, it has a bad stepper driver so itā€™s not in use at all. Iā€™m not sure what device would be used to connect to the JTAG (or if it even has one), but Iā€™d be happy to purchase it if it would help. I can even provide a remote VM for you (or an appropriately experienced dev) to work on it, or I can flash and test myself if thatā€™s better. Does any of that help?

As I ran into the same issue yesterday, I would like to emphasize my wish for getting this fixed.
The current MainsailOS (downloaded yesterday) already uses Bullseye as @zettabomb already forecasted.
To be quite honest, Iā€™m not sure how we could find a suitable dev willing to put work into this. @Knackwurst would also have a spare Duet 2 Wifi for diagnostic purposes.

For sake of completeness:

New user who tried to use a duet wifi, pi 4b and mainsail OSā€¦ran into same issue. As mentioned this is now broken on current mainsail OS releaseā€¦at least there could be some kind of alert message when on bullseye based OS and flashing duet, to save noobs like me from wasting a couple hours messing about before googling around and finding itā€™s just broken :slight_smile:

FYI for anyone else encountering this; I got a spare USB stick and used pi-imager to put Mainsail OS 0.7.1 on it (buster-based release). Loaded it up, updated klipper, compiled and flashed firmware for duet, and it worked. Then, swapped back to other Pi drive with Mainsail 1.0.1, and itā€™s working.

Fairly easy workaround, most of my time was lost trying to figure out why it was broken initially.

2 Likes

Unfortunately didnā€™t work for me. As soon as i updated klipper and flashed the board again. The issue is the same. Without the update of klipper it did work but then it wasnā€™t possible to run it with the Mainsail 1.01 version.
OS: Raspbian GNU/Linux 10 (buster)
Distro: MainsailOS 0.7.1 (buster)
klipper: v0.11.0-86-g6026a99a

Where did I go wrong?

Hi, I have had the same issue. I have tested a lot of different possible solutions to try to solve this issue.
First off, I do have an SD card with a working install, based on Buster with klipper v0.11.0_66_g4671cf2d.

This has been my safe path back to a working install.

I, as many has had failure after failure when updating to all releases after this one. Tried to download MainsailOS several times and build it all from scratch, but to no use, it fails all the time. So - I tried to move the new *.bin file to my ā€œsafe installā€ and do the make flash FLASH_DEVICE=*my printer ID - still fails. (looses the USB connection)

So - today I did it different, I made yet another SD card, but this time I used the rasbian lite img (Bullseye, and Buster) - and dropped MainsailOS, and went for semi automated install trough Kiauh, and to my suprise, it now works both on Buster and Bullseye. I did it on the Buster distro first, found it odd, cleaned my SD, made Bullseye and went troug it all by Kiauh again, and voila, my board flashed just fine.

Weird error, and I have had the same issue on pre v0.11.0_66_g4671cf2d who actually worked on Bullseye. So, my best bet - this has something todo with the Bossa instructions not ā€œgettingā€ it is flashed for usage trough USB.

Hope anyone else found this useful, I have done my ā€œshareā€ of of trial and error- to say the least!

1 Like

hi
i have the same problem with 2 new duet 2 wifi boards.
i tried everything you wrote and it didnt help.
i keep getting this id.
/dev/serial/by-id/usb-03eb_6124-if00

i tried with kiauh, tried with 0.7.1 imageā€™ and tried everything else.
do you have any other idea to solve this problem?
thanks

I had avoided updating firmware for several months, seems recently a breaking change came in forcing me to update (MCU protocol error because firmware on duet too old). Compilation/flashing on bullseye still broken - tried it (Pi 4B on mainsailOS 1.0.1) and duet disappeared, at least i expected it this time.

Followed normal firmware make and flash process on laptop running ubuntu 23.04, flashed fine, plug it back into Pi and all working well again with this version: v0.11.0-219-g645a1b83
image

For me anyway no issues running it once flashed. Only cannot build/flash on bullseye

Hi,

Just to help other people, like @cakenub , I did compile Klipper on another linux distro (pop os), flashed through USB, and it worked like a charm.

Cheers.

I was facing this issue still.

The Duet would either lose connection at some point or never connect, and I had to press the reset button on the duet several times until the serial device reappeared. Although, sometimes it would never work.

Thanks a lot for this tip!

I ended up making a GitLab CI job to build Klipper on Ubuntu 23.10 instead (just because I misread your message). The repo is here. To set it up I ran make menuconfig and configured the Duet on the RPi, and then uploaded the .config file to a file named config in the repo. The rest can be learnt from the ci-cd file therein.

Note that the config file is specific to the Duet 2 WiFi, and that the Klipper repo it is using is a fork (that Iā€™ve been messing with) included as a submodule.

The CI job builds Klipper and keeps the ā€œoutā€ directory (where the firmware is) as an artifact of the job. It then can be browsed, and the klipper.elf file within can be downloaded.

I copied the elf file from my laptop to the Raspberry with scp, overwritting the previous one, and flashed as usual from the Raspberry.

Issue begone.

If someone is still facing this issue, let me know and Iā€™ll try to help out.