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.
Cheers,
-Kevin
What would be involved in doing that? The ideal would be something that queried the UUID and USB numbers and presented the user with a choice of which one to load the most recent firmware build onto.
I haven’t looked at it enough to know the details of what’s involved. I’d guess a lot of Linux scripting. I suspect we’re getting a bit off-topic here though.
-Kevin
@koconnor
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?
Just an idea
I moved these posts to a new topic.
I don’t use the canboot deployer frequently enough for that to be a concern for me. So, unlikely it would be something I would spend development time on. I don’t know of anyone else working on it.
-Kevin
@koconnor
Ive been wanting to find a way to flash my skipr mcu, running in bridge mode, without needing physical access the sdcard, is it possible?
The first post mentions canboot and bridge mode, can one put canboot on a bridge mode mcu?
I tried ./scripts/flash-sdcard.sh /dev/ttyS0 mks-skipr
with board definition of
'mks-skipr': {
'mcu': "stm32f407xx",
'spi_bus': "spi3a",
"cs_pin": "PC9",
"firmware_path": "mks_skipr.bin",
"current_firmware_path": "mks_skipr.CUR"
}
But that gave me SPIFlashError("Unable to connect to MCU"), not sure there is any way to write to the sdcard while in can bridge mode.
When using the Klipper CAN bridge, the MCU USB port will only serve the CAN bridge and no other request.
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.
-Kevin
DFU mode is not working for my skipr boards
I flashed canboot via stlink, can I flash klipper application with stlink aswell?
@gaby_64: Did you find a solution for this - also mine - problem?
Hello @yammaster !
Sadly you may have to investigate yourself for a solution.
This is how I flash klipper after canboot/katapult is flashed with stlink.
~/klippy-env/bin/python3 ~/CanBoot/scripts/flash_can.py -i can0 -u e96cc8663264 -r
sleep 5s
sudo chmod 666 /dev/ttyACM0
~/klippy-env/bin/python3 ~/CanBoot/scripts/flash_can.py -d /dev/ttyACM0
change according to your setup
Is it right to configure CanBoot as follows:
… and Klipper:
I’m not sure about bootloder und bootloader offset.
@gaby_64: where did you connected the st programmer?
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.
Yes, I got it - but without stlink programmer: first canboot:
mks@mkspi:~/CanBoot$ sudo dfu-util -a 0 -D ~/CanBoot/out/canboot.bin --dfuse-address 0x08000000:force:mass-erase -d 0483:df11
second klipper:
mks@mkspi:~/klipper$ sudo dfu-util -a 0 -D ~/klipper/out/klipper.bin --dfuse-address 0x08008000:leave -d 0483:df11
And after all - the commands from gaby_64 see above.
THX!!!
Installing Klipper with dfu-util kinda defeats the purpose of installing Canboot/Katapult.
Why do you say that? I install Katapult with DFU-Util and then Klipper which allows me to update the main controller without having to physically access it.
My point was that once you’ve flashed Katapult with dfu-util, you don’t need to use dfu-util to install Klipper. You can use the included flashing scripts and stop messing with DFU.
Sorry, the way it was worded it sounded it was either or.
