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.