It is technically possible, but requires a two step process. One can run flash_can.py -u <bridge_can_uuid> to put the bridge mcu into bootloader mode, and then flash it with flash_can.py -d /dev/serial/by-id/usb-CanBoot-xxx. There’s been discussions of better automating this, but no one has had the time as of yet.
This would be rare, but if you use deployer.bin to update CanBoot, the deployer will be loaded where Klipper was running, so the CAN bridge goes down. You cannot load Klipper back via CanBoot CAN bus or USB.
Could a selectable option be added to deployer.bin and include klipper.bin, then get both back into place so the CAN bridge will be back up and working?
deployer.bin gets copied into the bootloader location.
then wipes the rest of the flash memory above the CanBoot firmware to application offset.
copies klipper firmware to the start of the application offset.
then wipes from above Klipper formware to the end of flash memory.
I know, but what about USART, this is how it actually connects from mcu to the builtin rk3328 without CAN, @koconnor previously mentioned that mcu communications to host for the bridge canbus are not actually over CAN, it does not consume CAN bandwidth.
It is possible to use canboot on an mcu that will ultimately run in “usb to canbus bridge mode” (as mentioned at the start of this topic). You would need to flash canboot using the sdcard (or DFU) method. Only subsequent flashing of Klipper is then a possibility without using the sdcard.
They have to match.
Katapult bootloader offset sets the flash memory location to jump to start running firmware code after running the bootloader code.
Klipper bootloader offset is where to place the start of the Klipper code within the flash memory and not to overwrite the bootloader code. If you set no bootloader then the Klipper code is placed where the MCU starts running flash memory code.