Duet2 Eth Klipper Firmware issues

[dtmcnamara]

Hey everyone,

I am having issues getting Klipper onto my Duet2 Eth board and would love some insight from anyone who might have had luck flashing it. Currently I have the following setup:

• Fusion3 F410 printer with a Duet2 Eth board

• Pi 4 with raspbian lite installed

I installed Kiauh which installed Klipper, Moonraker, and Fluidd for me. I went and compiled my firmware for Klipper with the following settings:

[ ] Enable extra low-level configuration options
Micro-controller Architecture (SAM3/SAM4/SAM E70 (Due and Duet))
Processor model (SAM4e8e (Duet Wifi/Eth))
Communication interface (USB)

Before flashing the files I throw the jumper on the erase header connect the board to the Pi and once the DIAG light turns on I take the erase jumper off. Just to make sure the board is connected I run a:

ls /dev/serial/by-id/*

and it returns:

/dev/serial/by-id/usb-03eb_6124-if00

additionally running a:

lsusb

Shows the Duet board as a Bossa device so everything looks good so far. Next I run:

./lib/bossac/bin/bossac --port=/dev/serial/by-id/usb-03eb_6124-if00 -b -U -e -w -v -R out/klipper.bin

and am greeted with:

Erase flash

Done in 4.252 seconds
Write 25252 bytes to flash (50 pages)
[==============================] 100% (50/50 pages)
Done in 0.349 seconds
Verify 25252 bytes of flash
[==============================] 100% (50/50 pages)
Verify successful
Done in 0.282 seconds
Set boot flash true

So everything looks good. Strange thing is if I run a:

ls /dev/serial/by-id/*

I get:

ls: cannot access '/dev/serial/by-id/': No such file or directory*

as well as if I run a

lsusb

I no longer see the Duet board anymore. I have from this point tried to reboot the Duet to see if that was the final step, and nothing. I have rebooted Klipper services and nothing. I have rebooted the Pi and still nothing comes up.

I have been chasing my tail all afternoon trying to get what should have been a quick and easy swap over, but obviously Im either doing something wrong, or missing one little step, this is my firest every Duet board so I could easily be making a mistake somewhere. I did notice all tutorials online people are using the Duet2 Wifi, which this shouldn't make a difference since they are the same base board, just with a different module on it.

Other notes about what I have tried. I have done everything with different usb cables connecting the Duet to the Pi to ensure the issue wasnt with the cable. I have also done this with wall power running into the Pi and not just power from a computers USB port. Additionally, I have flashed everything with and without the microSD card installed as well as with and without the PanelDue screen attached. I have re-installed my Pi from scratch 3-4 times already just to make sure the issue wasnt with my install and everything is up to date. All devices are still plugged into the Duet board since its still installed in the printer, but I dont think that makes a difference (if it does let me know and I can mark everything and pull it tomorrow). I have also pulled the klipper.bin file from the Pi and used Bossa on windows to flash the file both with the name Klipper.bin as well as changing it to Duet2CombinedFirmware.bin just to make sure it didnt matter.

Would love some input from people more familiar with the Duet board. Let me know what I can try

[droftarts]

@dtmcnamara Sorry, but we don't support Klipper; this forum is primarily for Duet with RepRapFirmware. For Klipper support, you would be better of asking on their Discord server. Have you tried flashing the board back to RepRapFirmware, and checking that works?

However, I can see an odd thing about the bossac firmware flashing command. It is happening very fast (0.349 seconds). Usually flashing just isn't that fast; it should be a few seconds at least.

You seem to be using the U parameter (which forces serial port detection) in your bossac command, when you are also specifying the port. Try with one or the other, not both.

I'm also not sure about using /dev/serial/by-id/ as the port. On Linux, I usually use the port directly, usually something like /dev/ttyACM0. See the Linux tab here on detecting the port: https://docs.duet3d.com/en/How_to_guides/Getting_connected/Getting_connected_to_your_Duet#install-drivers

See my post here about using bossac (on MacOS, but should apply to all OSs): https://forum.duet3d.com/post/290007

Ian

[dtmcnamara]

@droftarts totally understand. I figured with the little klipper content on here this was probably going to be the case. The flash speed seems right, as far as all the other content I have seen about flashing klipper on the Duet. Most tutorials show between 47-50 pages, and it taking no more than 2 seconds.

Everything else I just followed the instructions from others online so there is no reason for doing it any way.

I did revert back to ensure the board was functional, and everything still works when back on the original firmware.

If I find a solution I will update this post, just in case someone else stumbles across it. Thanks

[dc42]

@dtmcnamara it might be worth asking @Luke-sLaboratory if he has any ideas about this one.

[oliof]

@droftarts said in Duet2 Eth Klipper Firmware issues:

I'm also not sure about using /dev/serial/by-id/ as the port.

Thats normal under klipper because /dev/ttyACM* is not reliable to be stable across boots (USB enumeration can change with kernel and/or klipper formware updates), and you may have multiple boards (displays, toolboards, multiple control boards for larger numbers of drivers or additional IO). Configuring by id gives you a stable identifier.

[droftarts]

@dtmcnamara Ah, yes, the binary is much smaller, so would flash faster. That makes sense. I still think using both the port name and the U parameter might cause conflicts. Did you try without the U parameter?

@oliof Thanks for the info! Another Linux-command-line thing I didn't know about. Unfortunately it doesn't seem to have made it into macOS, where devices can't be connected to by id.

Ian

[apak]

@dtmcnamara need to use raspbian BUSTER (version 10)

Raspbian bullseye (version 11) has a bug whan flashing klipper onto duet boards, and does a semibrick of the board.

Lately it´s been said that flashing the LITE version of raspbian, and right after that using KIAUH you could flash it with both versions (buster and bullseye).

I have a SD with buster that flashed successfully duet3 mini5 and duet2 wifi

[oliof]

@apak what does semibrick mean, and do you know how to recover?

[apak]

@oliof when you flash klipper fw it doesn´t finish quite well, and board does not respond.
Just reflash RRF again and it works fine.

That´s a semibrick...board not working but you are able to recover it by regular procedure.

[oliof]

@apak is that captured in a bug on the klipper side? I worry that the conspiracy theorists talk about Duet3D "locking" the board.

[apak]

@oliof nothing to do with klipper or duet, it´s a debian or bossa bug....

[Luke'sLaboratory]

@oliof its 100% a debian or bossa bug. Duet has been nothing but awesome in their quest for true open source.

Have you got it working? I've definitely run across that annoying bug

[oliof]

@Luke-sLaboratory I havent tried, I just like to be on the up and up (-:

[matthew 81]

@dtmcnamara it took me several minutes to flash 100 pages or so on duet 2 upgrading the firmware,perhaps that is different