ESP32 Forum

Hi! I have not been able to find clarifications regarding some parts of the TWAI implementation. For reference, I am using ESP-IDF v6.0.0, with esp_twai.h and esp_twai_onchip.h.

1. When TWAI enters bus-off state, the TRM states the controller enters Reset mode. About Reset mode, the TRM states that "any transmission in progress is immediately terminated". So this means that if there is a transmission in progress when bus-off occurs, it is immediately aborted and the on_tx_done callback is not invoked, right? If you rely on that callback for freeing resources (since this version of the driver needs the buffer to remain valid until transmission is complete), this doesn't seem ideal. So what is the proper procedure to handle bus-off while sending?

2. The API reference states you must call twai_node_recover() from task context. It seems like all it does is clear and set a bit in its state_flags and enters Operation mode by setting the register TWAI_RESET_MODE to 0. Which part of this is unsafe to execute in ISR context? Apart from the ESP_RETURN_ON_FALSE check which would probably panic if it tries to print the log message.

3. Upon finishing recovery, it will immediately start transmitting whatever frame is left inside tx_mount_queue. So, let's say you try sending two frames, for the first one the hardware is idle so it starts transmitting immediately, and the second one gets queued. Then, bus-off happens while sending the first one, so it is aborted. Then, after recovery, it starts sending the second frame, from the queue. Effectively, the first frame is lost. And there is no way to get rid of the queue, i.e. set tx_queue_depth to 0.

Am I missing something? Thanks.

So this means that if there is a transmission in progress when bus-off occurs, it is immediately aborted and the on_tx_done callback is not invoked, right?

Should still be called, with twai_tx_done_event_data_t::is_tx_success set to false.

on_tx_done is only called when the events returned by twai_hal_get_events() contain the bit TWAI_HAL_EVENT_TX_BUFF_FREE, which is set only when the interrupts returned by twai_ll_get_and_clear_intrs() contain the bit TWAI_LL_INTR_TI (equivalent to TWAI_TX_INT_ST in the TRM).

I don't believe the controller sets that interrupt upon bus-off.

The TRM states that the Transmit Interrupt is triggered "whenever Transmit Buffer becomes free":

The Transmit Buffer becomes free under the following scenarios:
• A message transmission has completed successfully, i.e., acknowledged without any errors. Any failed messages will automatically be resent.
• A single shot transmission has completed (successfully or unsuccessfully, indicated by the TWAI_TX_COMPLETE bit).
• A message transmission was aborted using the TWAI_ABORT_TX command bit

In my twai_onchip_node_config_t, fail_retry_cnt is set to -1, so "re-trans forever" as per the comment next to it in esp_twai_onchip.h. I am not sending single shot messages. Also, it seems that it only checks if fail_retry_cnt is -1 or not, to know whether to set the frame as single-shot or not. Then why does the comment lead you to believe you can also use values 0-15 instead of just -1 and 0? Every other number would have the same effect as 0, i.e. single-shot. I can't find any mention of a "hardware retry counter" in the TRM.

So... in my case it's 1. trying to resend the failed transmission continuously, and 2. in Reset mode which doesn't allow transmission, both at the same time? That's a bit unclear. But according to this, the TX interrupt is not triggered.