The flashtool option (-r) to get Klipper to relinquish control to Katapult does not work

General Discussion
1

Basic Information:

Printer Model: Voron 0
MCU / Printerboard: SKR-Pico
klippy.log: Not required

Describe your issue:

I was updating the firmware for the SKR-Pico and EBB36 today and noticed that the flashtool option does not work. I disabled the CAN in printer.cfg and checked Klipper was listening on CAN:

~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -q -v

Resetting all bootloader node IDs…
Checking for Katapult nodes…
Detected UUID: fc7c3907fd17, Application: Klipper
Detected UUID: c80a2d7c1c33, Application: Klipper
Query Complete

It was, so I attempted to ‘request bootloader’ with:
~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -u c80a2d7c1c33 -r -v

Sending bootloader jump command…
Bootloader request command sent
Flash Success

Then I checked to see if Katapult is listening on USB
~/klipper $ lsusb

Bus 001 Device 012: ID 1d50:606f OpenMoko, Inc. Geschwister Schneider CAN adapter
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It was not (Klipper is still listening on CAN)

FYI: The old (and inelegant) workaround still works, writing new Klipper all over old Klipper and then picking up the pieces

~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -u fc7c3907fd17 -f ~/klipper/out/klipper.bin

Sending bootloader jump command…
Resetting all bootloader node IDs…
Attempting to connect to bootloader
ERROR:root:Can Read Error
Traceback (most recent call last):
…
lots of ugly error messages
…
FlashCanError: Error sending command [COMPLETE] to Can Device

Check Katapult is listening on USB with:
~/klipper $ lsusb

Bus 001 Device 004: ID 1d50:6177 OpenMoko, Inc. rp2040
Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It is, so we can update Klipper using Katapult on USB:
~/klipper $ ~/katapult/scripts/flashtool.py -d /dev/serial/by-id/usb-katapult_rp2040_4550357129118BE8-if00 -f ~/klipper/out/klipper.bin

Attempting to connect to bootloader
Katapult Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x10004000
MCU type: rp2040
Flashing ‘~/klipper/out/klipper.bin’…

[##################################################]

Write complete: 156 pages
Verifying (block count = 622)…

[##################################################]

Verification Complete: SHA = 086E4158F325F5B99B456D6000E863925D5B4C5C
Flash Success

I checked Klipper was listeing on CAN (which it was) and queried the CAN devices:
~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -q -v

Resetting all bootloader node IDs…
Checking for Katapult nodes…
Detected UUID: fc7c3907fd17, Application: Klipper
Detected UUID: c80a2d7c1c33, Application: Katapult
Query Complete

In the original test the version of Klipper was old (and now unknown), so I tried again after I upgraded

Klippy to v0.12.0-102-g9f41f53c
And on both devices
Katapult to v0.0.0-195-g6a7ca81e-inferred
Klipper firmware to v0.12.0-102-g9f41f53c

The problem persisted.

2

Maybe @Arksine could chime in.

3

I’m not sure what is happening here, but it seems exclusive to running the rp2040 in USB to Can bridge mode. It looks like Klipper receives the bootloader request and correctly sets the bootloader flag, but the device doesn’t reset until the follow up attempt to flash the other node.

To be clear, if a bootloader request is sent to node fc7c3907fd17 while the Can Bridge is running nominally then it should proceed with success. The issue the attempt to request the bridge.

I would recommend checking the output of dmesg after both the bootloader request and the followup flash attempt to see if any errors are produced.

4

OK, I’ll try again tomorrow. Is there an easy way to see the CAN packets, or other trace that might help.

5

My mistake (as shown in the original post) was that I requested the bootloader for the wrong device, twice! - and including the klippy.log WOULD have helped.

~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -u c80a2d7c1c33 -r -v
…
~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -u fc7c3907fd17 -f ~/klipper/out/klipper.bin
…
Detected UUID: c80a2d7c1c33, Application: Katapult

I retested with:
~/klipper $ ~/katapult/scripts/flashtool.py -i can0 -u fc7c3907fd17 -r
and it worked perfectly. Sorry to waste your time.

So I have almost got a scriptable solution to upgrading my firmware now.
The only thing I have not figured out is being able to run the USB to CAN bridge and see the CAN addresses WITHOUT changing the printer configuration. Is there a way?

6

The closest I have at the moment is to create a test.cfg with just an empty [mcu] section. Then stop the real klippy.py:

sudo service klipper stop

Create a dummy klippy.py in the background using test.cfg:

/home/mark/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/test.cfg -l /home/mark/printer_data/logs/klippy.log &
[1] 4010

Noting the Process Idendification (PID)
I can then ask for the CAN nodes and run the rest of the script:

~/katapult/scripts/flashtool.py -q
Resetting all bootloader node IDs…
Checking for Katapult nodes…
Detected UUID: fc7c3907fd17, Application: Klipper
Detected UUID: c80a2d7c1c33, Application: Klipper
Query Complete
…

Kill the dummy kippy.py using its PID

sudo kill 4010

And finally restart the real klippy.py:

sudo service klipper start

Not very pretty, but seems to work.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.