BEWARE: Latest Klipper update breaks symlink to mcu on USB connected devices

[mvdveer]

19 minutes ago, ken226 said:

It's running good now, test printing a Voron calibration cube.

Happy you got it sorted. 

[Manny]

At the end, what matter is that you got it sorted, i made bigger mistakes than yours and fried boards, so you're lucky.

Cheers.

[Hubert1234]

On 5/2/2023 at 12:20 PM, ken226 said:

Ok, this is really weird.  I tried reflashing the firmware on the octopus from my CB1, via SSH and using the DFU method.  So, the reflash worked, and now my CB1 recognizes the Octopus board.

So, I removed the CB1 and connected my Raspberry Pi, and it recognizes the Octopus baord too.  

So, i guess, WoHoo!  maybe!  Now i gotta put all this crap back together and see if it works.

I'm in the same situation that you were in, maybe slightly more confusing. I've read through your story (several times) and tried to DFU reflash the Octopus 1.1 with first the original Pi (which got the faulty upgrade, then the 252.5-2 upgrade, still no /dev/serial/by-id). Then from another (old) Pi, but I cannot get the  lsusb command to show the DFU device. I followed the steps in the Voron guide, but nada. Do you have any suggestions? And did you reflash the Octopus board?

Thanks for any help, Hubert

[ken226]

13 hours ago, Hubert1234 said:

I'm in the same situation that you were in, maybe slightly more confusing. I've read through your story (several times) and tried to DFU reflash the Octopus 1.1 with first the original Pi (which got the faulty upgrade, then the 252.5-2 upgrade, still no /dev/serial/by-id). Then from another (old) Pi, but I cannot get the  lsusb command to show the DFU device. I followed the steps in the Voron guide, but nada. Do you have any suggestions? And did you reflash the Octopus board?

Thanks for any help, Hubert

 Reflash the octopus in DFU mode

First, put the boot jumper in place.   Plug the octopus into the pi,  then press and hold  the little reset button, just over the USB-c port for a out 5 seconds.     I missed the reset button part a couple times, which messed me up.

 

Then continue with the instructions.

 

 

1. From your ssh session, run cd ~/klipper to make sure you are in the correct directory
2. Run lsusb. and find the ID of the dfu device. The device is typically named STM Device in DFU mode.
3. If you do not see a DFU device in the list, press the reset button next to the USB connector and run lsusb again.
4. Run make flash FLASH_DEVICE=1234:5678 replace 1234:5678 with the ID from the previous step. Note that the ID is in hexadecimal, it only contains the numbers 0-9 and letters A-F.
5. Power off the Octopus
6. Remove the jumper from BOOT0 and 3.3V
7. Power on the Octopus
8. You can confirm that the flash was successful by running ls /dev/serial/by-id. If the flash was successful, this should now show a klipper device, similar to:

https://docs.vorondesign.com/build/software/images/stm32f446_id.png

 

After you successfully reflash the Octopus board,  the ls /dev/serial/by-id command will work, and klipper should be able to connect to your MCU again.

 

 

 

 

Edited May 9, 2023 by ken226

[Hubert1234]

3 hours ago, ken226 said:

 Reflash the octopus in DFU mode

First, put the boot jumper in place.   Plug the octopus into the pi,  then press and hold  the little reset button, just over the USB-c port for a out 5 seconds.     I missed the reset button part a couple times, which messed me up.

Then continue with the instructions.

1. From your ssh session, run cd ~/klipper to make sure you are in the correct directory
2. Run lsusb. and find the ID of the dfu device. The device is typically named STM Device in DFU mode.
3. If you do not see a DFU device in the list, press the reset button next to the USB connector and run lsusb again.
4. Run make flash FLASH_DEVICE=1234:5678 replace 1234:5678 with the ID from the previous step. Note that the ID is in hexadecimal, it only contains the numbers 0-9 and letters A-F.
5. Power off the Octopus
6. Remove the jumper from BOOT0 and 3.3V
7. Power on the Octopus
8. You can confirm that the flash was successful by running ls /dev/serial/by-id. If the flash was successful, this should now show a klipper device, similar to:

https://docs.vorondesign.com/build/software/images/stm32f446_id.png

After you successfully reflash the Octopus board,  the ls /dev/serial/by-id command will work, and klipper should be able to connect to your MCU again.

Thanks for the reply Ken. Two parts to my answer: I replaced the Octopus and the Pi, and everything works. But: I put the original Octopus and original Pi on the workbench, hooked them up, and it also works - I can see the USB address. I have no idea why; that's against my principles, but I may have to live with it. 

Second part: I tried the DFU mode repeatedly and could not get it to work. I could never see an "STM device in DFU mode" from the lsusb command. Another riddle. 

For completeness: I created the mainsail/klipper/debian SD card with Raspberry Pi Imager, and the udev is: Version: 247.3-7+rpi1+deb11u1

I did not run a system update from Mainsail; only the other components are updated. 

Thanks again; back to tuning my Voron. 

[Hubert1234]

Today we started working on the Voron, and the problem reoccurred. Long story short: our min12864 display never worked, so we unplugged it. The Octopus + Pi worked fine. Turns out that the mini12864 cables go in wrong when the housings are not reversed. We did, and all seems to work. Info on the display is here: https://docs.vorondesign.com/build/electrical/mini12864_klipper_guide.html

 

[mvdveer]

Just updated all 7 Voron's with latest Klipper update (commit May 21 ## Version V0.11.0-201-g37315b3).

No problems encountered with the updates on any machine.

Seems the bug has been fixed.

[claudermilk]

Klipoper and OS updates?

[gabber130779]

Have you done the system update? Or just Klipper? 

[ken226]

After downloading the fix posted earlier in this thread, reflashing my MCU, and getting it up and running, I have been updating my system regularly.  That was a couple weeks ago.

The only update that caused the problem was the update to 247.3-7+deb11u2, around May 2nd.  I've installed every update since,  and had no more trouble.

 

 

Edited May 22, 2023 by ken226

[mvdveer]

12 hours ago, claudermilk said:

Klipoper and OS updates?

Updated all software (Klipper, moonraker, mainsail, Klipperscreen,crowsnest, etc) and did a Raspi Systems Update/upgrade.

[mvdveer]

On 5/21/2023 at 11:04 PM, gabber130779 said:

Have you done the system update? Or just Klipper? 

Both. System and ALL Klipper components.

[ChicagoKeri]

Many, many thanks!

 

[Dougie Doug]

Did the fix and now printing but I can not see my web cam.   Did I miss something?

[mvdveer]

49 minutes ago, Dougie Doug said:

Did the fix and now printing but I can not see my web cam.   Did I miss something?

No it seems there is an issue with the crowsnest update on some systems - see here. I run two cameras on 3 printers and did not have an issue with those, nor the single cameras.

From what I have read this solution may work.

[ken226]

20 hours ago, mvdveer said:

No it seems there is an issue with the crowsnest update on some systems - see here. I run two cameras on 3 printers and did not have an issue with those, nor the single cameras.

From what I have read this solution may work.

Yea, that bug got me about two weeks ago.   I started a support request on the Crowsnest GitHub, the a ton of others popped in with the same problem.   They had to fix something in the update.   

 

The procedure in that link cured mine,  but I had to go back into the crowsnest.conf file and re-add the data for the second cam.  After applying the fix, my crowsnest config file was reverted to default.

[Geoff.S]

So, having just gone through this same saga myself, and used the backport fix mentioned one the first page.  I was wondering - will future Debian updates install correctly over the backport, or will we need to do something extra?

[bart]

Thanks

 

[bdejong11129]

I can say that as of today, June-11-2023 if you update it will break your printer.  I did the one line fix on the first page and brought it back. 

[mvdveer]

1 hour ago, bdejong11129 said:

I can say that as of today, June-11-2023 if you update it will break your printer.  I did the one line fix on the first page and brought it back. 

I think it depends on your flavour of the raspian OS.

As a test I have just updated my Voron2.4008 without any issues.

I run the mainsail distro (Linux/GNU 10 (buster) on all my printers, and this may not be affected by this persistent bug.

After updating Klipper:

Updating Klipperscreen, moon raker and upgrading the system, then rebooting:

All alive and well

 

[bdejong11129]

Hmmm. I am running (bullseye).  Sorry for the crappy phone picture. 

 

What determines the flavor of the distro?

[mvdveer]

59 minutes ago, bdejong11129 said:

Hmmm. I am running (bullseye)

I am running buster on this machine. So it seems it may be the bullseye variant of the Raspian OS may be the problem. Buster is an older distribution. However, my newer builds are all running bullseye and have not had an issue with those as mentioned before. System upgrade went smoothly. (Linux 11(Bullseye) Mainsail OS 1.0.1  

Interesting.

Your mainsail distro is 1.1.1, Whereis mine is 1.0.1 - this may be the issue

Will do some more reading/research about this.

[claudermilk]

That was kind of my understanding. The Buster version is ok, the Bullseye update is the problem. I'm still waiting on updating Klipper/Moonraker/OS as this still seems to be an issue.

[Woosatch]

Outstanding work and information....Thank You

[mvdveer]

On 6/3/2023 at 6:00 PM, Geoff.S said:

So, having just gone through this same saga myself, and used the backport fix mentioned one the first page.  I was wondering - will future Debian updates install correctly over the backport, or will we need to do something extra?

Just updated one of my older Trizero printers to the bullseye distro as it was too old to update crowsnest on buster (v10).

And I wanted to see what happened regarding the mcu issue if I update to the latest bullseye version.

And...........

 It broke the symlink.

 

Got it back with the fix mentioned. So it seems the latest update still has the bug. Don't know if, once the fix is applied, a further update will again break the link. Will see once the next update gets released and keep the group updated.