CanBoot Issues with Klipper "USB to CAN bus bridge" Device

[idontknowtom]

@Arksine Can CanBoot be optimized to work with the Klipper "USB to CAN bus bridge" communication? The bridge device is seen as a serial device when you enter the bootloader...notably when CanBoot is flashed to a device after full chip erase. Klipper is then flashed using:

python3 flash_can.py -d {serial device}

After successful flash the serial device communication disappears the the bridge is now found with a CAN uuid. Any attempts to flash updated Klipper or CanBoot firmware using the CAN uuid produces an error.

My only solution to provide updates via CanBoot commands is to initially send an update command via CAN uuid:

python3 flash_can.py -i can0 -u {uuid}

This ends in error but also enters the bootloader...enabling access to the serial device communications. I can now send:

python3 flash_can.py -d {serial device}

And successfully flash firmware. The serial device communication disappears and becomes CAN. I provided screenshots of my SSH terminal window showcasing the issues. @KevinOConnor this may need your assistance due to your development of the "USB to CAN bus bridge" feature.

Note I don't expect to be able to flash over CAN for this device. But perhaps this type of device can be identified so that it can properly enter the bootloader when the serial device flash command is sent (even if the device is only identifiable with a CAN uuid).

Conducted with the most updated versions of CanBoot and Klipper:

CanBoot commit:
c85d2cc

Klipper commit:
9e4994cbdb5a3b1017a0dcca9808efde0de153d4

[idontknowtom]

Posted this on Klipper Discourse.

Kevin indicated that yes Klipper and CanBoot updates require two commands at this point.

1. A CanBoot CAN flash command to the bridge MCU
   • This will result in an error and will force entry into the CanBoot bootloader. can0 uuid disappears. Serial device appears.
2. A CanBoot serial flash command to the bridge MCU
   • This will flash your firmware update. can0 uuid appears and serial device disappears.

Potential to automate this, but not being worked on. @Arksine any possibility to implement this automation or should I close this issue?

[Arksine]

Its fine to keep it open. I can't promise that I'll be able to work on this anytime soon, however I'll try to get to it eventually.

[NAPCAL]

Klipper update script could be:
named octopus_update.sh
cd ~/CanBoot/scripts
python3 flash_can.py -u [uuid]
python3 flash_can.py -d [serial device]
python3 flash_can.py -q

Replace [uuid] with the octopus uuid
Replace [serial device] with the CanBoot /dev/serial/by-id/usb-canboot…..

run with
bash octopus_update.sh

The last command is to make sure the CAN bridge is back online.
Thanks to TJ MacLennan for testing this script and finding out that no delays between the commands are needed.

[idontknowtom]

@NAPCAL I did it slightly different than that, but similar idea.

cd CanBoot/scripts

Then create a "bridge.sh" script

sudo nano bridge.sh

Copy and paste:

python3 flash_can.py -u [uuid}
python3 flash_can.py -d [serial device]
python3 flash_can.py -q

Replace [uuid] with the Octopus uuid
Replace [serial device] with the CanBoot /dev/serial/by-id/usb-canboot…..

CTRL+X, key Y for yes, and key ENTER.

So the script is in ~/CanBoot/scripts

To run the script you don't want to use sudo, it gives an error:
FlashCanError: Invalid firmware path /root/klipper/out/klipper.bin

So to run it all you have to do is:
bash bridge.sh

Note, this requires you to have already compiled Klipper firmware and have the bin file in ~/klipper/out, as it does by default.

[NAPCAL]

Nice.

One reason I put my script in my home directory is when I want to update the CanBoot from GitHub; I remove the whole CanBoot folder and then do a clone. So with the octopus script in the home folder, it doesn't get deleted.

If there is a better way to get the upgrade/update CanBoot, please share.

[idontknowtom]

@NAPCAL It is better to use "git pull".

Since you used the following to put CanBoot on your Pi:

git clone https://github.com/Arksine/CanBoot

If you navigate to the CanBoot folder with cd CanBoot you can then use git pull
to update your CanBoot folder to the latest commit from GitHub.

This does not overwrite any local changes, so the bridge.sh or octopus_udpate.sh scripts (however you want to name it) won't get deleted.

[FirewinX]

i think this issue can be closed. After the commit [1da9898] you can use -r for bootloader request.

for me i use this:

create a bridge.sh script
nano bridge.sh

in this copy and paste

python3 ~/CanBoot/scripts/flash_can.py -r -u your-uuid
sleep 1s
python3 ~/CanBoot/scripts/flash_can.py -d /dev/serial/by-id/your-serial
sleep 1s
python3 ~/CanBoot/scripts/flash_can.py -q

press ctrl+x and press y for save the file

make it executable with
chmod +x bridge.sh

after this you can use this with
./bridge.sh

please make sure it is a compiled klipper.bin in the ~/klipper/out directory

this works for flashing my over USB connected SKR3 over canboot.

[Pmant]

To fully resolve the issue it would be nice if it would work in just one step with all three parameters -r -u -d

[idontknowtom]

@FirewinX I have a script similar to this already called bridge_update.sh but it attempts to flash the bridge MCU over CAN, fails, and sends the bridge MCU into the bootloader.

Great to see this feature added I’ll test it tomorrow and close this issue.

By the way I also copy my Klipper .config file as .config_skr3, .config_ebb and .config_rpi. So my bridge update script compiles Klipper firmware for all 3 boards (renaming them so they don’t override each other) and flashes Klipper updates via CanBoot commands.

KIAUH to update and a single bash command to build and flash the updates.

@Pmant I agree though I don’t know enough so say if that is even possible.

[Arksine]

To fully resolve the issue it would be nice if it would work in just one step with all three parameters -r -u -d

This may often result in the wrong location specified for -d, as it isn't possible to know it until the MCU has entered CanBoot. A user could guess it, or they could enter the device path of the gs_usb device, however the likely result would be much confusion.

To automate it in one step we need to be able to resolve the USB device path from the socketcan interface. I would think that this is possible, but thus far I am unable to find a way to do this.

[Pmant]

This may often result in the wrong location specified for -d, as it isn't possible to know it until the MCU has entered CanBoot. A user could guess it, or they could enter the device path of the gs_usb device, however the likely result would be much confusion.

Valid point but once the USB Serial ID is obtained it will stay the same unless you change it on purpose. Default setting in Kconfig is "USB serial number from CHIPID".

[FirewinX]

i think it is not the correct way, mixing the can -u UUID command with the -d serial device command in one command line

[Arksine]

Valid point but once the USB Serial ID is obtained it will stay the same unless you change it on purpose. Default setting in Kconfig is "USB serial number from CHIPID".

Correct, however the script cannot place the requirement that the user enter the path by id since it does not yet exist. A robust automated solution would not require that the user specify any device path, it needs to check the device at the bus path to validate the USB IDs, it can then find the appropriate serial device. Truth be told this functionality is probably better implemented in Klipper through its make flash facility, as the USB-CAN bridge is unique to Klipper and requires a unique solution for full automation.

[idontknowtom]

@Arksine The latest commit with flash_can.py -r argument works great.

Had an error at first but quickly realised that even though bootloader request doesn’t flash firmware to the board…it still requires firmware to exist (default Klipper firmware out location) or requires a custom firmware location be defined with -f

Is it possible to not require -f (default or custom) if the -r flag is used?