Different CAN bus speeds for Klipper and Canboot possible?

I want to change the CAN bus speed of Klipper from 500Kbps to 1Mbps, but I don’t want to change the speed for Canboot on my Fysetc SHT36v2, because it came with Canboot preinstalled and I am afraid to break something. Even if I would try, do I flash Canboot with flash_can.py?

To flash Klipper using 500K bps to the board should be no problem. If I then change the speed in the Network setting everything should run, but can I still flash Klipper with the Canboot on the lower speed by using ./lib/canboot/flash_can.py -b 500000 -u ea3249fe7350?
Or will Klipper in this case not go into Canboot mode, because it expects communication with 1Mbps?

All devices on the same CAN bus connections have to run at the same speed.

You can use different speeds, but in this case you have to switch to the canboot speed before you can flash, and also use the boot jumper (you can’t enter bootloader mode via software with mismatched speeds).

1 Like

Thank you. That makes sense. Can I reflash Canboot with ./lib/canboot/flash_can.py?

I believe so, I know I’ve done that at least once one a printer that had mismatched speeds.

Hmm, if I understand the documentation right then installing the deployer.bin with the new Canboot settings will do the job. Might have to read it more often to be sure ;). It seems that the deployer.bin comes together with the new Canboot and replaces Klipper. The only job of this new “Klipper” is to call Canboot. I assume that the deployer will then get replaced by the new Klipper with the new CAN speed I would have to flash afterwards.
What I don’t understand is whether the Canboot that is part of the deployer.bin replaces the old Canboot, or there will be a cascade. The old Canboot, calls the new Canboot? If the deployer replaces Klipper then it has the same starting address, but the old Canboot has another address. So how can it get replaced?

The canboot “deployer” is an “application” that is loaded on to the flash just as any other application would be loaded (eg, Klipper is another “application”).

So, when you flash the “deployer”, the flash looks like: Existing Canboot --> Deployer. The mcu is restarted and the previous Canboot calls the new Deployer.

The new deployer then flashes the new version of Canboot to the start of flash, overwriting the existing canboot. So the flash then looks like: New Canboot. At this point there is no application on the board, so only Canboot runs - it just sits there waiting for a request to flash an application.

At that point, one would typically flash an application (eg, Klipper). At that point, after flashing Klipper, the flash would look like: New Canboot --> Klipper.

Hope that helps,
-Kevin

1 Like

That is of big help, thank you!
So the Deployer gets called as the new application and replaces the current Canboot with the new Canboot that it carry inside it. After that erases its own start so that the new Canboot thinks that there is no application.
Yes that makes sense.

1 Like

Your post gave me another idea a little bit unrelated. I have another printer that uses a MKS robin nano for that I need to use this update_mks_robin.py script to encrypt klipper so that this shitty bootloader accepts it. What if I use instead of klipper.bin this deployer.bin? Would I be able to replace this custom bootloader with canboot ín this way?

Yes, that is what CanBoot depolyer.bin is for to get CanBoot to replace the current bootloader. Make sure you have copy or access to the stock bootloader if you ever need to go back.