[CRITICAL REGRESSION] ESP-IDF v5.5.2 TWAI Driver: Message Loss & Broken ISO 11783-6 (IDFGH-17045)

[diplfranzhoepfinger]

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.

General issue report

Subject: [CRITICAL REGRESSION] ESP-IDF v5.5.2 TWAI Driver: Message Loss & Broken ISO 11783-6

@wanckl @Dazza0

Description

I am reporting a critical regression regarding the TWAI (CAN) driver in ESP-IDF release v5.5.2.

I have conducted an A/B comparison using the exact same application code, changing only the TWAI driver implementation (components\CAN1). The results show that the new driver implementation introduced in this release is causing severe instability compared to the previous version.

Test Scenario

• Release: ESP-IDF v5.5.2
• Path: Application\components\CAN1
• Comparison: Tested the same application logic with two different driver implementations (files attached below).

Attachments & Evidence

Component	New Driver (Failing)	Legacy Driver (Working)
Source	NewCanDriver_CAN1.c	OldCanDriver_CAN1.c
CMake	NewCMakeLists.txt	OldCMakeLists.txt

Logs:

• 20260105_222206_logiBUS.log (Log showing failures with the New Driver)

Observed Symptoms

With the new CAN driver implementation, we are observing:

1. Message Loss: Significant dropping of CAN frames.
2. Protocol Failure: Broken Pool Uploads regarding ISO 11783-6 (ISOBUS).
3. General Instability: The bus communication is unreliable compared to the legacy driver.

Impact / Severity

[BLOCKER / HIGHEST PRIORITY]
This regression makes the product completely unusable for the end customer.

• The application cannot perform basic required tasks (ISO 11783-6 compliance).
• We categorize this as a 100% functional failure of the driver in this context.
• We currently have to invest a significant amount of work to mitigate these driver issues.

We urgently request a review of the changes made to the TWAI driver in v5.5.2 and a fix for this regression.

[wanckl]

@diplfranzhoepfinger Hi, sad to hear this info and sorry for let you so hard to migration your project.

I'll continuously help you to resolve twai issues

I need more info to try to reproduce your issue with your code:

1. I see you config normal mode in both code, so, how frequently the messages other node send to bus, and esp32 send to bus.
2. you set to a low bitrate 250k, so how long the bus wire is, it decide the signal quality on bus, because we can see many stuff error detected
3. from your other issues, I guess you still using the esp32s3 right?
4. is message missing happens on tx or rx directory?
5. how many nodes on bus?
6. dose wifi is used, because the interrupt priority is higher than twai

[wanckl]

@diplfranzhoepfinger From my simply test, maybe is timing default sample point issue, you can try to config bit_timing.sp_permill = 800, or smaller, it will help for error TWAI Error Detected (0x8)

[diplfranzhoepfinger]

@wanckl did you change Sample Point Setting ?
old TWAI Driver had default 80%, single Sampling.

bit_timing.sp_permill = 800, what does it mean ? it is unclear to me.

in ISO 11783-2 there is a very strict rule for Sample Point.

here a AI summary around it.

ISO 11783-2: Sample Point Rules

Based on ISO 11783-2, the rules regarding the Sample Point are strictly defined to ensure reliable communication and compatibility between Electronic Control Units (ECUs) from different suppliers.

1. General Requirements

• Method: The system must be configured to use the single sample point method as defined in ISO 11898-1.
• Location: The sample point must be located at 80 % ± 3 % of the bit time.
• Bit Rate Context: These settings apply to a bit time of 4 µs, which corresponds to a data rate of 250 kbit/s.

2. Definition and Function

• The sample point is defined as the specific point in time within the bit duration at which the bus level is read and interpreted as the value of the bit.
• It marks the end of PHASE_SEG1 and the beginning of PHASE_SEG2 within the bit subdivision.

3. Implementation and Timing (Annex A)

To achieve the required sample point precision, the document provides specific configuration guidelines for the CAN protocol controller:

• Time Quanta (tq): The bit time is divided into smaller time units called time quanta. The document recommends specific total tq counts (e.g., 16 or 20) to accurately hit the 80% target.
• Clock Tolerance: Achieving these specific bit timing restrictions generally requires the use of crystal oscillators at all nodes.

Recommended Settings (Table A.1)

The following values are recommended to achieve the 80 % ± 3 % sample point:

Total tq	tq Timing	tSync-Seg	tTSEG1 (Prop + Phase 1)	Sample Point Calculation	Result
16	250 ns	1 tq	12 tq	(1 + 12) / 16	81.25%
20	200 ns	1 tq	15 tq	(1 + 15) / 20	80.00%

[wanckl]

@diplfranzhoepfinger Yes, new driver contain a bitrate calculator which let bitrate config easier.

But default sample point is not fixed to 80% but a engineering segmented value:

bitrate >= 800k      sample point 75%
bitrate 500k~800k    sample point 80%
bitrate <500k        sample point 85%

bit_timing.sp_permill = 800 to config sample point at 800‰ (80%).

there is also bit_timing.ssp_permill to setting the 2nd sample point

[wanckl]

@diplfranzhoepfinger And BTW:

driver is now added API twai_node_transmit_wait_all_done, you can use it for sync trans
and tx_queue_remaining is also able to be get from twai_node_get_info

[franz-ms-muc]

@diplfranzhoepfinger And BTW:

driver is now added API twai_node_transmit_wait_all_done, you can use it for sync trans and tx_queue_remaining is also able to be get from twai_node_get_info

NewCanDriver_CAN1.c

i need to do the Retransmission right ? so twai_node_transmit_wait_all_done is not useful, as the Task would pull already the next msg from the Queue ?

[wanckl]

@franz-ms-muc OK, if you also transmit from isr callbacks, wait_all_done is not proper

But generally, TWAI is able to hardware retry by setting twai_onchip_node_config_t::fail_retry_cnt, unless you don't enable it.

wait_all_done dose wait_tx_queue_empty + hardware idle, so it waiting for all enqueued item from task and callbacks

[diplfranzhoepfinger]

fail_retry_cnt = -1

still i get failed transmissions in the callback, retransmit, and not fail again.
i checked you code, when the callback is triggered, the Controller already gave up.

[wanckl]

@diplfranzhoepfinger Dose sample_point config anything help for your message losing?

[roffe]

Im having similar issues where the esp32-s3 is missing incoming frames in my canbus application.

i have a on_error callback and it triggers every time about the same time my pc application is missing a response from the ECU

static IRAM_ATTR bool twai_err_cb(twai_node_handle_t handle, const twai_error_event_data_t *edata, void *user_ctx)
{
    ESP_EARLY_LOGI("TWAI", "bus error: 0x%lx", edata->err_flags.val);
    return false;
}

but all it says is TWAI: bus error: 0x0

i've spent days trying different timing configurations but none seem to help

[wanckl]

@roffe Hi, may I know what the role of your esps3/pc-application/ECU? dose they are all different node?

And there is a patch on error_code thanks to @diplfranzhoepfinger , you can have a try. #18100

If possible, have a logic wave of esp32s3 on where the frame missing will be helpful

[diplfranzhoepfinger]

@roffe did you have a look on "NewCanDriver_CAN1.c" ? the Retry on_tx_done seems important.

do you have this ?