Esp32TWAI driver churns on interrupts when there is no CAN plugged in

[balazsracz]

Here is an example output from the TWAI report messages with no CAN-bus plugged in:

ESP-TWAI: RX:0 (pending:0,overrun:0,discard:0,missed:0,lost:0) TX:32 (pending:0,suc:0,fail:32) Bus (arb-err:0,err:2249824,state:Running)
ESP-TWAI: RX:0 (pending:0,overrun:0,discard:0,missed:0,lost:0) TX:32 (pending:0,suc:0,fail:32) Bus (arb-err:0,err:2264530,state:Running)
ESP-TWAI: RX:0 (pending:0,overrun:0,discard:0,missed:0,lost:0) TX:32 (pending:0,suc:0,fail:32) Bus (arb-err:0,err:2279236,state:Running)
ESP-TWAI: RX:0 (pending:0,overrun:0,discard:0,missed:0,lost:0) TX:32 (pending:0,suc:0,fail:32) Bus (arb-err:0,err:2293942,state:Running)
ESP-TWAI: RX:0 (pending:0,overrun:0,discard:0,missed:0,lost:0) TX:32 (pending:0,suc:0,fail:32) Bus (arb-err:0,err:2308648,state:Running)
ESP-TWAI: RX:0 (pending:0,overrun:0,discard:0,missed:0,lost:0) TX:32 (pending:0,suc:0,fail:32) Bus (arb-err:0,err:2323354,state:Running)

each "err" counter is one interrupt (event) with

    // Bus error detected
    if (events & TWAI_HAL_EVENT_BUS_ERR)

This means that we are getting about 15k interrupts in five seconds when there is no CAN-bus plugged in. That's an unexpectedly high churn for something that's a pretty common condition.

The expected behavior is that the device goes into bus-off and sends an interrupt next time there is a valid received frame or the frame happens to be transmitted correctly.

[balazsracz]

@atanisoft fyi

[atanisoft]

Let me see what I can find, I agree this is a sub-optimal behavior. I'm not seeing anything specific in the ESP-IDF driver that would handle this differently.

[balazsracz]

Maybe the answer would be that the error interrupt should be masked.

…

-- Sent from my mobile device

[atanisoft]

Perhaps, but there may be other conditions masked by doing that. Perhaps the WD task could disable/enable the interrupt when it wakes every ~10sec if the TX/RX count has changed since last wake up?

[balazsracz]

check the datasheet, maybe there is a way to mask only the error interrupt (without masking the rest of the interrupts). Usually hardware peripherals have an interrupt mask register themselves that determines what interrupt sources are enabled. Those sources are then OR-ed together to drive the interrupt line to the core.

[atanisoft]

from the S3 datasheet, it looks like the bus-error interrupt flag can be isolated but there are some usages of this bit in ESP-IDF (ref).

It also appears that TWAI_HAL_EVENT_BUS_ERR is being set in the event bits when any form of error is detected (TX, RX, arb, bit, etc), so I'm not 100% certain it is very meaningful on it's own. Perhaps this bit should be ignored entirely when other conditions are also detected?

[atanisoft]

It may also make sense to implement handlers for the following events which are currently ignored:

• TWAI_HAL_EVENT_ABOVE_EWL
• TWAI_HAL_EVENT_BELOW_EWL
• TWAI_HAL_EVENT_ERROR_PASSIVE
• TWAI_HAL_EVENT_ERROR_ACTIVE

These are currently being set by the HAL layer but not used.

[atanisoft]

I've dug through the TWAI code and this bus-error count increasing is occurring AFTER the driver enters error-passive state. It also does not ever appear to transition to the bus-off state after entering error-passive state.

Making it worse though is the entire SimpleCanStack can enter a 100% blocked state due to the traffic failing during TX (silently failing due to error-passive). I've pushed this commit to my 5.1.0 branch and have yet to encounter an issue. I'll be raising it as a PR here soon.