Flashing over CAN not working with Big Tree Tech EBB36 v1.2 from BTT U2C v2.1

[Norbs12]

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: https://github.com/Arksine/CanBoot/issues/44#issuecomment-1381555466

--------- 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.

[rbrtwtrs]

Same for me but using a Huvud 6.1 board. Term resistors are reading 60 Ohms and connection seems fine since it gets UUID.

pi@voron:~/klipper/lib/canboot $ python3 flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 2d96b9a09c30 Sending bootloader jump command... Resetting all bootloader node IDs... Checking for canboot nodes... Detected UUID: 2d96b9a09c30, Application: CanBoot Attempting to connect to bootloader 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 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 603, 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 467, in run await flasher.connect_btl() File "flash_can.py", line 89, in connect_btl ret = await self.send_command('CONNECT') File "flash_can.py", line 187, in send_command % (cmdname)) FlashCanError: Error sending command [CONNECT] to Can Device pi@voron:~/klipper/lib/canboot $

[NAPCAL]

Chime in if you are using a U2C, and if so, what version, V1-STM32F072 or V2-STM32G0B1

I have the STM32F072 without this issue, but I do know of another user that has the STM32G0B1 that has this issue.

[Norbs12]

BTT U2C v2.1 (STM32G0B1) and BTT EBB36 CAN v1.2 (STM32G0B1)

[ChipTheCat]

U2C v2.1 with EBB42 v 1.2 both G0B1 chips. Flashed over DFU and seams to be working. Had to send cmd's sudo ifdown can0 sudo ifup can0 then ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0 to get a uuid otherwise id just get 0 uuid.

[Norbs12]

For the people having issues, can you try and follow this guide with all the exact settings? (only thing i did different is 250000 instead of 500000)

https://maz0r.github.io/klipper_canbus/toolhead/ebb36-42_v1.1.html

I was trying to reproduce the issue and it actually worked on hardware that didn't work before.

[rbrtwtrs]

I tried both 500000 and 250000, followed the guide verbatim. Tried different offsets etc. Nothing worked.

[rbrtwtrs]

I'm giving up on the Canbus mod. Way more trouble than it saves in wiring. Huvud board is too big to fit anywhere on a Stealthburner anyway. Disappointing waste of $

[NAPCAL]

I'm giving up on the Canbus mod. Way more trouble than it saves in wiring. Huvud board is too big to fit anywhere on a Stealthburner anyway. Disappointing waste of $

Robert, if you don't mind, are you trying to use the BTT U2C?

If so, please comment with the STM32 version on yours; thanks.

[rbrtwtrs]

I am using a Huvud 6.1 board with an STM32F103C8T6. Latest version w CANBOOT pre installed. CAN interface is a Waveshare RS485 CAN Hat w a RasPi4. Did not have an ST-Link to try re-flashing the CAN bootloader and I have decided to quit screwing with it and just go with direct wires.

[Norbs12]

So I think I managed to track the issue down to something with possibly the Pi4 (or my specific Pi4).

I'm basically at the point where I can replace my Pi4 with a Pi3 (only changing the Pi, keeping same SD card and everything else connected) and make it work.

Don't think there is any issue with my Pi4 as everything else is stable, but I plan on trying to swap that with another and keep testing.

UPDATE: Tried another Pi4 and same issue.

Not sure if it helps anyone but here is the full error when it fails on my Pi4:

python3 /home/pi/klipper/lib/canboot/flash_can.py -i can0 -f ~/klipper/klipper-ebb36.bin -u 505bd1db8c4c Sending bootloader jump command... Resetting all bootloader node IDs... Checking for canboot nodes... Detected UUID: 505bd1db8c4c, 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/klipper-ebb36.bin'...

[#ERROR:root:Can Read Error Traceback (most recent call last): File "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/klipper/lib/canboot/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/klipper/lib/canboot/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/klipper/lib/canboot/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/klipper/lib/canboot/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/klipper/lib/canboot/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 137, in send_command ret = await self.node.readuntil() File "/home/pi/klipper/lib/canboot/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 "/home/pi/klipper/lib/canboot/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/klipper/lib/canboot/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 603, 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 "/home/pi/klipper/lib/canboot/flash_can.py", line 475, in run await flasher.finish() File "/home/pi/klipper/lib/canboot/flash_can.py", line 265, in finish await self.send_command("COMPLETE") File "/home/pi/klipper/lib/canboot/flash_can.py", line 187, in send_command % (cmdname)) FlashCanError: Error sending command [COMPLETE] to Can Device

[NAPCAL]

In another issue post when the EBB's changed to STM32G0B1 when asking about CAN-FD that G0B1 provides and if we needed to upgrade our CAN bus devices to CAN-FD; Arksine responded that the CanBoot for the G0B1 would use the basic CAN bus protocol and not the FD protocol, so no update needed.

Klipper seems to support both basic & FD on the G0B1. Still, the overall bus has to use the same protocol, so the newer U2C with the G0B1 is more than likely setting up for FD and will not fully talk to CanBoot in basic CAN mode, like binary file transfer of the Klipper firmware but can retrieve UUID's from devices running basic CAN.

[Norbs12]

Alright my last update. Seems like this is some kind of interaction between the Pi4 and the BTT U2C v2.1.

Since I have a Octopus Pro, I ended up just using the onboard can bridge and I don't have anymore issues with the same can toolhead.

[Cova]

I'm also experiencing this issue - canboot and klipper are both flashed via USB, and klipper is working, but attempting to flash over CAN corrupts something, and then you have to start over from scratch with DFU again.

Running the U2C v2.1 and EBB36 v1.2 - both on G0B1 chips, and all connected to a CB1 mounted on a Manta MP8.

Not sure if its related - but I also cannot use the ADXL on my EBB. The moment I enable that section of the klipper config, klipper fails to start. Kinda seems like anything high-bandwidth is having issues? Or maybe its unrelated.

[akhamar]

Same problem here with a Pi4 and an octopus 1.1

master ✔ $ ip a
...
8: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 128
    link/can

master ✔ $ python3 flash_can.py -i can0 -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: c2ecdf459ba5, Application: Klipper
Query Complete

If I try a second time the can device is not present anymore.

master ✔ $ python3 flash_can.py -i can0 -q
Resetting all bootloader node IDs...
Checking for canboot nodes...
Query Complete

If I try to flash klipper over can I get the following.

master ✔ $ python3 flash_can.py -i can0 -u c2ecdf459ba5 -f ~/firmware/octopus_1.1_klipper.bin
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
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 458, in run
id_list = await self._query_uuids()
File "flash_can.py", line 406, in _query_uuids
resp = await self.admin_node.readexactly(8, diff)
File "flash_can.py", line 282, in readexactly
return await asyncio.wait_for(self._reader.readexactly(n), timeout)
File "/usr/lib/python3.7/asyncio/tasks.py", line 416, in wait_for
return fut.result()
File "/usr/lib/python3.7/asyncio/streams.py", line 677, in readexactly
raise IncompleteReadError(incomplete, n)
asyncio.streams.IncompleteReadError: 0 bytes read on a total of 8 expected bytes

And klipper itself also crash

I can properly flash with the serial usb for the first klipper flash. python3 flash_can.py -f ~/firmware/octopus_1.1_klipper.bin -d /dev/serial/by-id/usb-CanBoot_stm32f446xx_170038000650314D35323820-if00

But after klipper with can is flashed, I can no longer use the serial usb as only the can0 interface is available.

Also note that doing a power cycle put everything back in working condition.

[akhamar]

Some complementary info :

• octopus 1.1 STM32F446
• latest version of klipper
• latest version of canboot
• klipper configured as USB to CAN bus bridge (USB on PA11/PA12) and CAN bus (on PD0/PD1)

It is the octopus 1.1 board itself that I'm trying to update, not the toolhead.

[akhamar]

After some more test, I get the following.

master ✔ $ python3 flash_can.py -i can0 -u c2ecdf459ba5 -f ~/firmware/octopus_1.1_klipper.bin                                                                                                  130 ↵
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
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 458, in run
    id_list = await self._query_uuids()
  File "flash_can.py", line 406, in _query_uuids
    resp = await self.admin_node.readexactly(8, diff)
  File "flash_can.py", line 282, in readexactly
    return await asyncio.wait_for(self._reader.readexactly(n), timeout)
  File "/usr/lib/python3.7/asyncio/tasks.py", line 416, in wait_for
    return fut.result()
  File "/usr/lib/python3.7/asyncio/streams.py", line 677, in readexactly
    raise IncompleteReadError(incomplete, n)
asyncio.streams.IncompleteReadError: 0 bytes read on a total of 8 expected bytes

While the flash fail, it appear that the board itself restart and start on the bootloader itself.

Oct 29 00:58:33 mainsailos kernel: [ 6458.109661] usb 1-1.2: USB disconnect, device number 34
Oct 29 00:58:33 mainsailos kernel: [ 6458.109858] gs_usb 1-1.2:1.0 can0: Couldn't shutdown device (err=-19)
Oct 29 00:58:33 mainsailos kernel: [ 6458.443138] usb 1-1.2: new full-speed USB device number 35 using xhci_hcd
Oct 29 00:58:33 mainsailos kernel: [ 6458.589189] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=6177, bcdDevice= 1.00
Oct 29 00:58:33 mainsailos kernel: [ 6458.589210] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 29 00:58:33 mainsailos kernel: [ 6458.589226] usb 1-1.2: Product: stm32f446xx
Oct 29 00:58:33 mainsailos kernel: [ 6458.589241] usb 1-1.2: Manufacturer: CanBoot
Oct 29 00:58:33 mainsailos kernel: [ 6458.589256] usb 1-1.2: SerialNumber: 170038000650314D35323820
Oct 29 00:58:34 mainsailos kernel: [ 6458.596299] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

The board is now available as a serial usb device and can be flashed with

master ✔ $ python3 flash_can.py -f ~/firmware/octopus_1.1_klipper.bin -d /dev/serial/by-id/usb-CanBoot_stm32f446xx_170038000650314D35323820-if00                                               130 ↵
Attempting to connect to bootloader
CanBoot Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8008000
MCU type: stm32f446xx
Flashing '/home/pi/firmware/octopus_1.1_klipper.bin'...

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

Write complete: 2 pages
Verifying (block count = 446)...

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

Verification Complete: SHA = 5BF4BBAF365293CB52CB338FD720F766B16B1EF1
CAN Flash Success

The board restart immediately on klipper with the can0 interface working.

Oct 29 01:01:10 mainsailos kernel: [ 6615.572625] usb 1-1.2: USB disconnect, device number 35
Oct 29 01:01:11 mainsailos kernel: [ 6615.866358] usb 1-1.2: new full-speed USB device number 36 using xhci_hcd
Oct 29 01:01:11 mainsailos kernel: [ 6616.007819] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
Oct 29 01:01:11 mainsailos kernel: [ 6616.007829] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 29 01:01:11 mainsailos kernel: [ 6616.007837] usb 1-1.2: Product: stm32f446xx
Oct 29 01:01:11 mainsailos kernel: [ 6616.007844] usb 1-1.2: Manufacturer: Klipper
Oct 29 01:01:11 mainsailos kernel: [ 6616.007851] usb 1-1.2: SerialNumber: 170038000650314D35323820
Oct 29 01:01:11 mainsailos kernel: [ 6616.012563] gs_usb 1-1.2:1.0: Configuring for 1 interfaces
Oct 29 01:01:11 mainsailos kernel: [ 6616.186506] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

[NAPCAL]

The issue called out is issues flashing the EBB42 with CanBoot.

Flashing the Octopus (when using it as a CAN bus bridge, Klipper), you will not be able to do this because CanBoot doesn't support the CAN bus bridge mode.

When trying to flash using CanBoot via CAN bus will not work because Klipper on the MCU will not be running; therefore, the CAN bus bridge will not be running.

So you will always be required to use the USB to flash CanBoot or Klipper CAN bus bridge.

If you were using a CAN hat or USB to CAN bus adapter, you would be able to flash over the CAN bus.

[akhamar]

Ok I though the problematic was the same, but as you said it's definitely something else. And you are probably right, since the octopus is in bridge mode.

[NAPCAL]

When having to flash via USB, CanBoot will have a different USB ID than Klipper.

If you setup CanBoot with the quick double click of the reset to jump into firmware loading. Then quick double click the reset will get you into that mode.

Then using the CanBoot USB ID, you can flash the Octopus with Klipper.

I store my CanBoot ID in my printer.cfg as a comment for easy access.

[NAPCAL]

I was going to try to flash the U2C V2 (STM32G0B1) with Klipper in CAN bus bridge mode to see if this would correct the issue, but BTT is using (PB5 RX and PB6 TX), and these are not selectable CAN bus pins under Klipper.

As I see it right now, it is a common issue with U2C V2 and CanBoot, there is no issues with the U2C V1's.

[jmeier5261]

Confirming I had the same issue using G0B1_U2C_fw on my u2c v2.1 with ebb36 v1.2, the firmware transfer itself fails and then the canboot ebb becomes non responsive until I re program with cube programmer. issue not observed with U2C v1.1

[e2p2]

I can confirm that the issue occurred with U2C 2.1 but not with the 1.0. I had the U2C 2.1 on two different printers, both with EBB36 1.2, and had issues with flashing and using canbus speeds above 250k. Switched both to U2C v1. 0 and was able to flash without issue and run 1MB canbus speed.

[Arksine]

It sounds like the STM32G0 variants of the U2C cant handle the somewhat larger transfers required to upload firmware...in fact it appears that these devices have general communications issues.

There does appear to be a fork of CandleLight for the G0. If someone is feeling adventurous you could try following these instructions to build and flash it to a U2C v2.1.

[jmeier5261]

It sounds like the STM32G0 variants of the U2C cant handle the somewhat larger transfers required to upload firmware...in fact it appears that these devices have general communications issues.

There does appear to be a fork of CandleLight for the G0. If someone is feeling adventurous you could try following these instructions to build and flash it to a U2C v1.1.

I have a spare u2c v2.1 and ebb36 v1.2. I’ll try the above and report back

[e2p2]

I've tried the candlelight fork on a U2C 2.1 and it didn't help,. That fork hasn't been updated in 5 months.

[Arksine]

If candlelight doesn't work I added 100% untested support for pins PB5 and PB6 to Klipper here. You can add my fork as a Klipper remote and checkout the dev-stm32g0-can-pins branch, configure and build Klipper in USB to CanBridge mode, then flash the U2C V2.1.

Note: I suspect that this would require adding the U2C V2.1 as an mcu in printer.cfg to work.

[NAPCAL]

I think the issue is with the BTT U2C V2 firmware trying to use FDCAN for file transfers or not settling this up correctly since the rest of the bus is non-FD.

It seems to be only with binary data transfers, all other communications works.

[garrettwp]

If candlelight doesn't work I added 100% untested support for pins PB5 and PB6 to Klipper here. You can add my fork as a Klipper remote and checkout the dev-stm32g0-can-pins branch, configure and build Klipper in USB to CanBridge mode, then flash the U2C V2.1.

Note: I suspect that this would require adding the U2C V2.1 as an mcu in printer.cfg to work.

I tried flashing the U2C 2.1 board with klipper in usb to can bridge using your fork. I could not get it to see anything on the can network. Since BTT has not published the code for the u2c 2.1 board, it makes it hard to see what they used / changed. I suspect that the U2C 2.1 board is using FDCAN which is causing the transfer issues that NAPCAL mentioned.

[Rick88Stang]

I seem to be having the same issue with the U2C 2.1 and EBB42 v1.1. Was going to send back my EBB thinking it was bad (got it already opened from amazon) but if I'm reading the comments right it is a problem with the U2C, is that correct?

My PI4 recognizes everything all the way up to flashing Klipper then I get the following error. After I get 0 UUIDs found until I reinstall canboot.

`pi@fluiddpi:~/klipper $ python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 793da0714a5e Sending bootloader jump command... Resetting all bootloader node IDs... Checking for canboot nodes... Detected UUID: 793da0714a5e, 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'...

[####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 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 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 Flash Error Traceback (most recent call last): File "/home/pi/CanBoot/scripts/flash_can.py", line 469, in run await flasher.send_file() File "/home/pi/CanBoot/scripts/flash_can.py", line 207, in send_file resp = await self.send_command('SEND_BLOCK', prefix + buf) File "/home/pi/CanBoot/scripts/flash_can.py", line 186, in send_command raise FlashCanError("Error sending command [%s] to Can Device" FlashCanError: Error sending command [SEND_BLOCK] to Can Device

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/home/pi/CanBoot/scripts/flash_can.py", line 609, in main loop.run_until_complete(sock.run(intf, uuid, fpath)) File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete return future.result() File "/home/pi/CanBoot/scripts/flash_can.py", line 475, in run await flasher.finish() File "/home/pi/CanBoot/scripts/flash_can.py", line 265, in finish await self.send_command("COMPLETE") File "/home/pi/CanBoot/scripts/flash_can.py", line 186, in send_command raise FlashCanError("Error sending command [%s] to Can Device" FlashCanError: Error sending command [COMPLETE] to Can Device `

[NAPCAL]

Yes, it is an issue only with the U2C V2.x G0B1 and binary transfers.

[NAPCAL]

If candlelight doesn't work I added 100% untested support for pins PB5 and PB6 to Klipper here. You can add my fork as a Klipper remote and checkout the dev-stm32g0-can-pins branch, configure and build Klipper in USB to CanBridge mode, then flash the U2C V2.1.

Note: I suspect that this would require adding the U2C V2.1 as an mcu in printer.cfg to work.

@Arksine Thanks, I will try the branch in a couple of weeks when I return home from my current work trip.

[e2p2]

I just tried the dev-stm32g0-can-pins fork as well. I can apply canboot and flash the forked version of klipper, using either pb5/6 or pb8/9 in usb to can bridge mode, to the u2c 2.1. Neither connect to the ebb36 or show up in mainsail.

[NAPCAL]

Did you add the U2C as an additional MCU as @KevinOConnor recommended?

[e2p2]

I did.

[NAPCAL]

@Arksine I tried your branch of Klipper on the U2C G0B1 that I have, but no joy. What I see is that Klipper is setting up for FDCAN, and the CAN bus transceiver is not an FDCAN type (SN65HVD1050DR); this is the same hardware as on the EBB (STM32G0B1). The basic commands work, but the binary file (firmware) transfer fails.

The SKR3 & SKR3 EZ boards have (MCP2561FD-HISN) CAN-FD transceivers on those boards and had no issues with them on a non-FD bus since the spec for these state CAN 2.0 & CAN-FD.

I have a handful of MCP2561FD-HISN on order, and it should get to me late next week that I will swap out the chips (non-FD for FD). This should make this adaptor an FDCAN.

Any chance you could alter your branch of Klipper (dev-stm32g0-can-pins) to use non-FD CAN code, I am sure you did this on CanBoot when the EBB G0B1 just came out.

[Arksine]

CanBoot's platform specific source is a very close port of Klipper's, in fact recent changes have made it near identical. Functionally they are equivalent. Neither Klipper nor CanBoot use the CAN FD protocol. The stm32g0 has a CAN peripheral that supports both CAN FD and CAN 2.0. CanBoot and Klipper use in the CAN 2.0 mode. I think what may be confusing is that the platform specific source for stm32 devices has a can.c and fdcan.c. Note that both of these use CAN 2.0 mode. Some stm32 variants have an older peripheral that only supports CAN 2.0 which is implemented in can.c, whereas the newer stm32 variants use the new peripheral implemented in fdcan.c. As mentioned above, both use the CAN 2.0 protocol.

If the basic commands work with the branch but the binary transfer fails I'm left to wonder if there is a hardware issue.

[NAPCAL]

@Arksine There are no issues with BTT U2C V1 (F072) with CanBoot firmware or bootloader updating of CAN bus devices, but the BTT U2C V2 (G0B1) the STM is the only hardware change, and branched Candlelight firmware for the (G0B1).

I have tried the Klipper branch you altered to allow pins PB5 & PB6; it sees only the U2C with the CanBoot and Klipper scripts, even when an EBB42 (G0B1 & CanBoot) is connected.

I have ohmed out the traces from PB5 & PB6 to the CAN bus transceiver to ensure there was no schematic error.

[Arksine]

@NAPCAL I need a bit of clarity on the issue. Previously you indicated the following with the G0 CAN Bridge Branch:

The basic commands work, but the binary file (firmware) transfer fails.

In your latest post, you indicate:

it sees only the U2C with the CanBoot and Klipper scripts, even when an EBB42 (G0B1 & CanBoot) is connected.

Did the bridge previously work for basic commands (ie: query), and now its not working?

I think that regardless this issue is clearly a problem with the U2C v2.1, not CanBoot. My inclination is to modify the Readme to recommend against using this device until BTT resolves it.

[NAPCAL]

@Arksine, Sorry, but I now cannot reproduce this failure, does any part of CanBoot utilize dfu-util? The version installed on the Debian release is the 0.9 ver; I have downloaded an updated to 0.11.

Checks I have done currently. Loading Klipper firmware over the CAN bus using CanBoot. Your Klipper dev-stm32g0-can-pins, latest Moonraker, latest Fluidd <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

  | EBB42 G0B1 |   | EBB42 F072 |   -- | -- | -- | -- | --   | USB-C (CAN) | CAN connector | USB-C (CAN) | CAN connector U2C F072
BTT firmware | Success | Success | Success | Success U2C G0B1
BTT firmware | Success | Success | Success | Success U2C G0B1 CAN bridge | Fail (sees only the bridge UUID once) | Fail (sees only the bridge UUID once) | Fail (sees only the bridge UUID once) | Fail (sees only the bridge UUID once)

I haven't scoped the CAN bus when trying the Klipper CAN bridge dev-stm32g0-can-pins. But I have rechecked quite a few times and confirmed that the bus pins are PB6/PB5 going to the CAN bus transceiver. Unlessa GPIO assignment is not happening to set these I/O to be used for FDCAN2, then I am not sure what's going on with the bridge mode.

P.S. The Klipper CAN bridge will not work on the STM32F072; I would guess it cannot use the USB and CAN simultaneously.

[Arksine]

CanBoot does not use dfu-util. It sounds like something is wrong with the dev-stm32-can-pins branch, however I'm not currently in a position to debug it. I'll take a look at it to see if I missed something obvious when I get a chance.

I did not realize that the stock U2C v2.1 firmware was working for you. When reading through this issue, perhaps the problem only occurs on a Pi 4? If that is the case it indicates a USB issue.

Edit: I updated the readme to indicate that the device may work, however it is not consistent.

[NAPCAL]

@Arksine Maybe a dependency that got updated with the new version of dfu-util?

It would fail repeatedly when I only had dfu-util v0.9

[NAPCAL]

@Arksine

Did the bridge previously work for basic commands (ie: query), and now its not working?

It did not work because it never shows any UUIDs but the bridge, never any CAN devices connected to it. If I said it did, I was mistaken, only thinking that the UUID showing was the device connected, not the bridge.

[NAPCAL]

Update: I have completely reinstalled the Debian 11 bullseye, updated apt, upgraded apt, installed kiauh, set the Arksine Klipper dev-stm32g0-can-pins, used kiauh to install klipper, moonraker, and fluidd. Setup the CAN bus.

Using a U2C V2.1 G0B1 with BTT U2C_V2_STM32G0B1.bin firmware and an EBB42 V1.2 G0B1 with CanBoot loaded. I had no issues using CanBoot to load klipper firmware to the EBB.

After this, I put the EBB in DFU mode and used dfu-util to load CanBoot with this command sudo dfu-util -a 0 -D ~/CanBoot/out/canboot.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11

This flashed it with CanBoot and reset it so it would be back on the Can bus. I tried using CanBoot to load klipper firmware a second time and didn't run into any failures.

Unfortunately, I can't reproduce the failure that I had previously. If you have this problem with the U2C, EBB, and CanBoot, please ensure you are running Bullseye. sudo apt update sudo apt dist-upgrade -y if any errors show, try without the -y

[bigtreetech]

G0B1_U2C_V2.zip

For users who encounter the canboot programming problem of U2C V2 version , please update the firmware of U2C V2 to this file for testing. This file is a compressed file. After decompression, there will be a .bin binary file, which can be directly programed to U2C V2 by DFU

@Rick88Stang Hello. can you test this?

[garrettwp]

G0B1_U2C_V2.zip

For users who encounter the canboot programming problem of U2C V2 version , please update the firmware of U2C V2 to this file for testing. This file is a compressed file. After decompression, there will be a .bin binary file, which can be directly programed to U2C V2 by DFU

@Rick88Stang Hello. can you test this?

I tested this out and it works!

python3 ~/CanBoot/scripts/flash_can.py -i can0 -f ~/klipper/out/klipper.bin -u 8f43f757d80e
Sending bootloader jump command...
Resetting all bootloader node IDs...
Checking for canboot nodes...
Detected UUID: 8f43f757d80e, 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/garrett/klipper/out/klipper.bin'...

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

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

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

Verification Complete: SHA = 487D7BCFCC1B426628445F29D306DCB7B415CB05
CAN Flash Success

[garrettwp]

For anyone who wants to reproduce this.

1. Download the file from bigtreetech comment.
2. Stop klipper sudo systemctl stop klipper
3. Bring down the can interface sudo ifdown can0
4. Unzip the firmware file from bigtreetech
5. Unplug the u2c controller from usb
6. Press and hold the boot button on the u2c and plug the usb cable back in, then release the boot button.
7. Verify that the u2c is in dfu mode dfu-util -l You should see lines that contain Found DFU: [0483:df11]
8. Flash the new firmware to the u2c dfu-util -D G0B1_U2C_V2.bin -d 0483:df11 -a 0 -s 0x08000000:leave
9. Unplug and replug in the usb cable for the u2c to reset it
10. The CAN interface should now be back up
11. Follow the steps to compile and flash canboot to the EBB
12. Follow the steps to compile and flash klipper over CAN
13. Success

[NAPCAL]

@garrettwp revise step 6 (see below); the U2C’s don’t have a reset button; it is a boot button.

Press and hold the boot button on the u2c and plug the usb cable back in, then release the boot button.

[garrettwp]

Thanks for the catch! I have updated it.

[EricZimmerman]

confirming this worked. flashed u2c with attached firmware per directions. CANBOOT'ed ebb36 1.2 flashed klipper via CANBOOT to ebb

everything is up

[e2p2]

@bigtreetech, can you supply any details about what was changed in the supplied firmware? Perhaps a link to the source?