I was able to flash Canboot onto the SKR V1.4 using a raspberry pi connected to the board via UART using the tft pins and lpc21isp command below.
lpc21isp -wipe -bin ~/CanBoot/out/canboot.bin /dev/ttyAMA0 230400 12000
After I was able to flash klipper with the following command.
python3 ~/CanBoot/scripts/flash_can.py -d /dev/ttyAMA0 -b 250000 -v -f ~/klipper/out/klipper.bin

After the first flash if I want to reflash or flash an updated version I have to double tap the reset button. Is this the normal Canboot behavior? I was hoping to be able to flash klipper via the command line without having to access the board itself.

I get the following error if I don't double tap the reset button.

Attempting to connect to bootloader
ERROR:root:Can Read Error
Traceback (most recent call last):
File "/home/pi/CanBoot/scripts/flash_can.py", line 137, in send_command
ret = await self.node.readuntil()
File "/home/pi/CanBoot/scripts/flash_can.py", line 287, in readuntil
return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

Thank you for any information you may provide.

Any way to return to application from bootloader with serial device without having to reboot the board?
This is for a board running klipper in bridge mode.

This is just a note that CanBoot is currently using Klipper's USB ids. When I ported the USB code from Klipper, I just copied the ids (the Klipper id is 0x1d50:0x614e as defined in src/Kconfig).

It might be worthwhile to obtain a unique USB id dedicated to CanBoot. I don't think it's a huge issue as Linux shows the "product name" in lsusb and /dev/serial/by-id/ , and I did change that to "CanBoot" as part of porting.

The process I used to get a unique USB id was to clone the https://github.com/openmoko/openmoko-usb-oui repo, add a line to usb_product_ids.psv , and then submit a PR with that change. For reference: openmoko/openmoko-usb-oui#11

I'd make the request for CanBoot, but I'm not sure if you need to be the author of the PR.

-Kevin

I have followed the guide (and Eddies videos) to install canboot on the EBB42 CAN V1.1.
I used the menuconfig options from the BTT documentation.
I happen to be using the waveshare can hat.
After flashing canboot on the board, I successfully flashed klipper over the can bus.

pi@arkwire2:~/klipper/lib/canboot_ $ python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 3266f8206791
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 3266f8206791, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/pi/klipper/out/klipper.bin'...

[##################################################]

Write complete: 13 pages
Verifying (block count = 411)...

[##################################################]

Verification Complete: SHA = 68F2BECD8F5259EC79195152106770D87BCD6D4D
CAN Flash Success

But upon restarting, the printer does not see the MCU EBBCan.

I have used a stripped down printer.cfg for testing.
Klippy log listed below.

Starting Klippy...
Args: ['/home/pi/klipper/klippy/klippy.py', '/home/pi/klipper_config/printer.cfg', '-l', '/home/pi/klipper_logs/klippy.log', '-a', '/tmp/klippy_uds']
Git version: 'v0.10.0-566-g9f8f3cd7'
CPU: 4 core ARMv7 Processor rev 3 (v7l)
Python: '3.7.3 (default, Jan 22 2021, 20:04:44) \n[GCC 8.3.0]'
Start printer at Mon Sep 5 09:15:58 2022 (1662383758.8 20.0)
===== Config file =====
[mcu]
serial = /dev/serial/by-id/usb-Klipper_stm32f103xe_39FFD7054247333439710757-if00
restart_method = command

[mcu EBBCan]
canbus_uuid = 3266f8206791

[printer]
kinematics = none
max_velocity = 100
max_accel = 100

mcu 'mcu': Starting serial connect
Loaded MCU 'mcu' 105 commands (v0.10.0-566-g9f8f3cd7 / gcc: (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] binutils: (2.31.1-11+rpi1+11) 2.31.1)
MCU 'mcu' config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c1a=PB8,PB9 BUS_PINS_i2c2=PB10,PB11 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi3=PB4,PB5,PB3 CLOCK_FREQ=72000000 INITIAL_PINS=!PC13 MCU=stm32f103xe PWM_MAX=255 RESERVE_PINS_USB=PA11,PA12 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
mcu 'EBBCan': Starting CAN connect
Created a socket
webhooks client 3045371664: New connection
webhooks client 3045371664: Client info {'program': 'Moonraker', 'version': 'v0.7.1-659-gf047167'}
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
mcu 'EBBCan': Timeout on connect
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
mcu 'EBBCan': Wait for identify_response
Traceback (most recent call last):
File "/home/pi/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
params = self.send_with_response(msg, 'identify_response')
File "/home/pi/klipper/klippy/serialhdl.py", line 259, in send_with_response
return src.get_response([cmd], self.default_cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 317, in get_response
cmd_queue)
File "/home/pi/klipper/klippy/serialhdl.py", line 251, in raw_send_wait_ack
self._error("Serial connection closed")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Serial connection closed
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
Created a socket
mcu 'EBBCan': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available
MCU error during connect
Traceback (most recent call last):
File "/home/pi/klipper/klippy/mcu.py", line 772, in _mcu_identify
self._canbus_iface)
File "/home/pi/klipper/klippy/serialhdl.py", line 133, in connect_canbus
self._error("Unable to connect")
File "/home/pi/klipper/klippy/serialhdl.py", line 61, in _error
raise error(self.warn_prefix + (msg % params))
serialhdl.error: mcu 'EBBCan': Unable to connect

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/pi/klipper/klippy/klippy.py", line 176, in _connect
self.send_event("klippy:mcu_identify")
File "/home/pi/klipper/klippy/klippy.py", line 263, in send_event
return [cb(*params) for cb in self.event_handlers.get(event, [])]
File "/home/pi/klipper/klippy/klippy.py", line 263, in
return [cb(*params) for cb in self.event_handlers.get(event, [])]
File "/home/pi/klipper/klippy/mcu.py", line 782, in _mcu_identify
raise error(str(e))
mcu.error: mcu 'EBBCan': Unable to connect
Build file /home/pi/klipper/klippy/../.config(2553): Sun Sep 4 20:09:33 2022
========= Last MCU build config =========
CONFIG_LOW_LEVEL_OPTIONS=y

CONFIG_MACH_AVR is not set

CONFIG_MACH_ATSAM is not set

CONFIG_MACH_ATSAMD is not set

CONFIG_MACH_LPC176X is not set

CONFIG_MACH_STM32=y

CONFIG_MACH_RP2040 is not set

CONFIG_MACH_PRU is not set

CONFIG_MACH_LINUX is not set

CONFIG_MACH_SIMU is not set

CONFIG_BOARD_DIRECTORY="stm32"
CONFIG_MCU="stm32g0b1xx"
CONFIG_CLOCK_FREQ=64000000
CONFIG_FLASH_START=0x8000000
CONFIG_FLASH_SIZE=0x20000
CONFIG_RAM_START=0x20000000
CONFIG_RAM_SIZE=0x24000
CONFIG_STACK_SIZE=512
CONFIG_STM32_SELECT=y

CONFIG_MACH_STM32F103 is not set

CONFIG_MACH_STM32F207 is not set

CONFIG_MACH_STM32F401 is not set

CONFIG_MACH_STM32F405 is not set

CONFIG_MACH_STM32F407 is not set

CONFIG_MACH_STM32F429 is not set

CONFIG_MACH_STM32F446 is not set

CONFIG_MACH_STM32F031 is not set

CONFIG_MACH_STM32F042 is not set

CONFIG_MACH_STM32F070 is not set

CONFIG_MACH_STM32F072 is not set

CONFIG_MACH_STM32G0B1=y

CONFIG_MACH_STM32H743 is not set

CONFIG_MACH_STM32H750 is not set

CONFIG_MACH_STM32G0=y
CONFIG_HAVE_STM32_USBFS=y
CONFIG_HAVE_STM32_FDCANBUS=y
CONFIG_HAVE_STM32_USBCANBUS=y

CONFIG_STM32_FLASH_START_2000 is not set

CONFIG_STM32_FLASH_START_0000=y
CONFIG_STM32_CLOCK_REF_8M=y

CONFIG_STM32_CLOCK_REF_12M is not set

CONFIG_STM32_CLOCK_REF_16M is not set

CONFIG_STM32_CLOCK_REF_25M is not set

CONFIG_STM32_CLOCK_REF_INTERNAL is not set

CONFIG_CLOCK_REF_FREQ=8000000
CONFIG_STM32F0_TRIM=16

CONFIG_STM32_USB_PA11_PA12 is not set

CONFIG_STM32_SERIAL_USART1 is not set

CONFIG_STM32_SERIAL_USART1_ALT_PB7_PB6 is not set

CONFIG_STM32_SERIAL_USART2 is not set

CONFIG_STM32_SERIAL_USART2_ALT_PD6_PD5 is not set

CONFIG_STM32_SERIAL_USART3 is not set

CONFIG_STM32_SERIAL_USART3_ALT_PD9_PD8 is not set

CONFIG_STM32_CANBUS_PA11_PA12 is not set

CONFIG_STM32_MMENU_CANBUS_PB8_PB9 is not set

CONFIG_STM32_MMENU_CANBUS_PD0_PD1 is not set

CONFIG_STM32_MMENU_CANBUS_PB0_PB1=y

CONFIG_STM32_MMENU_CANBUS_PD12_PD13 is not set

CONFIG_STM32_MMENU_CANBUS_PC2_PC3 is not set

CONFIG_STM32_USBCANBUS_PA11_PA12 is not set

CONFIG_STM32_CANBUS_PB0_PB1=y
CONFIG_USB_VENDOR_ID=0x1d50
CONFIG_USB_DEVICE_ID=0x614e
CONFIG_USB_SERIAL_NUMBER="12345"
CONFIG_CANSERIAL=y
CONFIG_CANBUS=y
CONFIG_CANBUS_FREQUENCY=250000
CONFIG_CANBUS_FILTER=y
CONFIG_INITIAL_PINS=""
CONFIG_HAVE_GPIO=y
CONFIG_HAVE_GPIO_ADC=y
CONFIG_HAVE_GPIO_SPI=y
CONFIG_HAVE_GPIO_I2C=y
CONFIG_HAVE_GPIO_HARD_PWM=y
CONFIG_HAVE_GPIO_BITBANGING=y
CONFIG_HAVE_STRICT_TIMING=y
CONFIG_HAVE_CHIPID=y
CONFIG_HAVE_STEPPER_BOTH_EDGE=y
CONFIG_INLINE_STEPPER_HACK=y

Build file /home/pi/klipper/klippy/../out/klipper.dict(7674): Mon Sep 5 08:27:52 2022
Last MCU build version: v0.10.0-566-g9f8f3cd7
Last MCU build tools: gcc: (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] binutils: (2.31.1-11+rpi1+11) 2.31.1
Last MCU build config: ADC_MAX=4095 BUS_PINS_i2c1=PB6,PB7 BUS_PINS_i2c1a=PF1,PF0 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_spi3=PB4,PB5,PB3 CANBUS_FREQUENCY=250000 CLOCK_FREQ=64000000 MCU=stm32g0b1xx PWM_MAX=255 RECEIVE_WINDOW=192 RESERVE_PINS_CAN=PB0,PB1 RESERVE_PINS_crystal=PF0,PF1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
Build file /home/pi/klipper/klippy/../out/klipper.elf(373984): Mon Sep 5 08:27:57 2022

Hello,

maybe an update manager entry would be a cool feature, but I'm not sure if it would be such a useful feature, CanBoot updates should happen very rarely.

It would be nice to be able to get MCU type and other details from a device without actually starting a flash cycle, similar to the information provided when starting a flash.

hi
Btt has with his Ebb board 1.1 switched to STM32G0B1xx is it possible to use this chip also with CanBoot with changes. the firmware upload via can was is very pleasant and you do not always have to press the small buttons for the dfu mode

and great work

Using the steps defined in the document below for the EBB42 v1.2, it fails every time while downloading:

https://klipper.discourse.group/uploads/short-url/oKyxrVja7wW0J8toGB1pqfaGp4z.pdf

Clearing the memory works, but the following step to write does not.

Possibility to install CanBoot on a RP2040 Chip

Example code:
https://github.com/rhulme/pico-flashloader

Blog entry for building a custom RP2040 bootloader:
https://blog.usedbytes.com/2021/12/pico-serial-bootloader/

I tried another update today, as klipper required that the MB be flashed, and I just realized that this has never worked. I can install katapult and klipper via DFU mode with the following:

dfu-util -a 0 -D ~/katapult/out/katapult.bin -s 0x08000000:mass-erase:force -d 0483:df11
dfu-util -a 0 -D ~/klipper/out/klipper.bin -s 0x08008000:force:leave -d 0483:df11

However, I can NEVER do anything with flashtool.py (previously flash_can.py). The following command to use katapult to flash the MB has never worked:

python3 ~/katapult/scripts/flashtool.py -i can0 -f ~/klipper/out/klipper.bin -u 28b14df6273c

After stopping klipper and executing the above, the result is always:

python3 ~/katapult/scripts/flashtool.py -i can0 -f ~/klipper/out/klipper.bin -u 28b14df6273c
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for Katapult nodes...
ERROR:root:Flash Error
Traceback (most recent call last):
  File "/home/pi/katapult/scripts/flashtool.py", line 628, in main
    loop.run_until_complete(sock.run(intf, uuid, fpath, req_only))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/pi/katapult/scripts/flashtool.py", line 474, in run
    raise FlashCanError(
FlashCanError: Unable to find node matching UUID: 28b14df6273c

And 28b14df6273c is the UUID of my Octopus Pro MB.

Would be great to have a CAN Bus, for sure with CanBoot from the (in my case) PI to the (in my case) Fysetc Spider Board to (in my case) SB2040.
Would be very easy to update the firmware and no more USB/micro-sd needed. Too it would be possible to move the PI, 5V powersupply and 'network' out of the printer and just need 2 small cables in between. And have a lovely box near the printer with everything in and the display in Front 😍

I am following this guide: https://docs.meteyou.wtf/

Building and flashing bootloaders (BTT candleLight_fw for U2C 2.1, katapult for EBB36 1.2 and 2x EBB42 1.2) using dfu-util over USB seems to go fine. Building klipper again goes fine, but to flash over CAN fails because no devices are detected on the CAN network.

pi@fluiddpi:~ $ python3 ~/katapult/scripts/flashtool.py -i can0 -q Resetting all bootloader node IDs... Checking for Katapult nodes... Query Complete pi@fluiddpi:~ $

I can go ahead and flash klipper over USB, so I have tried that, but when I reconnect for CAN communication the same problem persists.

I have tried re flashing all boards with setting CAN speed to 500k and 1M, which has not helped.

I am trying this with only one EBB board at a time, so my connections are Pi to U2C (USB) U2C to EBB (CAN). I am using the screw terminals on the U2C and I have quadruple checked the wiring- Can-H to Can-H, CAN-L to CAN-L, +24 to +24, and GND to GND. Since I am only testing with one node at a time I have 120R jumpers on both the U2C and the EBB. Measuring CAN-H to CAN-L with power off is 60 Ohms.

Can you recommend any further troubleshooting steps?

Hi, I have the creality Ender 6 with the V4.3.1 board. I compiled the bootloader with the attached .config file.

I flashed the bootloader with STM32 Cube Programmer, and see that it's flashed.

However, I can not get into bootloader mode and flash with stm32flash on Linux using this command for flashing the klipper firmware. I connected PB 11 to high and plugged the board in USB.

stm32flash -w out/klipper.bin -v -b 230400 -g 0x08002000 /dev/ttyUSB1

config.txt

Please provide support for STM32H743; this is a processor being used on the NEW BigTreeTech boards.
CanBoot makes it easy to update without jumping through hoops or SD cards.
I am using it on all of my BigTreeTech boards with STM32 processors.

Hi , can you help me to find out whats wrong?
i use skr pico and uart

pi@MinionPi:~ $ python3 ~/katapult/scripts/flash_can.py -f ~/klipper/out/klipper.bin -d /dev/ttyAMA0
ERROR:root:Flash Error
Traceback (most recent call last):
File "/home/pi/.local/lib/python3.9/site-packages/serial/serialposix.py", line 385, in _reconfigure_port
fcntl.flock(self.fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
BlockingIOError: [Errno 11] Resource temporarily unavailable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/pi/katapult/scripts/flash_can.py", line 549, in run
serial_dev.open()
File "/home/pi/.local/lib/python3.9/site-packages/serial/serialposix.py", line 332, in open
self._reconfigure_port(force_update=True)
File "/home/pi/.local/lib/python3.9/site-packages/serial/serialposix.py", line 387, in _reconfigure_port
raise SerialException(msg.errno, "Could not exclusively lock port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 11] Could not exclusively lock port /dev/ttyAMA0: [Errno 11] Resource temporarily unavailable

I'm trying to flash Klipper to the nucleo using CanBoot and CanSerial as described in your instructions, and with the following bootloader config

but I do get the following error

could you point me in the right direction to debug this?

I recently updated the project and I'm facing this issue while trying to do a make menuconfig

master ✔ $ make menuconfig 
Using default symbol values (no '/tmp/CanBoot/.config')
Configuration saved to '/tmp/CanBoot/.config'
  Creating symbolic link out/board
Loaded configuration '/tmp/CanBoot/.config'
Traceback (most recent call last):
  File "lib/kconfiglib/menuconfig.py", line 3281, in <module>
    _main()
  File "lib/kconfiglib/menuconfig.py", line 661, in _main
    menuconfig(standard_kconfig(__doc__))
  File "lib/kconfiglib/menuconfig.py", line 705, in menuconfig
    locale.setlocale(locale.LC_ALL, "")
  File "/usr/lib/python3.7/locale.py", line 604, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
make: *** [Makefile:150: menuconfig] Error 1

When trying to reboot into CanBoot via flash_can.py -u [uuid] -r , an invalid firmware path error is invoked, and the bootloader is never called. Seems like the request bootloader function shouldn't be looking for a file given that it won't be flashing at that point.

I think the following change or something similar would fix it

if not fw_path.is_file():
            raise FlashCanError("Invalid firmware path '%s'" % (fw_path))

to

if not fw_path.is_file() and not req_only:
            raise FlashCanError("Invalid firmware path '%s'" % (fw_path))

Hi,
I have a custom RP2040 design that i intend to use only with the CAN interface for communication and uploading new firmware. But i am unable to write the CanBoot firmware on my custom RP2040 pcb.
I have tried doing the same on the stock Rpi Pico module and it works properly. I am able to detect the board using 'scripts/flash_can.py -i can0 -q'.
The difference with the custom design is that i am using a W25Q32JVZPIQ flash chip instead of W25Q16 chip. And also the CAN IC that i used is TCAN337 (on custom board) instead of VP230 (on rpi pico module).
Is there anything that i am missing here?

In the readme.md it states:

Enter the bootloader. This will occur automatically if no program is detected. If you built CanBoot with an alternative method of entry you may use that. If upgrading from a currently flashed version of Klipper the flash_can.py script will command the device to enter the bootloader (currently for CAN devices only).

Is it possible and planned to implement this for USB as well? We've had quite a few bootloader related issues out of the box on some boards lately, so I would love to add CanBoot support to RatOS to facilitate recovery from those situations, and maybe move over to CanBoot completely depending on how that goes.

Hello,

while trying to upload firmware I get this errors. Could you help me what could be wrong please?

For upload I use RS485 CAN HAT and on RPI
Node is "Bluepill"

Thanks a lot

`
[##################################################]

Write complete: 23 pages
Verifying (block count = 356)...

[###########ERROR:root:Can Read Error
Traceback (most recent call last):
File "flash_can.py", line 137, in send_command
ret = await self.node.readuntil()
File "flash_can.py", line 287, in readuntil
return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
####ERROR:root:Can Read Error
Traceback (most recent call last):
File "flash_can.py", line 137, in send_command
ret = await self.node.readuntil()
File "flash_can.py", line 287, in readuntil
return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
###########ERROR:root:Can Read Error
Traceback (most recent call last):
File "flash_can.py", line 137, in send_command
ret = await self.node.readuntil()
File "flash_can.py", line 287, in readuntil
return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
#######ERROR:root:Can Flash Error
Traceback (most recent call last):
File "flash_can.py", line 609, in main
loop.run_until_complete(sock.run(intf, uuid, fpath))
File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
return future.result()
File "flash_can.py", line 470, in run
await flasher.verify_file()
File "flash_can.py", line 240, in verify_file
resp = await self.send_command("REQUEST_BLOCK", payload)
File "flash_can.py", line 187, in send_command
% (cmdname))
FlashCanError: Error sending command [REQUEST_BLOCK] to Can Device
`

I managed to flash CanBoot on the device and it is visible

~/CanBoot/scripts/flash_can.py -i can0 -q

Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 558da1510eb7, Application: CanBoot
Query Complete

I performed menueconfig in klipper and when I try to upload the klipper fw to the device I get following output:

python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 558da1510eb7

Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 558da1510eb7, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/lukics/klipper/out/klipper.bin'...

[##################################################]

Write complete: 13 pages
Verifying (block count = 414)...

[ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Flash Error
Traceback (most recent call last):
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 619, in main
    loop.run_until_complete(sock.run(intf, uuid, fpath, req_only))
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 475, in run
    await flasher.verify_file()
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 240, in verify_file
    resp = await self.send_command("REQUEST_BLOCK", payload)
  File "/home/lukics/CanBoot/scripts/flash_can.py", line 186, in send_command
    raise FlashCanError("Error sending command [%s] to Can Device"
FlashCanError: Error sending command [REQUEST_BLOCK] to Can Device

I google'd around and did not get any hint on how to solve this issue

When querying the can again I can see klipper under the save uuid:

python3 ~/CanBoot/scripts/flash_can.py -i can0 -q

Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 558da1510eb7, Application: Klipper
Query Complete

When i add the feature for 8KB offset, it works, the 16 and 32KB offsets dont work for a blackpill board.

Suggested change in KCONFIG of STM32

|| MACHSTM32F4 to the 8KB offset

Ran into this while messing with running my own transceiver on an octopus pro using alternative pins. I get no communication on PB5/PB6 with CanBoot, but klipper works fine. I suspect it is similar to the issue that resulted in this klipper commit: https://github.com/Klipper3d/klipper/pull/5988/commits

Edit: I never realized the can code is more or less the same as in klipper. I copied the revised can.c from that klipper commit to my local CanBoot install and recompiled. Now it works as expected.

I was looking to use this for my SKR 1.4 with LPC1768 but noticed the instructions are heavily based around the STM32 devices. I have flashed a BTT EBB36 using CanBoot and want to add CanBoot to the SKR 1.4

Any tips on flashing CanBoot, setting up Klipper (smoothieware bootloader, so no bootloader options available), and flashing Klipper?

After flashing my BTT Octopus Pro 1.0 and the accompanying EBB36 1.2 with canboot and klipper successfully I get the following issue:

dmesg output:

[   43.832205] can: controller area network core
[   43.832287] NET: Registered PF_CAN protocol family
[   43.853804] can: raw protocol
[   45.382598] usb 1-1.1.1: reset high-speed USB device number 4 using dwc_otg
[   86.503446] gs_usb 1-1.1.2:1.0 can0: bit-timing not yet defined

Here is my /etc/network/interfaces.d/can0:

allow-hotplug can0
iface can0 can static
    bitrate 500000
    up ifconfig $IFACE txqueuelen 1024
    post-up /sbin/ip link set up $IFACE type can bitrate 500000

Not matter what I try, the interface fails to load until I manually run /sbin/ip link set up can0 type can bitrate 500000

Hello

I instaled CanBoot + Klipper on my SB2040 Toolboard
Now every time I restart everything the Toolboard is not recognized.
But for some reason if I connect my Toolboard after the Pi boots to USB and power everything works just fine.

Add a command (or extend CONNECT) to report the version of canboot (possibly from git describe or a .version file if not in a git repo at build time). This would allow for software to query and update canboot (via deployer or other methods) conditionally.

Hi. I cannot flash the klipper.bin file using the flash_can.py script. It seems that the script cannot recognize the UUID of my EBB42 V1.2 BTT and omits the most significant digit - which is the number zero.

Hi, we spoke this afternoon on Discord (@Arksine), but thinking this may be a better place to continue discussion about this issue.

I have below described issue with Klipper, an earlier version of Canboot, as well as the latest version of Katapult (master when I tried it at git rev abd1545).

I have a setup where there are 14 BTT EBB42 (STM32G0B1) devices connected to the CAN bus. When I run the flash_can.py -q tool, I see the following output:

Resetting all bootloader node IDs...
Checking for Katapult nodes...
Detected UUID: 00f22d4144ed, Application: Katapult
Detected UUID: 1317977e2691, Application: Katapult
Detected UUID: 1938ab445cd6, Application: Katapult
Detected UUID: 1c48bb32084e, Application: Katapult
Detected UUID: 2f8cda1c080d, Application: Katapult
Detected UUID: 524c7d22ceb7, Application: Katapult
Detected UUID: 5cdbc4430eb7, Application: Katapult
Detected UUID: 5ea9f1aad1ad, Application: Katapult
Detected UUID: 63da04283cb8, Application: Katapult
Detected UUID: 7ebe07793a00, Application: Katapult
Detected UUID: 863872fb3e8c, Application: Katapult
Detected UUID: a561e958aa96, Application: Katapult
Detected UUID: c2645270504d, Application: Katapult
Detected UUID: e80c6d2a5c83, Application: Katapult
Query Complete

Candump shows:

  can0  3F0   [1]  12
  can0  3F0   [1]  00
  can0  3F1   [8]  20 00 F2 2D 41 44 ED 11
  can0  3F1   [8]  20 13 17 97 7E 26 91 11
  can0  3F1   [8]  20 19 38 AB 44 5C D6 11
  can0  3F1   [8]  20 1C 48 BB 32 08 4E 11
  can0  3F1   [8]  20 2F 8C DA 1C 08 0D 11
  can0  3F1   [8]  20 52 4C 7D 22 CE B7 11
  can0  3F1   [8]  20 5C DB C4 43 0E B7 11
  can0  3F1   [8]  20 5E A9 F1 AA D1 AD 11
  can0  3F1   [8]  20 63 DA 04 28 3C B8 11
  can0  3F1   [8]  20 7E BE 07 79 3A 00 11
  can0  3F1   [8]  20 86 38 72 FB 3E 8C 11
  can0  3F1   [8]  20 A5 61 E9 58 AA 96 11
  can0  3F1   [8]  20 C2 64 52 70 50 4D 11
  can0  3F1   [8]  20 E8 0C 6D 2A 5C 83 11

If I then run the same flash_can.py -q a second time, I see fewer devices on the bus:

Resetting all bootloader node IDs...
Checking for Katapult nodes...
Detected UUID: 00f22d4144ed, Application: Katapult
Detected UUID: 1317977e2691, Application: Katapult
Detected UUID: 1938ab445cd6, Application: Katapult
Detected UUID: 1c48bb32084e, Application: Katapult
Detected UUID: 2f8cda1c080d, Application: Katapult
Detected UUID: 524c7d22ceb7, Application: Katapult
Detected UUID: 5cdbc4430eb7, Application: Katapult
Detected UUID: 5ea9f1aad1ad, Application: Katapult
Detected UUID: 63da04283cb8, Application: Katapult
Query Complete

And on candump:

  can0  3F0   [1]  12
  can0  3F0   [1]  00
  can0  3F1   [8]  20 00 F2 2D 41 44 ED 11
  can0  3F1   [8]  20 13 17 97 7E 26 91 11
  can0  3F1   [8]  20 19 38 AB 44 5C D6 11
  can0  3F1   [8]  20 1C 48 BB 32 08 4E 11
  can0  3F1   [8]  20 2F 8C DA 1C 08 0D 11
  can0  3F1   [8]  20 52 4C 7D 22 CE B7 11
  can0  3F1   [8]  20 5C DB C4 43 0E B7 11
  can0  3F1   [8]  20 5E A9 F1 AA D1 AD 11
  can0  3F1   [8]  20 63 DA 04 28 3C B8 11

Every time the query for unassigned devices is done, the amount of toolboards gets less. This goes on until two or sometimes one device is left and the rest doesn't answer anymore.

I can then only bring back the missing devices by resetting them (button press on the toolboard).

--

Notice that the devices are always listed from low to high uuid.

This low-to-high made me think of the bus arbitration, where the lowest value always gets precedence. But still I thought that was based on the id, which is 3F1 here all the time. But then again, how can bus arbitration work if the id's are always the same ?

I was given advice to try a debugger, but I have no experience with STM32 programming or debugging yet.

I did wonder what happens if I make sure that the devices do not answer at the same time, so I put a random sleep before replying at the following location:

https://github.com/Arksine/katapult/blob/master/src/generic/canserial.c#L154

#include "board/armcm_timer.h" // udelay(uint32_t) and timer_read_time(void)

// ...

static void
can_process_query_unassigned(struct canbus_msg *msg)
{
    if (CanData.assigned_id)
        return;
    struct canbus_msg send;
    send.id = CANBUS_ID_ADMIN_RESP;
    send.dlc = 8;
    send.data[0] = CANBUS_RESP_NEED_NODEID;
    memcpy(&send.data[1], CanData.uuid, sizeof(CanData.uuid));
    send.data[7] = CANBUS_CMD_SET_CANBOOT_NODEID;

    // hack introduce random delay of 0 upto about 0.5 sec (=500000 usec)
    // take last 19 bits (mask 0x7FFFF fit max value 524287) of current time
    udelay(timer_read_time() & 0x7FFFF);

    // Send with retry
    for (;;) {
        int ret = canbus_send(&send);
        if (ret >= 0)
            return;
    }
}

When using this, all the devices remain working, now the flash_can.py -q shows:

Resetting all bootloader node IDs...
Checking for Katapult nodes...
Detected UUID: 1938ab445cd6, Application: Katapult
Detected UUID: 1c48bb32084e, Application: Katapult
Detected UUID: e80c6d2a5c83, Application: Katapult
Detected UUID: 863872fb3e8c, Application: Katapult
Detected UUID: a561e958aa96, Application: Katapult
Detected UUID: 5ea9f1aad1ad, Application: Katapult
Detected UUID: 1317977e2691, Application: Katapult
Detected UUID: 524c7d22ceb7, Application: Katapult
Detected UUID: 7ebe07793a00, Application: Katapult
Detected UUID: c2645270504d, Application: Katapult
Detected UUID: 2f8cda1c080d, Application: Katapult
Detected UUID: 5cdbc4430eb7, Application: Katapult
Detected UUID: 00f22d4144ed, Application: Katapult
Detected UUID: 63da04283cb8, Application: Katapult
Query Complete

And I can repeat that many times, all devices stay on the bus.

Notice that sequence is now also randomized.

--

I think the solution I concocted is somewhat ugly, but for now it gets me a bit further, seeing that other traffic after short node-id assignment uses a unique id.

Could someone help me out making a nice solution for this issue ?

Thank you,
Leon

Installing CanBoot appear to leave the SKR Pico in permanent boot mode, even without the jumper installed and rebooting.

I am also seeing a lot of errors in dmesg:
device descriptor read/64, error -32
device not accepting address 6, error -71
unable to enumerate USB device

Hi,
it seems to me there is a typo in the README where the only supported model should read STM32F103 instead of STM32F203.
Is my assumption correct?

This option is not implemented in CanBoot and was a carryover from Klipper code.

Found when running [make menuconfig] setting up my new Octopus Pro H723.

These lines need to be removed from this file so users don't get the notion that CanBoot has this feature.
413 config STM32_USBCANBUS_PA11_PA12
414  bool "USB to CAN bus bridge (USB on PA11/PA12)"
415  depends on HAVE_STM32_USBCANBUS
416  select USBCANBUS

I'm not entirely sure of the feasibility of this, as it relies on being able to reliably extract the MCU type from a klipper/deployer image to be deployed. Information about that should be readily available in the klipper .elf, but getting it out from .bin may be pain. This would probably best be an opportunistic check, that maybe prints an informative message if it can't determine the MCU type of a firmware blob.

Having trouble getting CanBoot and klipper run on Manta M8P STM32G0B1 with CM4. Reset of the board gives me can0 interface, ~/CanBoot/scripts/flash_can.py -i can0 -q gives me the uuid (if I'm quick enough) and then it disappears and not coming back before next reset of MCU. klipper service is shutdown while testing. Update of klipper with ~/CanBoot/scripts/flash_can.py -i can0 -u UUID fails.
To me it looks like CAN on klipper is not working correct on the STM32G0B1 MCU. This is both with CAN-Hat and with "USB to CAN bus bridge (USB on PA11/PA12)"

Hi everyone, I would like to address a very recent issue popping up at multiple places related to the BOOT0 Pin in the STM32G0 series devices. See:

• https://github.com/Esoterical/voron_canbus/tree/main/can_adapter/Makerbase%20UTC%201.0
• https://community.st.com/t5/stm32-mcu-products/has-anyone-gotten-the-boot0-pin-to-work-on-an-stm32g071-solved/td-p/338772/page/2
• And we have the same problem with my GBB15 board (https://github.com/skuep/GBB15)

The issue basically is, that STM thought it was a good idea, to disable the BOOT0-Pin functionality (unless the flash is empty). That means, DFU mode can be reached on those devices when you buy them and they are unprogrammed. You can flash CanBoot to those devices via dfu-util without any issues. However, if you want to change e.g. the CAN baudrate of CanBoot, you will quickly find, the device will no longer enter DFU mode by asserting BOOT0-Pin = 3.3V, because it is disabled by default in the STM32 option bytes.

As a fix, it is possible to program the option bytes, setting the nBOOT_SEL=0. This enables the "legacy" (sic!) behaviour. This can be done via SWD (needs hardware probe), DFU (clunky) or from within the device itself (cool).
I am proposing to add a CanBoot menuconfig option for STM32G0 series devices STM32G0_ENABLE_BOOT0PIN (or similar, which is enabled by default), that checks on startup if the above option bit is set, and if it is, it will reset the bit permanently. This will function very similar to the already available menuconfig-option STM32F103GD_DISABLE_SWD for the GigaDevice stuff.

Here is a code snippet on how to do that:
https://github.com/olikraus/stm32g031/blob/main/enable_boot0/enable_boot0.c

I am willing to integrate this feature and issue a pull request, if you think, this is a good idea, however the following question arises: I think most of the source is pulled from Klipper upstream, right? Would I need to integrated this feature into Klipper and wait for it to trickle down into CanBoot, or can we make this adjustment in the CanBoot sourcecode? I think most users (with CAN boards) will use CanBoot as a bootloader (i.e. the first thing they will flash to the board), so CanBoot is (in my opinion) a good place to make this change to the option-bytes.

Hi,

I updated Raspbian 10 (buster) to Raspbian 11 (bullseye), for crowsnest compatibilities issues. But now Klipper is unable to connect to can mcu.
I'am using a RPi 3B, an octopus v1.1 (STM32F446) and a SB2040 (RP2040). Each MCU is connected via canbus.

pi@voron24:~ $ ifconfig
can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1024
pi@voron24:~/canboot/scripts $ python3 flash_can.py -i can0 -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 3f56a5b6c36c, Application: Klipper
Detected UUID: 2d70e57a001c, Application: Klipper
Query Complete

Everything is up-to-date in the mainsail update manager or in kiauh. machine.cfg is included in printer.cfg and containt both mcu parameters and adresses. But mainsail still can't connect to klipper.
I even tryed to reflash canboot on the octopus board. No success.
moonraker.log
klippy.log.json.txt (I add ".txt" for uploading)
machine.cfg.txt (which is imported in printer.cfg)
printer.cfg.txt

If I missed something, surely someone else will too. So, thank you for your help.

Mainsail config and errors :

EDIT: This turned out to be a issue with the BTT U2C v2.1, a new firmware was released which addresses this issue. I'm closing this out. Here is the link to the firmware which was posted by BTT below.

Firmware link:
https://github.com/Arksine/CanBoot/files/10410265/G0B1_U2C_V2.zip

Comment from BTT that solved this:
#44 (comment)

--------- Original post below ---------

Currently you can flash CanBoot onto the device and it's recognized over the CAN network, but then trying to flash Klipper, it ends with a bunch of errors during the flash and requires reflash in DFU mode.

I will try to get more details on the errors soon, when this first happened I thought I was just doing somethign wrong but others are also seeing this issue. Just wanted this as a placeholder for now and for awareness.

The board otherwise functions over CAN reliably if flashed with only Klipper via DFU.

Others who also experienced this:
https://www.youtube.com/watch?v=Ucq3U-H2N-A

EDIT: Seems to be an issue specifically with the BTT U2C v2.1, I was able to use Octopus Pro can bridge without issue.

Just rebuilt my system, can connection to huvud works well, but when i try and flash the newly made firmware to the huvud it doesn't seem to enter the bootloader and times out. This has worked in the past. Any insights? This is not all the output of the error, if you want it all, i will add it. I am hoping this is enough and its straightforward fix or a "i've been a muppet" ,

After this command, huvud is unresponsive until a power cycle

Thanks
James

pi@printpii:/CanBoot/scripts $ service klipper stop
pi@printpii:/CanBoot/scripts $ python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 46abbf984311
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 46abbf984311, Application: CanBoot
Attempting to connect to bootloader
ERROR:root:Can Read Error
Traceback (most recent call last):
File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
await self._wait_for_data('readuntil')
File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/home/pi/CanBoot/scripts/flash_can.py", line 137, in send_command
ret = await self.node.readuntil()
File "/home/pi/CanBoot/scripts/flash_can.py", line 287, in readuntil
return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
await self._wait_for_data('readuntil')
File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
await self._waiter
asyncio.exceptions.CancelledError`

I'm trying to do a serial flash over USB to a board already loaded and running klipper and it fails to drop into the CanBoot loader when I run the script. . I've done this in the past and it worked fine.. Tried it on 2 systems. My Pi4 and a Fly Pi.. both threw the same error. If I double tap the reset button to kick it into the CanBoot loader, grab the CanBoot USB serial ID and flash it will run fine.. See below for the errors.

pi@pi4:~ $ python3 ~/CanBoot/scripts/flash_can.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-Klipper_stm32f407xx_20003B001547393436343430-if00
Attempting to connect to bootloader
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/pi/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/pi/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/pi/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/pi/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/pi/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/pi/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for
    raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError
ERROR:root:Can Read Error
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/streams.py", line 632, in readuntil
    await self._wait_for_data('readuntil')
  File "/usr/lib/python3.9/asyncio/streams.py", line 517, in _wait_for_data
    await self._waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/tasks.py", line 492, in wait_for
    fut.result()
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/pi/CanBoot/scripts/flash_can.py", line 137, in send_command
    ret = await self.node.readuntil()
  File "/home/pi/CanBoot/scripts/flash_can.py", line 287, in readuntil
    return await asyncio.wait_for(self._reader.readuntil(sep), timeout)
  File "/usr/lib/python3.9/asyncio/tasks.py", line 494, in wait_for

this is truncated.. ask if you need more.

@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

Hello

i tried to set up ebb36 but I fail. I just saw it one time on my mainsail. After reboot it did not work .so I want to go without canbus. How do I flash back the octoboard to stok settings ?

I flashed CanBoot on my SKR 1.4 Turbo and noted some items:

Flashing Klipper

Building Klipper for the SKR 1.4 and having Smoothieware Bootloader enabled leads to:

ubuntu@ubuntu ~/klipper $ make flash FLASH_DEVICE=1d50:6177
  Flashing out/klipper.bin to 1d50:6177
sudo dfu-util -d ,1d50:6177 -D out/klipper.bin

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available

Failed to flash to 1d50:6177: Error running dfu-util

If flashing Klipper to a Smoothieboard for the first time it may be
necessary to manually place the board into "bootloader mode" - press
and hold the "Play button" and then press and release the "Reset
button".

When a Smoothieboard is in bootloader mode it can be flashed with the
following command:
  make flash FLASH_DEVICE=1d50:6015

Alternatively, one can flash a Smoothieboard via SD card - copy the
"out/klipper.bin" file to a file named "firmware.bin" on an SD card
and then restart the Smoothieboard with that SD card.

make: *** [src/lpc176x/Makefile:37: flash] Error 255

Flashing with ./lib/canboot/flash_can.py -d /dev/ttyACM0 works fine and board boots correctly

Building Klipper for the board but disabling the Smoothieware Bootloader leads to:

ubuntu@ubuntu ~/klipper $ make flash FLASH_DEVICE=/dev/ttyACM1
  Flashing out/klipper.bin to /dev/ttyACM1
Entering bootloader on /dev/ttyACM1
Device reconnect on /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.3/1-1.1.3:1.0
/usr/bin/python3 lib/canboot/flash_can.py -d /dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0 -f out/klipper.bin

/home/ubuntu/klipper/lib/canboot/flash_can.py:589: DeprecationWarning: There is no current event loop
  loop = asyncio.get_event_loop()
/home/ubuntu/klipper/lib/canboot/flash_can.py:271: DeprecationWarning: There is no current event loop
  self._reader = asyncio.StreamReader(CAN_READER_LIMIT)
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x4000
MCU type: lpc1769
Flashing '/home/ubuntu/klipper/out/klipper.bin'...

[##################################################]

Write complete: 8 pages
Verifying (block count = 455)...

[##################################################]

Verification Complete: SHA = AB01A6F5AAF2371766A1CD467074D86B86DACD0D
CAN Flash Success

Flashing succeeds but the board does not boot.

Flashing CanBoot with STLink and OpenOCD

ubuntu@ubuntu ~ $ sudo openocd -f interface/stlink.cfg -f board/mcb1700.cfg -c "program /home/ubuntu/CanBoot/out/canboot.bin verify exit"
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 10 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.254047
Info : lpc17xx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for lpc17xx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 10 kHz, using 5 kHz
Info : Unable to match requested speed 10 kHz, using 5 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Info : Unable to match requested speed 12500 kHz, using 4000 kHz
Info : Unable to match requested speed 12500 kHz, using 4000 kHz
** Programming Started **
Warn : Boot verification checksum in image (0x00000109) to be written to flash is different from calculated vector checksum (0xefff7b4a).
Warn : OpenOCD will write the correct checksum. To remove this warning modify build tools on developer PC to inject correct LPC vector checksum.
** Programming Finished **
** Verify Started **
Error: checksum mismatch - attempting binary compare
** Verify Failed **
shutdown command invoked

I'm by no means an OpenOCD expert and the command may be complete rubbish:

• The flashing seems to succeed and CanBoot is usable
• The Warning about the Checksum and the failed verification makes me nervous

When running octopus pro in can bridge mode.
I found that I can use canboot flash over canbus to trigger DFU mode on the octopus but not flash it over canbus. This however makes the octopus show up as a serial stm device in DFU mode, at which point I can just flash over serial. Once flashed it shows up as a can device again.

Is there a command or would it be possible to add a command to simply trigger DFU without attempting to flash?

This would be useful for scripting and avoiding all the errors that get generated by intentionally doing a failed flash over canbus, just to trigger the stm serial dfu mode.

Now that Klipper is able to support the STM32H723 we need canboot support for it also. Current board is Octopus Pro H723 variant.

I may not fully understand the command protocol in CanBoot, so let me know if I got something wrong. However, I didn't see a CRC check on commands and I'd be concerned about that.

It's possible for the canbus to reorder packets and/or drop some packets. We've seen some host adapters do this in practice. The fear is that a reordered data packet may subtly alter the flashed contents - the application (eg, Klipper) may actually even start and run with a subtle corruption like that, but is likely to cause hard to debug crashes.

Granted, the verification check should report a mismatch, but that check is also subject to reordering issues (that is it may spurious report failures even when the device is successfully flashed). I've been testing locally with an old innomaker can adapter that has this reordering problem and it consistently fails the verification check (but seems to generally write out correct images).

I'm not sure I fully understand the current command protocol, but I wonder if we could add a CRC. Maybe change the protocol to something like:
<0x6362746C><1-byte length><1-byte command><data><16-bit crc><etx>? In this proposal both args and block data would be contained within the command message. I'm proposing a 16-bit crc just because it's easy to grab that from the current Klipper code. This would also fix a block size of 64 bytes (or at least, one not larger than about 250 bytes).

I'd also suggest sending the flash write address with every flash block to avoid possible issues with dropped messages. May also be useful for the ack message to state what command and address is being acknowledged.

A CRC check would also make it easier to support flashing over UART instead of CAN. (Several users with stm32 and rp2040 boards have requested that feature and it shouldn't be too hard to extend the code to support Klipper's UART handlers instead of CAN.)

Thoughts?
-Kevin

I bought a whole stack of EBB42s when they were on sale on AliExpress. I can't even remember how many. Like 10-15 units. I have flashed a couple and they work, but I want to flash all of them at once and be done with it.

Is it possible to somehow conjoin a Katapult image and a Klipper image built for the same target device and flash them both at once over USB? As it stands it seems like the workflow is to flash Katapult to them, set up a temporary Can network, connect the EBB42s to this temporary can net, get the uuid, then flash Klipper to it.

It would be neat to compile Katapule, compile Klipper, cat the two images together, flash once, and be done.

Add a user-definable device name that will be provided with the CAN bus ID when running flash_can.py -q
Since the direction for using the CAN bus will head toward multiple print heads, this will help debug and update these devices.

Example output
pi@Fluidd:~ $ python3 /home/pi/CanBoot/scripts/flash_can.py -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 93499ef89c38, Application: Klipper, Device: Octopus Pro
Detected UUID: a0c90a3740c9, Application: Klipper, Device: Hermit Crab 1
Detected UUID: a0c90a3740d3, Application: Klipper, Device: Hermit Crab 2
Detected UUID: a0c90a3740f9, Application: Klipper, Device: Hermit Crab 3
Query Complete

I'm getting this error when I flash klipper with a 16k offset using the canbus.

The board has a fast flashing led (very fast) and doesn't seem to work after the flash.

Flashing klipper without canboot work fine.

pi@voron:~/CanBoot/scripts $ python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 3799962ca524
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 3799962ca524, Application: CanBoot
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x10004000
MCU type: rp2040
Verifying canbus connection
Flashing '/home/pi/klipper/out/klipper.bin'...

[###################################ERROR:root:Can Flash Error
Traceback (most recent call last):
File "flash_can.py", line 483, in run
await flasher.send_file()
File "flash_can.py", line 214, in send_file
resp = await self.send_command('SEND_BLOCK', prefix + buf)
File "flash_can.py", line 194, in send_command
% (cmdname))
FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "flash_can.py", line 628, in main
loop.run_until_complete(sock.run(intf, uuid, fpath, req_only))
File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
return future.result()
File "flash_can.py", line 489, in run
await flasher.finish()
File "flash_can.py", line 272, in finish
await self.send_command("COMPLETE")
File "flash_can.py", line 194, in send_command
% (cmdname))
FlashCanError: Error sending command [COMPLETE] to Can Device

Hi,

I tested the bootloader with a GD32F103. Flashing a firmware worked, but an error occurred during verification. The firmware was flashed successfully anyway.

I found the problem in the canbus_send() function. Apparently the CODE[1:0] bits in the CAN_TSR register of the GD32F103 are not working as described in the datasheet. If a message longer than 8 bytes is sent and thus more than one transmit mailbox should be used at the same time, mailbox 0 was always given back as the next free mailbox via CODE[1:0], even if it was currently in use.

The problem can be solved by using the TME0, TME1 and TME2 bits to determine the next free mailbox:

// Transmit a packet
int
canbus_send(uint32_t id, uint32_t len, uint8_t *data)
{
    uint32_t tsr = SOC_CAN->TSR;
    if (!(tsr & (CAN_TSR_TME0|CAN_TSR_TME1|CAN_TSR_TME2))) {
        // No space in transmit fifo - enable tx irq
        irq_disable();
        SOC_CAN->IER |= CAN_IER_TMEIE;
        irq_enable();
        return -1;
    }
#if 0
    int mbox = (tsr & CAN_TSR_CODE) >> CAN_TSR_CODE_Pos;
#else
    int mbox;

    if((tsr & (CAN_TSR_TME0)))
      mbox = 0;
    else if((tsr & (CAN_TSR_TME1)))
      mbox = 1;
    else
      mbox = 2;

#endif

    CAN_TxMailBox_TypeDef *mb = &SOC_CAN->sTxMailBox[mbox];

Is it possible to add this bugfix for the GD32F103 and make it available via a Kconfig option?