Unable to flash klipper on EBB42 using CAN

[valan77]

Basic Information:

Printer Model: CM4 on BTT-PAD7
MCU / Printerboard: skr 1.4 Turbo
klippy.log - not needed.

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Hi there,
I’m trying to get klipper to flash on the BTT EBB 42 1.2 via using canboot over canbus. I keep getting a “Error sending command [CONNECT] to Can Device” error when trying to flash. The “Attempting to connect to bootloader” command takes a few seconds. All details below. Any idea what I might be doing wrong?

I am using a BTT PAD 7 with CM4 installed. The CAN configuration is selected correctly (have completed a resonance test with the supplied ADXL345 over SPI.

I have flashed canboot following the instructions here. CanBoot (optional) - Klipper Misc Docs. That seemed to work successfully (blinking blue led).

After flashing I disconnected the USB from the pi (moved it to a brick), connected the CAN interface (H to H, L to L), jumpered the 120ohm jumper. When plugged it all in.

When I query the CAN network, I get a UUID per below. That tells me that CAN communication is working.
Tried to flash klipper several times over CAN but got the same errors below. I thought I’d try to just update canboot over CAN (in case I was doing something very wrong)

Setting from my pi:
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 (UNSPEC)
RX packets 39 bytes 264 (264.0 B)
RX errors 8 dropped 0 overruns 0 frame 8
TX packets 24 bytes 134 (134.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

biqu@btt-pad7:~/katapult/scripts $ cat /etc/network/interfaces.d/can0
allow-hotplug can0
iface can0 can static
bitrate 1000000
up ifconfig $IFACE txqueuelen 1024

my menuconfig options

Katapult Configuration v0.0.1-64-g3e23332
Micro-controller Architecture (STMicroelectronics STM32)  --->
Processor model (STM32G0B1)  --->
Build Katapult deployment application (8KiB bootloader)  --->
Clock Reference (8 MHz crystal)  --->
Communication interface (CAN bus (on PB0/PB1))  --->
Application start offset (8KiB offset) 
(1000000) CAN bus speed  
()  GPIO pins to set on bootloader entry
[*] Support bootloader entry on rapid double click of reset button
[ ] Enable bootloader entry on button (or gpio) state  
[*] Enable Status LED
(PA13)  Status LED GPIO Pin

Commands and error messages below

biqu@btt-pad7:~/katapult/scripts $ python3 flashtool.py -i can0 -q
Resetting all bootloader node IDs...
Checking for Katapult nodes...
Detected UUID: 4220d6e9e9f9, Application: Katapult
Query Complete
biqu@btt-pad7:~/katapult/scripts $ python3 ~/katapult/scripts/flash_can.py -f ~/katapult/out/canboot.bin -i can0 -u 4220d6e9e9f9
Sending bootloader jump command...
Resetting all bootloader node IDs...
Attempting to connect to bootloader
ERROR:root:Flash Error
Traceback (most recent call last):
  File "/home/biqu/katapult/scripts/flash_can.py", line 626, 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/biqu/katapult/scripts/flash_can.py", line 479, in run
    await flasher.connect_btl()
  File "/home/biqu/katapult/scripts/flash_can.py", line 90, in connect_btl
    ret = await self.send_command('CONNECT')
  File "/home/biqu/katapult/scripts/flash_can.py", line 196, in send_command
    raise FlashCanError("Error sending command [%s] to Can Device"
**FlashCanError: Error sending command [CONNECT] to Can Device**

edit: fixed code blocks

[hcet14]

How is your BTT EBB 42 1.2 connected? What is the second CAN bus node?

[valan77]

No sure what you mean by second canbus node? I’m using a Pad 7 with CAN and SPI ports on it. After supposedly flashing Klipper, when I query for canbus nodes I get nothing. (see below)

biqu@btt-pad7:~ $ ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
Total 0 uuids found

if I put it back in DFU mode on USB, I get the results above way above. (DFU mode seems to work fine for flashing canboot)

After flashing the boot loader, configured for CAN interface, connecting the CAN lines and running on a brick for power (so not a USB device in any way),

biqu@btt-pad7:~ $ python3 ~/CanBoot/scripts/flash_can.py -i can0 -q
Resetting all bootloader node IDs…
Checking for Katapult nodes…
Detected UUID: 4220d6e9e9f9, Application: Katapult
Query Complete

but when I try to flash klipper over CAN, I get the CONNECT error. I’m thinking I need to find a way to try to manually connect to the CAN interface. As far as I can tell the comm speed is the same in all the places.

[hcet14]

@valan77

I’m using a Pad 7 with CAN

Sorry, I didn’t know BTT PAD7 Pad7/Hardware/BIGTREETECH PD7 V1.0-SCH.pdf at master · bigtreetech/Pad7 · GitHub has CAN. So BTT PAD7 is your second CAN bus node.

I’m out of this. You might ask here GitHub - Arksine/katapult: Configurable bootloader for Klipper. I would open a new issue.

Good luck, hcet14

[valan77]

Thanks. Already have an issue open. I’ll post back here if/when this get resolved.

Sigh. It’s irritating. In the time I’ve spent trying this fancy toolboard idea, I could have simply wired up my printer with all the components directly.

[hcet14]

@valan77

I’ve spent trying this fancy toolboard idea, I could have simply wired up my printer with all the components directly.

I believe in CAN, less weight. Right now it’s just CAN. I wish CAN FD would be implemented to Klipper GitHub - marckleinebudde/candleLight_fw at multichannel.

@marckleinebudde Is doing a fabulous job!

[valan77]

That is some pretty cool stuff. I would have gone with a usb2can board, but my Pad7 came with a CAN port, and in the docs they show it connecting to an ebb36 directly.

This bugs me because it would take BTT all of like 1 day to write up a definitive guide on how to get these things working together. They have all the information, and 3d printer experience, so why make all of us suffer? It’s laziness, not cost. The effort would be low compared to the revenue they’d generate by getting huge portions of the 3d printing community to move over. Sigh. Rant over, for now.

[docgalaxyblock]

Hi, I am the coop writer of the CAN guide you used.
I do not have any experience with SPI-CAN chips like the MCP2515 in the PAD7 (I also did not know that it supports CAN) yet…

@valan77

I am using a BTT PAD 7 with CM4 installed. The CAN configuration is selected correctly (have completed a resonance test with the supplied ADXL345 over SPI.

The BTT mentions that you cannot use ADXL and CAN at the same time:
Note: It is not possible to use the CAN interface and the ADXL345 accelerometer SPI interface simultaneously due to the MCP2515 SPI to CAN conversion.
Is that the case in your setup?

EDIT: It would be great if you can please fix the formatting of your posts (use and repair the codeblocks for terminal stuff).

[valan77]

Thanks for stepping in.

I did see the note about CAN and SPI simultaneously in the docs. I don’t have the ADXL connected - only used for a resonance test, and the plan would be to figure how to swap between CAN and ADXL when I need to re-do one later. So that’s not the setup at the moment. Also I have not changed my klipper config to even look for the EBB, so it’s not grabbing the port or device. To be safe I’ve turned off the klipper service while doing all this too, even if that seems illogical.

Right now it’s like the CAN interface works (sees the UUID) and then is unable to actually flash klipper to it over CAN. Interestingly, I don’t seem to be able to flash klipper to it over usb either, which makes no sense. I flash katapult, and the led starts blinking and the device uuid shows up on CAN interface. When I flash kilpper (usb or CAN) the light stops blinking but does not show up with canbus_query.py, so can’t get the ID and add it klipper. I did try just adding it using the UUID from before flashing klipper, and klipper cannot see it.

I have opened issues on Katapult and cross-posed to the EBB github repo with detailed log dumps using candump. There seems to be some tx/rx errors when trying to flash klipper via CAN.

Anyway, there you go. So I guess my options are:

1. stick with Pad7 built-in CAN interface, and see if this gets solved (seems more unlikely atm)
2. Spend another $35 CAD and get the U2C v2.1 board and try that way (seems to be what everyone is doing and all the guides are based on). Already spent $65 on the EBB42 - is this a really good way to spend $100?
3. Ditch CAN entirely and either a) buy replacement Artillery PCB/Ribbon cables or b) rewire everything straight through using the “classical way”
4. Stop everything, salvage/sell the parts off and buy a new modern printer with everything (lots of choices, Bambu A1 for $500, the new Anycubics, heck even a Biqu B1 is only $249 and most of what I want (with it’s own problems, granted).
5. Or go the complete opposite -spend the money to rebuild everything on this printer or just get a Voron kit. I like 3d “printering”. But don’t have much time or the interest in spending the money.

I really hoped the built-in CAN interface on the Pad7 would make this easy, but seems like I should have just stuck with my old PI vs spending the money on the fancy screen+interfaces.

thanks

[docgalaxyblock]

OK

@valan77

$65 on the EBB42

that sound a bit high for me - was it a 2pcs pack?
If so it is possible to missuse a ebb as a usb-can for testing to narrow down where the issue is.

[valan77]

@docgalaxyblock

@valan77

$65 on the EBB42

Nope, just one. Here https://a.co/d/5Bczqnv

@docgalaxyblock

If so it is possible to missuse a ebb as a usb-can for testing to narrow down where the issue is.

Ordered one to see if it suits my needs. Have a feeling it will like “work”, but still not solve my problem (throwing good money after bad)

[docgalaxyblock]

Ah Amazon -

I have a MCP based Pi CAN HAT that I find interesting to test out somewhere … could try it myself if I find the time to get some experience there.

If I am allowed to blindly guess - I guess the problem is on the pad side.

---

Your above

@valan77

Setting from my pi:

looks like this was the command ip link show can0?
Could you also try a ip -details -statistics link show can0 after a failed flash attemp?

[jakep_82]

@valan77

Already spent $65 on the EBB42

Where did you buy it? They’re $14 USD on AliExpress with free shipping. Even with the conversion to CAD, $65 is about 3 times what it’s worth. Similarly the U2C board is only $16 USD on Ali.

[hcet14]

@valan77
Sorry, I have to apologize. I just had a very quick look at the Pad7 schematics yesterday. Didn’t see it uses an MCP2515.

It is possible to use an MCP2515 with Klipper, but I wouldn’t suggest to try! You won’t get any support here.

Please forget my advice to open an issue here GitHub - Arksine/katapult: Configurable bootloader for Klipper. I would close it!
Katapult doesn’t support MCP2515. CandleLight_fw doesn’t support MCP2515. Therefore, KLipper doesn’t support MCP2515.

You also might read Experimental "USB to CANbus bridge" mode and CANBUS - Klipper documentation.

I suggest an U2C from BTT GitHub - bigtreetech/U2C. Make sure it has an STM32G0B1 on board!!!
I’m still dreaming of CAN FD support. With that MCU on board of an U2C, it will be possible to go for CAN FD.

[docgalaxyblock]

Ok I am encountering the same issue but not everytime…
sometimes it works sometimes it does not

It was just a fast test-setup:

I will try more stuff tomorrow.

[docgalaxyblock]

Ok out of my testing it looks like Error sending command [COMPLETE] to Can Device is a “generic” error message you get if flashtool.py cannot connect to a can device.

And I get that error if I do not reset the ebb once after using katapult to update itself.

@valan77 Just before flashing issue a can query and if the uuid gets discovered run the flashtool.py - otherwise press reset once. Just make sure the status led is blinking if you after you updated katapult.

[hcet14]

@docgalaxyblock

Ok out of my testing it looks like Error sending command [COMPLETE] to Can Device is a “generic” error message you get if flashtool.py cannot connect to a can device.

Of course, you’ll get an error! See my last post above.

[Sineos]

@hcet14

Of course, you’ll get an error! See my last post above.

Klipper / Katapult supports these MCP2515 hats, but it is known that they can drop packets which can lead to failures.

[docgalaxyblock]

Appendix to my previous post:
I got katapult and klipper working with the above setup.
So

@hcet14

Of course, you’ll get an error!

Is not true

[valan77]

Ok, finally got back to this. Sorry for the wall of text, but figured I owed this group the details since you have done so much research as well.

tl;dr; : the CAN interface on the Pad7 seems unreliable. Quite a bit of success, got fully functional EBB42 visible in klipper, but several attempts to replicate were fraught with errors. It seems sensitive to noise/wiring (more success with twisted wires than without). Something else might be going on. Not going to try to print with these kinds of errors.

Steps I followed:

1. Connect to USB and put board in dfu mode. Successfully detected in dfu, so flashed katapult successfully (got to flashing blue LED).
2. Reconnected power to a brick and wiring between the CAN pins on the Pad7 and the board. Pressed RESET once, got blinking LED. Uuid showed up with canbus_query. Re-flashed katapult successfully over CAN. LED not blinking after flashing.
3. Pressed RESET twice to get into blinking LED. Flashed klipper successfully. LED no longer blinking.
4. Set up EBB as MCU in klipper, worked just as directed.

So, for fun, tried to reflash klipper several times to check if it was something with the wiring, a fluke, etc.

Findings:

Attempt 1: DFU flash successful, CAN katapult flash failed first time, succeed second time. klipper flash succeeded.
Attempt 2: re-flashed klipper, failure.
Block Attempt 3: Tried to flash klipper three times. First two succeeded but had timeout errors, last time failed. WTF is going on?
Block attempt 4: changed to new set of wires, straight, no twists. All succeeded but had REQUEST_BLOCK errors on the verify step.
Block attempt 5: twisted the wires. All 3 attempts successful no errors.
Block attempt 6: untwisted the wires. First two succeed with errors. Final one failed.
Block attempt 7: re-twisted the wires. All attempts failed.

Conclusion: the CAN interface on the Pad7 seems unreliable when used directly with a CAN device. Seems more so the more data written (almost no errors flashing katapult, but many more errors flashing klipper). I do not want to try printing these amounts of errors. No response from BTT yet. Maybe I’ll try the U2C for fun.

Error examples below in case anyone searches for the same thing:

full failure

iqu@btt-pad7:~ $ python3 ~/katapult/scripts/flashtool.py -i can0 -b 500000 -v -f ~/klipper/out/klipper.bin -u 4220d6e9e9f9
Sending bootloader jump command...
Resetting all bootloader node IDs...
Attempting to connect to bootloader
Katapult Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/biqu/klipper/out/klipper.bin'...

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

Write complete: 14 pages
Verifying (block count = 427)...

[INFO:root:Response for command REQUEST_BLOCK timed out, 4 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 3 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 2 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 1 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 0 tries remaining
ERROR:root:Flash Error
Traceback (most recent call last):
  File "/home/biqu/katapult/scripts/flashtool.py", line 626, 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/biqu/katapult/scripts/flashtool.py", line 482, in run
    await flasher.verify_file()
  File "/home/biqu/katapult/scripts/flashtool.py", line 250, in verify_file
    resp = await self.send_command("REQUEST_BLOCK", payload)
  File "/home/biqu/katapult/scripts/flashtool.py", line 196, in send_command
    raise FlashCanError("Error sending command [%s] to Can Device"
FlashCanError: Error sending command [REQUEST_BLOCK] to Can Device

Success with errors:

biqu@btt-pad7:~ $ python3 ~/katapult/scripts/flashtool.py -i can0 -b 500000 -v -f ~/klipper/out/klipper.bin -u 4220d6e9e9f9
Sending bootloader jump command...
Resetting all bootloader node IDs...
Attempting to connect to bootloader
Katapult Connected
Protocol Version: 1.0.0
Block Size: 64 bytes
Application Start: 0x8002000
MCU type: stm32g0b1xx
Verifying canbus connection
Flashing '/home/biqu/klipper/out/klipper.bin'...

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

Write complete: 14 pages
Verifying (block count = 427)...

[INFO:root:Response for command REQUEST_BLOCK timed out, 4 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 3 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 2 tries remaining
INFO:root:Response for command REQUEST_BLOCK timed out, 1 tries remaining
##################################################]

Verification Complete: SHA = D03D9A802979D42780A2338C0BE924A7630EE0EF
Flash Success