Klipper fails to connect via can, flashing successful

Basic Information:

Printer Model: Voron 2.4r2 250mm with Voron Tap
MCU / Printerboard: BTT Octopus Max EZ with 6 EZ2209 and BTT EBB SB2209 CAN (STM32)
Host / SBC: Check neofetch below, board is a ASRock AD2550-ITX
klippy.log

neofetch

OS: Ubuntu 24.04.1 LTS x86_64 
Kernel: 6.8.0-49-generic 
Uptime: 55 mins 
Packages: 896 (dpkg) 
Shell: fish 3.7.0 
Terminal: /dev/pts/3 
CPU: Intel Atom D2550 (4) @ 1.866GHz 
GPU: Intel Atom Processor D2xxx/N2xxx 
Memory: 486MiB / 7928MiB 

Describe your issue:

After some time using my EBB SB2209 (RP2040) via USB I decided to switch over to canbus. The reason being, that I intend to also wire my SuperRacer, my Voron 0.2 and my (soon to be built) Rook 2020 MK2 via CAN to reduce the cables needed in my host PC.

The first issue I had was getting the SB2209 (RP2040) to be recognized at all by Klipper and simply gave up. My dad had a EBB SB2209 (STM32) which gets recognized and was able to get flashed. I managed to connect it with klipper and get two can uuids listed using the query tool. But as soon as I start the klipper service it ends with the following message:

mcu 'mcu': Starting CAN connect
Created a socket
webhooks client 135305606483072: New connection
webhooks client 135305606483072: Client info {'program': 'Moonraker', 'version': 'v0.9.3-1-g4e00a07'}
Loaded MCU 'mcu' 120 commands (v0.12.0-394-g7f89668d6 / gcc: (15:13.2.rel1-2) 13.2.1 20231009 binutils: (2.42-1ubuntu1+23) 2.42)
MCU 'mcu' config: ADC_MAX=4095 BUS_PINS_i2c1_PB6_PB7=PB6,PB7 BUS_PINS_i2c1_PB8_PB9=PB8,PB9 BUS_PINS_i2c2_PB10_PB11=PB10,PB11 BUS_PINS_i2c3_PA8_PC9=PA8,PC9 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_spi3a=PC11,PC12,PC10 BUS_PINS_spi4=PE13,PE14,PE12 BUS_PINS_spi5=PF8,PF9,PF7 BUS_PINS_spi5a=PH7,PF11,PH6 BUS_PINS_spi6=PG12,PG14,PG13 CANBUS_BRIDGE=1 CLOCK_FREQ=400000000 INITIAL_PINS=PF7 MCU=stm32h723xx PWM_MAX=255 RECEIVE_WINDOW=192 RESERVE_PINS_CAN=PD0,PD1 RESERVE_PINS_USB=PA11,PA12 RESERVE_PINS_crystal=PH0,PH1 STATS_SUMSQ_BASE=256 STEPPER_BOTH_EDGE=1
mcu 'EBBCan': Starting CAN connect
Created a socket
mcu 'EBBCan': got {'count': 559, 'sum': 541734, 'sumsq': 5133552, '#name': 'stats', '#sent_time': 3401.948837832, '#receive_time': 3401.99062775}
Loaded MCU 'EBBCan' 120 commands (v0.12.0-394-g7f89668d6 / gcc: (15:13.2.rel1-2) 13.2.1 20231009 binutils: (2.42-1ubuntu1+23) 2.42)
MCU 'EBBCan' config: ADC_MAX=4095 BUS_PINS_i2c1_PA9_PA10=PA9,PA10 BUS_PINS_i2c1_PB6_PB7=PB6,PB7 BUS_PINS_i2c1_PB8_PB9=PB8,PB9 BUS_PINS_i2c2_PB10_PB11=PB10,PB11 BUS_PINS_i2c2_PB13_PB14=PB13,PB14 BUS_PINS_i2c3_PB3_PB4=PB3,PB4 BUS_PINS_i2c3_PC0_PC1=PC0,PC1 BUS_PINS_spi1=PA6,PA7,PA5 BUS_PINS_spi1a=PB4,PB5,PB3 BUS_PINS_spi2=PB14,PB15,PB13 BUS_PINS_spi2_PB2_PB11_PB10=PB2,PB11,PB10 BUS_PINS_spi2a=PC2,PC3,PB10 BUS_PINS_spi3=PB4,PB5,PB3 CANBUS_FREQUENCY=1000000 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
Sending MCU 'mcu' printer configuration...
Configured MCU 'mcu' (1024 moves)
Sending MCU 'EBBCan' printer configuration...
b'Got error -1 in can write: (11)Resource temporarily unavailable'
b'Got error -1 in can write: (11)Resource temporarily unavailable'
b'Got error -1 in can write: (11)Resource temporarily unavailable'
b'Halting reads due to CAN write errors.'

This happens, regardles, which bitrate I use, I tried 1M, 250K and 500K. All three yield the same result. For me it looks like it actually connects to the board, otherwise it wouldn’t know the board details, but after that it stops.

The wire is the original one from BTT just shortend to the length I actually need. But it didn’t work with the long cable either.

Can anyone help me troubleshoot and hopefully find a solution?
klippy.log (23.8 KB)

Output of can query

> ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0voron2
Found canbus_uuid=88067de26298, Application: Klipper
Found canbus_uuid=3857b6afa202, Application: Klipper
Total 2 uuids found

The network is configured as follows:

> cat /etc/network/interfaces.d/can0voron2
allow-hotplug can0voron2
iface can0voron2 can static
    bitrate 1000000
    up ip link set $IFACE txqueuelen 1024
    pre-up ip link set can0voron2 type can bitrate 1000000
    pre-up ip link set can0voron2 txqueuelen 1024
> cat /etc/systemd/network/10-can.link 
[Match]
Type=can

[Link]
TransmitQueueLength=1024
> cat /etc/systemd/network/25-can.network 
[Match]
Name=can*

[CAN]
BitRate=1M

The can interface is renamed using udev like this:

> cat /etc/udev/rules.d/z21_persistent-local.rules 
SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="380036001551303531313638", NAME="can0voron2"

Here are the guides I followed to get all that setup:

Ah dang, I clicked on create topic before the klippy.log was uploaded completely, my bad. Added the klippy.log :slight_smile:

The CAN network setup looks extremely fishy:

  • do not use txqueuelen > 128
  • You are mixing the ifupdown network definition with the systemd network definition. Not sure if Linux is smart enough to sort this mess or which definition will ever take precedence

Alright, after changing that I get a new error message, as follows:

mcu 'mcu': Unable to open CAN port: Failed to transmit: [Errno 105] No buffer space available

klippy.log (24.0 KB)

I just saw, I had the wrong bitrate set, I changed it to 1M and the here is the currrent klippy.log (24.6 KB)

These are my current network settings:

❯ cat /etc/udev/rules.d/z21_persistent-local.rules
SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="380036001551303531313638", NAME="can0voron2"
❯ cat /etc/systemd/network/25-can.network
[Match]
Name=can*

[CAN]
BitRate=1M
❯ cat /etc/systemd/network/10-can.link
[Match]
Type=can

[Link]
TransmitQueueLength=128
❯ ip -d -s link show can0voron2
14: can0voron2: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 128
    link/can  promiscuity 0  allmulti 0 minmtu 0 maxmtu 0 
    can state ERROR-ACTIVE restart-ms 0 
          bitrate 1000000 sample-point 0.750
          tq 62 prop-seg 5 phase-seg1 6 phase-seg2 4 sjw 2 brp 3
          gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1
          clock 48000000 
          re-started bus-errors arbit-lost error-warn error-pass bus-off
          0          0          0          0          0          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus usb parentdev 5-2:1.0 
    RX:  bytes packets errors dropped  missed   mcast           
         33140    5394      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
          4446     772      0       0       0       0 

For good measures here is the make menuconfig for the Octopus Max EZ

Klipper Firmware Configuration
[*] Enable extra low-level configuration options
    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32H723)  --->
    Bootloader offset (128KiB bootloader)  --->
    Clock Reference (25 MHz crystal)  --->
    Communication interface (USB to CAN bus bridge (USB on PA11/PA12))  --->
    CAN bus interface (CAN bus (on PD0/PD1))  --->
    USB ids  --->
(1000000) CAN bus speed
(PF7) GPIO pins to set at micro-controller startup

And for the EBB SB2209 (STM32)

Klipper Firmware Configuration
[*] Enable extra low-level configuration options
    Micro-controller Architecture (STMicroelectronics STM32)  --->
    Processor model (STM32G0B1)  --->
    Bootloader offset (8KiB bootloader)  --->
    Clock Reference (8 MHz crystal)  --->
    Communication interface (CAN bus (on PB0/PB1))  --->
(1000000) CAN bus speed
()  GPIO pins to set at micro-controller startup

This looks correct now. Have you restarted the entire system, i.e. power-cycling SBC and MCUs? Sometimes, something “gets stuck” when messing around too much.
What distribution do you use? Generally it looks like an issue with the OS rather than the firmware / MCUs

This is the system I use currently:

OS: Ubuntu 24.04.1 LTS x86_64 
Kernel: 6.8.0-49-generic 
Uptime: 55 mins 
Packages: 896 (dpkg) 
Shell: fish 3.7.0 
Terminal: /dev/pts/3 
CPU: Intel Atom D2550 (4) @ 1.866GHz 
GPU: Intel Atom Processor D2xxx/N2xxx 
Memory: 486MiB / 7928MiB

The full power cycle sadly didn’t help.

One thing I find weird, flashing with Katapult worked flawless.

I would try using a dedicated setup, e.g. some spare RPi and do a standard installation on a standard (Debian) Linux, which should not take more than 20 mins and then test this.

If it works, then you know it is something in your Linux setup.

I just followed this post and noticed, it has something to do with the toolhead board or the cable. But I switched the cable twice.

I double checked that the jumpers for termination are set.

What confuses me the most is, that Katapult can successfully flash Klipper to the toolhead board and the mainboard. Only Klipper has the issue.

I honestly have no idea why, but it worked after reflashing the MCU again. Maybe something went wrong the other times.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.