Duet2 Eth Klipper Firmware issues

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