CAN No buffer space available (yet another issue)

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Spider 2.2, EBB SB2209 CAN V1.0（RP2040), Cartographer v3
Host / SBC: Raspberry Pi 4, Raspbian Linux 6.12.47+rpt-rpi-v8 Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16)
klippy.log

klippy.log.zip (756.0 KB)

Describe your issue:

I just finished building my Voron 2.4. Everything is connected, and printer is printing fine… but only 20-40 minutes. After some time it reports 'Got error -1 in can write: (105)No buffer space available’. I get this error even if printer just booted and does not perform any job.

Restarting klipper does not help - after restart CAN is still not available. Only power cycle helps

My CAN setup is:

Raspberry Pi → BTT U2C v2.1 (120 Ohm resistor enabled) → BTT EBB SB2209 (120 Ohm resistor enabled) → Cartographer v3

CAN baudrate: 1M

What I checked so far:

  • Studied all relevant topics on this forum related to this error
  • Studied Klipper CANBUS troubleshooting guide
  • Ensured TX queue size is 128
  • Ensured CAN line resistance is 60 Ohm
  • Tried increasing queue size to 256
  • Tried changing USB cable
  • Tried changing CAN cable
  • Tried different USB2CAN firmwares (* one, * two)
  • Checked dmesg (no new records during CAN outage)
  • Checked ifconfig (no TX/RX errors there)
  • Checked bytes_invalid parameter in the log. Even though sometimes it is not zero, it does not increase over time

There are a few items that do not contradict documentation, but concern me a little bit:

  • The terminating resistor is not on the cartographer PCB, but rather on SB2209. As per documentation this is OK, as cartographer is considered as spur, but technically the cartographer is the farmost device.
  • tx_retries value growth over time. Is this a problem?

Are there any ideas what could be wrong in my setup, and how can I localize the problem?

2

I’m not sure if this is going to be helpful or not, but just to throw this out there for consideration.

Can you remove the ‘cartographer’ component from the setup and operate the printer to see if you still get the error? I am not familiar with this component, and maybe it is in fact key to what you’re doing, but operating with it not present might be illuminating. Just a thought.

-tetra

addendum:
also v4 is out now, and have you updated the firmware on the cartographer?

3

Have you tried 500k? should be PLENTY of bandwidth and more tolerant of the long spur (and any other electrical issues on the CAN line).

4

You have CAN bus issue.
Alas because here is U2C in the middle, there is no info of what exactly is happening.
You can flash it with the klipper, it can help with debugging data, but it will not fix anything.

Otherwise it can be some of the bazillion issues with EBB SB boards.
(and probably is).

Hope that helps a little.
-Timofey

JFYI: CAN will not stop working because of a bit flip, or 2, or even 10.

5

Thank you for your thoughts.

Alas because here is U2C in the middle, there is no info of what exactly is happening.
You can flash it with the klipper, it can help with debugging data, but it will not fix anything.

What do you mean here? I probably can flash klipper on the U2C board, but what will it prove? U2C is connected by USB, while the issue is related to CAN.

In the meantime I also tried/excluded these:

  • Used a separate power supply for Raspberry to avoid voltage drop (previously it was powered from Spider board, which provided only 4.8V under load)
  • Removed cartographer
  • Replaced SB2209 board with another BTT EBB42 laying around

Unfortunately CAN buffer issue is still observed :frowning:

6 
Stats 2822.4:
  gcodein=0
  mcu: mcu_awake=0.000 mcu_task_avg=0.000004 mcu_task_stddev=0.000003 bytes_write=20479 bytes_read=328864 bytes_retransmit=9 bytes_invalid=6 send_seq=3113 receive_seq=3113 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=180003992
  canstat_EBB: bus_state=active rx_error=0 tx_error=0 tx_retries=1650
  EBB: mcu_awake=0.046 mcu_task_avg=0.000030 mcu_task_stddev=0.000092 bytes_write=3262958 bytes_read=1498606 bytes_retransmit=591 bytes_invalid=0 send_seq=124306 receive_seq=124302 retransmit_seq=124306 srtt=0.005 rttvar=0.001 rto=0.400 ready_bytes=0 upcoming_bytes=0 freq=12000223 adj=11999946
  cartographer: mcu_awake=0.028 mcu_task_avg=0.000011 mcu_task_stddev=0.000025 bytes_write=17658 bytes_read=315708 bytes_retransmit=35 bytes_invalid=0 send_seq=2922 receive_seq=2921 retransmit_seq=2922 srtt=0.002 rttvar=0.002 rto=0.400 ready_bytes=0 upcoming_bytes=0 freq=47998077 adj=47996945
  heater_bed: target=0 temp=24.9 pwm=0.000
  cartographer_coil: temp=26.6
  RaspberryPi: temp=49.9
  SpiderBoard: temp=33.0
  EBB: temp=34.4
  CartographerMCU: temp=39.9 print_time=64.227 buffer_time=0.000 print_stall=0
  extruder: target=50 temp=50.0 pwm=0.042 sysload=0.20 cputime=265.455 memavail=570048
Stats 2823.4:
  gcodein=0 
  mcu: mcu_awake=0.000 mcu_task_avg=0.000004 mcu_task_stddev=0.000003 bytes_write=20485 bytes_read=328967 bytes_retransmit=9 bytes_invalid=6 send_seq=3114 receive_seq=3114 retransmit_seq=2 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=180004005
  canstat_EBB: bus_state=active rx_error=0 tx_error=0 tx_retries=1650
  EBB: mcu_awake=0.046 mcu_task_avg=0.000030 mcu_task_stddev=0.000092 bytes_write=3262979 bytes_read=1498707 bytes_retransmit=738 bytes_invalid=0 send_seq=124308 receive_seq=124302 retransmit_seq=124308 srtt=0.005 rttvar=0.001 rto=1.600 ready_bytes=0 upcoming_bytes=0 freq=12000223 adj=11999942
  cartographer: mcu_awake=0.028 mcu_task_avg=0.000011 mcu_task_stddev=0.000025 bytes_write=17664 bytes_read=315789 bytes_retransmit=55 bytes_invalid=0 send_seq=2923 receive_seq=2921 retransmit_seq=2923 srtt=0.002 rttvar=0.002 rto=1.600 ready_bytes=0 upcoming_bytes=0 freq=47998077 adj=47996938
  heater_bed: target=0 temp=24.9 pwm=0.000
  cartographer_coil: temp=26.5
  RaspberryPi: temp=49.4
  SpiderBoard: temp=33.0
  EBB: temp=34.4
  CartographerMCU: temp=40.2 print_time=64.227 buffer_time=0.000 print_stall=0
  extruder: target=50 temp=50.0 pwm=0.025 sysload=0.20 cputime=265.527 memavail=572548

The point is that right now, only I can say that there is no answer/ack from the EBB (RTO increasing).
Because only EBB exports CAN stats and EBB is dead.

With the setup where:
Klippy process → USB → MCU → CAN BUS → EBB → CAN BUS → Carto
I have no data in between klippy process and EBB.
If there were a Klipper MCU, I would have some information about CANBUS state from the bridge.

That is the main difference.
It may or may not shine light on the issue.

Same about Carto here.
(btw, it should also work fine with the Klipper firmware).

Hmmmm, I reared it. Both MCUs, Carto and EBB lost connection.
So, I guess, it is something in between or your carto is powered from EBB, and lost power from EBB.
Anyway, they both died at the same time here.

We generally need logs if you changed something and it still happens.
Buffer overflow is not the root cause (and not an issue by itself I would say).

-Timofey

7

Thank you for the idea to flash Klipper as a USB2CAN bridge. With this firmware everything works much more stable. I was running it for 4 hours and it seems there are no major issues. Tomorrow I’ll try to get back the original cable, original EBB board, and the cartographer.

The only concern is ocasionally growing bytes_retransmit value (approx 10 bytes / hour). Shall I care about this? Currently I am testing this on the table using non-twisted cable, so connection quality is not the best. In a normal setup I’ll use a better cable.

klippy.log.zip (833.1 KB)

8

It is suboptimal. But generally should not cause issues by itself.
Unless it will be worse under real load.

-Timofey

9

What do you mean on ‘suboptimal’ and ‘worse under load’? What shall I monitor?

10

Retries are handled, and they are fine by themselves.
In an ideal scenario, there are no retries because there are no losses.

Your log seems to be from an “idle” machine with low transfer rates.
It may happen that this will work and continue to do occasional retries.
It may happen that while printing there will be more traffic to retry, and it will shutdown with TTC, for example, because of too many retries.

Hope that explains something.

11

You were right. I restored my setup (twisted cable, original EBB board, and the cartographer), and it failed almost right after start. Tried twice - same thing.

klippy.log.zip (236.0 KB)

However, logs are quite confusing to me: sending data towards EBB looks ok, while number of retries in EBB→host direction increases dramatically over time. This does not hint me what board is working incorrectly :frowning: Can you help, please?

12

It seems to me, that you lost connection to the USB2CAN:

USB2CAN: mcu_awake=0.024 mcu_task_avg=0.000011 mcu_task_stddev=0.000005 bytes_write=6054 bytes_read=20212 bytes_retransmit=97 bytes_invalid=0 send_seq=975 receive_seq=970 retransmit_seq=975 srtt=0.001 rttvar=0.000 rto=3.200

It just happened that EBB failed first.

So, I guess there is something with RPI3 and USB.

13

I was experimenting last week with connection of the gear and software used. I ended up installing Ubuntu Server 25.10 instead of Raspbian, and the original problem seems no longer reproduces. I was running my printer for 3 full days of printing, and did not see the CAN issue.

However, I still see constantly increasing tx_retries value reported by EBB board. Shall I be concerned about this? Does this indicate a real problem?

klippy.log.zip (4.9 MB)

14

Your EBB is RP2040 - generally no, you don’t have to, it is arbitration.
(the only mcu which reports tx_retries, and does not report tx_error).

-Timofey

15

It is normal and expected for messages to be “quashed” during arbitration. Message priority is determined as the header is transmitted. Low priority messages (IE temperature readings) are more prone to “yield” the bus than high priority messages (IE extruder move instructions).

Are NOT an error and will vary greatly with bus load.

16

JFYI,
There are no high/low priority messages in the klipper (at the can level), and there are no traditional “can” messages.
For klipper it is just like “ethernet” frame, that’s it.
Only Node addresses in the Klipper.
So, the message with the lower address wins.

-Timofey.

17

Interesting. Node numbers are assigned in the order they appear in printer.cfg. So make sure to put your toolhead above a AMS or other acessory.

Also explains the rising tx_retries for the tool head. The Host has the lowest ID and wins every collision.

18

Thank you for your replies, very helpful.

19

This is simply not true.

Arbitration IDs are mandatory in CAN, as it is how it handles contention. Klipper just doesn’t leverage this behavior much.

In the typical klipper setup with two CAN MCUs, from lowest to highest:

0x3F1 MCU → Host Admin Responses

0x3F0 Host → MCU Admin Broadcasts

(additional CAN MCUs here)

0x10B MCU →Host #2

0x10A Host → MCU #2

0x109 MCU #1 →Host

0x108 Host → MCU #1

If the primary mcu is CAN, it will be #1, then other MCUs follow. Klipper handles the list of extra MCUs in a way where order is not guaranteed, but is typically in the order the MCU block was encountered, with the contents of includes treated as replacing the include section.

To summarize:

  • Traffic to/from the main MCU (if it is can) has the highest priority.
  • Traffic to/from other MCUs are next, in config file order, but this is not guaranteed (this is a python configparser thing)
  • Administrative messages are last
  • Nothwithstanding the above, traffic from the host wins over its respective responses.

Klipper does not assume that MCUs will communicate with each other over CAN, and is basically tunneling a serial stream over CAN.