# The flashtool option (-r) to get Klipper to relinquish control to Katapult does not work **URL:** \ **Category:** General Discussion\ **Created:** [January 30, 2024, 5:55pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665 "2024-01-30T17:55:15Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mark.dunn](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mark.dunn](https://klipper.discourse.group/u/mark.dunn)\ **Post date:** [January 30, 2024, 5:55pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/1 "2024-01-30T17:55:15Z")
### 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. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [January 30, 2024, 7:57pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/2 "2024-01-30T19:57:30Z")
Maybe @Arksine could chime in. ---
**Author:** ![Arksine](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@Arksine](https://klipper.discourse.group/u/Arksine)\ **Post date:** [January 30, 2024, 8:09pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/3 "2024-01-30T20:09:31Z")
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. ---
**Author:** ![mark.dunn](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mark.dunn](https://klipper.discourse.group/u/mark.dunn)\ **Post date:** [January 30, 2024, 9:41pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/4 "2024-01-30T21:41:58Z")
OK, I’ll try again tomorrow. Is there an easy way to see the CAN packets, or other trace that might help. ---
**Author:** ![mark.dunn](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mark.dunn](https://klipper.discourse.group/u/mark.dunn)\ **Post date:** [January 31, 2024, 2:18pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/5 "2024-01-31T14:18:58Z")
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? ---
**Author:** ![mark.dunn](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@mark.dunn](https://klipper.discourse.group/u/mark.dunn)\ **Post date:** [January 31, 2024, 2:54pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/6 "2024-01-31T14:54:38Z")
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. ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/klipper/original/1X/64419bf2aac6639e6ef5cef200dcd456b0a01ac3.png) [@system](https://klipper.discourse.group/u/system)\ **Post date:** [March 31, 2024, 2:54pm UTC](https://klipper.discourse.group/t/the-flashtool-option-r-to-get-klipper-to-relinquish-control-to-katapult-does-not-work/13665/7 "2024-03-31T14:54:50Z")
Closed on March 31, 2024, 2:54pm UTC This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.