ESP32C3: TWAI_ALERT_RX_FIFO_OVERRUN (IDFGH-9944)

[mickeyl]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

5.0.1

Operating System used.

Linux

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-C3-DevKitM-1

Power Supply used.

USB

What is the expected behavior?

Using an ESP32C3 for ECU reprogramming. Everything works fine in testing mode where I have a bunch of milliseconds delay between frames. When I let the ECUs go "full throttle", the ESP32C3 TWAI chokes with "TWAI_ALERT_RX_FIFO_OVERRUN". Since this is NOT queue-based (my rx queue length is 600 and thus should accomodate a full ISOTP PDU), I wonder what the problem is and what are my options?

What is the actual behavior?

I would expect that the ESP32c3's TWAI controller is suitable to manage the full CAN bus bandwidth? (I'm not even exceeding 500KB/sec).

Steps to reproduce.

Nothing unsual, just following the examples.

Debug Logs.

I (2873) TWAI: Alert 2
I (2873) TWAI: Alert 1
I (2883) TWAI: Alert 4
V (2883) TWAI: <<< can0  18DAF900  [8]  11 55 5A 80 00 00 31 69 
V (2893) TWAI: CAN RX still running...
I (2893) TWAI: Alert 2
I (2893) TWAI: Alert 1
I (2903) TWAI: Alert 4
I (2903) TWAI: Alert 4
I (2903) TWAI: Alert 4
I (2903) TWAI: Alert 4
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
E (2903) TWAI: Alert 16384
I (2943) TWAI: Alert 4
E (2943) TWAI: Alert 16384

### More Information.

_No response_

[mickeyl]

Ok, so I have researched a bit more. Apparently the controller has a buffer of 64 bytes, which accommodates roughly 5 CAN frames. If you don‘t pull out the frames fastly enough, it will overrun and no amount of TWAI RX queue length will help you preventing that. Why is that?

Whether you can manage to service a full bus depends on the overall systemload, especially on the single core devices, such as the C3 in my case. Switching the ISR to IRAM and removing most of my debug output helped me to survive longer without a FIFO overrun. Still, I would have expected the RX buffer to make a difference. I have set it to 600 frames to hold a full ISOTP frame (which needs 586).

I reckon this is probably not strictly a bug, but do you have any advice for me to get CAN running more smoothly?