I2C interrupt watchdog timeout on IDF v5.2.x (IDFGH-12970)

[10mann]

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.

v5.2.2

Espressif SoC revision.

ESP32-s3

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-S3-DevKitC-1 v1.1

Power Supply used.

USB

What is the expected behavior?

It should only report an error with the transmission, i.e. I2C_TIMEOUT or something similar.

What is the actual behavior?

When the I2C fails it sometimes crashes with an interrupt watchdog timeout.

Steps to reproduce.

This is reliably reproduced by updating the examples/peripheral/i2c/i2c_simple to use i2c master instead of the legacy driver. I used an sht31 for this test. If you short the pins while communicating, the chip almost always crashes with interrupt watchdog timeout.

There is a line in i2c_master.c:566 where there is a while(i2c_ll_is_bus_busy(hal->dev)){} running in an ISR context. This will trigger the interrupt watchdog if the device is busy. I think this should return an error / set an error flag instead of waiting forever.

Debug Logs.

E (15484) i2c.master: s_i2c_synchronous_transaction(830): I2C transaction failed
E (15484) i2c.master: i2c_master_transmit_receive(1056): I2C transaction failed
E (16584) i2c.master: s_i2c_synchronous_transaction(830): I2C transaction failed
E (16584) i2c.master: i2c_master_transmit_receive(1056): I2C transaction failed
E (17684) i2c.master: s_i2c_synchronous_transaction(830): I2C transaction failed
E (17684) i2c.master: i2c_master_transmit_receive(1056): I2C transaction failed
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0). 

Core  0 register dump:
PC      : 0x40377513  PS      : 0x00060034  A0      : 0x803776f1  A1      : 0x3fc93bc0  
0x40377513: i2c_isr_receive_handler at /opt/esp/idf/components/driver/i2c/i2c_master.c:566 (discriminator 1)

A2      : 0x3fc9af44  A3      : 0x3fc9af54  A4      : 0x3fc93bf0  A5      : 0x00000000  
A6      : 0x00000000  A7      : 0x3fc9b26c  A8      : 0x4600c011  A9      : 0x3fc93bb0  
A10     : 0x3fc9b39c  A11     : 0x3fc9af54  A12     : 0x00000000  A13     : 0x3fc95948  
A14     : 0x00000000  A15     : 0x3fc99db0  SAR     : 0x00000000  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x40056f5c  LEND    : 0x40056f72  LCOUNT  : 0xffffffff  
0x40056f5c: memcpy in ROM
0x40056f72: memcpy in ROM

Core  0 was running in ISR context:
EPC1    : 0x4201c3cf  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40377513
0x4201c3cf: uart_hal_write_txfifo at /opt/esp/idf/components/hal/uart_hal_iram.c:27
0x40377513: i2c_isr_receive_handler at /opt/esp/idf/components/driver/i2c/i2c_master.c:566 (discriminator 1)



Backtrace: 0x40377510:0x3fc93bc0 0x403776ee:0x3fc93bf0 0x4037634d:0x3fc93c30 0x403771c5:0x3fc93c50 0x40378d37:0x3fc9a340 0x42002d0e:0x3fc9a360 0x4037c029:0x3fc9a380 0x4037b0e5:0x3fc9a3a0
0x40377510: i2c_ll_is_bus_busy at /opt/esp/idf/components/hal/esp32s3/include/hal/i2c_ll.h:532
 (inlined by) i2c_isr_receive_handler at /opt/esp/idf/components/driver/i2c/i2c_master.c:566
0x403776ee: i2c_master_isr_handler_default at /opt/esp/idf/components/driver/i2c/i2c_master.c:627
0x4037634d: shared_intr_isr at /opt/esp/idf/components/esp_hw_support/intr_alloc.c:445
0x403771c5: _xt_lowint1 at /opt/esp/idf/components/xtensa/xtensa_vectors.S:1240
0x40378d37: xt_utils_wait_for_intr at /opt/esp/idf/components/xtensa/include/xt_utils.h:81
 (inlined by) esp_cpu_wait_for_intr at /opt/esp/idf/components/esp_hw_support/cpu.c:132
0x42002d0e: esp_vApplicationIdleHook at /opt/esp/idf/components/esp_system/freertos_hooks.c:59
0x4037c029: prvIdleTask at /opt/esp/idf/components/freertos/FreeRTOS-Kernel/tasks.c:4307 (discriminator 1)
0x4037b0e5: vPortTaskWrapper at /opt/esp/idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:134



Core  1 register dump:
PC      : 0x40378d3a  PS      : 0x00060734  A0      : 0x82002d11  A1      : 0x3fc9aaa0  
0x40378d3a: esp_cpu_wait_for_intr at /opt/esp/idf/components/esp_hw_support/cpu.c:145

A2      : 0x00000000  A3      : 0x00000000  A4      : 0x3fc97970  A5      : 0x3fc97950  
A6      : 0x40378afc  A7      : 0x00000001  A8      : 0x8200d5b6  A9      : 0x3fc9aa60  
0x40378afc: ipc_task at /opt/esp/idf/components/esp_system/esp_ipc.c:48

A10     : 0x00000000  A11     : 0x00000000  A12     : 0x3fc97950  A13     : 0x3fc97920  
A14     : 0x00000001  A15     : 0x3fc9ac68  SAR     : 0x00000000  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  


Backtrace: 0x40378d37:0x3fc9aaa0 0x42002d0e:0x3fc9aac0 0x4037c029:0x3fc9aae0 0x4037b0e5:0x3fc9ab00
0x40378d37: xt_utils_wait_for_intr at /opt/esp/idf/components/xtensa/include/xt_utils.h:81
 (inlined by) esp_cpu_wait_for_intr at /opt/esp/idf/components/esp_hw_support/cpu.c:132
0x42002d0e: esp_vApplicationIdleHook at /opt/esp/idf/components/esp_system/freertos_hooks.c:59
0x4037c029: prvIdleTask at /opt/esp/idf/components/freertos/FreeRTOS-Kernel/tasks.c:4307 (discriminator 1)
0x4037b0e5: vPortTaskWrapper at /opt/esp/idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:134

More Information.

This is reproducible for all ESP32-S3s I have tested. It happens for IDF v5.2.1 and v5.2.2

[congyue]

Looks like a dup of this one?

[10mann]

Yes that seems like the same issue, it didn't show up when I searched for the problem. Do you know if there is an official fix coming soon? This doesn't just happen if you short the pins, but also if the bus is busy for any reason.

[congyue]

This commit marks above issue as fixed, which is available on main but not 5.2.2. You need to apply manually since they changed the file path a little bit.
Also the same piece of code has been talked about in many other threads.

[10mann]

Ok I see, thanks for the information

[AxelLin]

This commit marks above issue as fixed, which is available on main but not 5.2.2.

Fixed in v5.2.3, 34abdae