led_strip Occasionally, an exception occurs, causing the system to reset (IEC-116)

[hyzgit]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

led_strip

ESP-IDF version.

v5.1.2

Development Kit.

esp32-s3

Used Component version.

2.5.3

More Information.

Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.

Core 1 register dump:
PC : 0x4015f1a7 PS : 0x00060b30 A0 : 0x8015eef2 A1 : 0x3ffdc9f0
0x4015f1a7: rmt_tx_disable at C:/Espressif/frameworks/esp-idf-v5.1.2/components/driver/rmt/rmt_tx.c:773

A2 : 0x00000000 A3 : 0x3f80ea98 A4 : 0x3ff56000 A5 : 0x3f80f450
A6 : 0x3ff56800 A7 : 0x00000003 A8 : 0x8015f1a4 A9 : 0x3ffdc9b0
A10 : 0x00000001 A11 : 0x00000000 A12 : 0x3f80ebfc A13 : 0x00000000
A14 : 0x00000000 A15 : 0x00000000 SAR : 0x0000001e EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
0x4000c2e0: memcpy in ROM

0x4000c2f6: memcpy in ROM

Backtrace: 0x4015f1a4:0x3ffdc9f0 0x4015eeef:0x3ffdca20 0x400deba7:0x3ffdca50 0x400dea76:0x3ffdca90 0x400d91cd:0x3ffdcac0 0x400d9222:0x3ffdcae0
0x4015f1a4: rmt_tx_disable at C:/Espressif/frameworks/esp-idf-v5.1.2/components/driver/rmt/rmt_tx.c:773

0x4015eeef: rmt_disable at C:/Espressif/frameworks/esp-idf-v5.1.2/components/driver/rmt/rmt_common.c:199 (discriminator 2)

0x400deba7: led_strip_rmt_refresh at D:/202303/ESP32/pipeline_bt_sink/managed_components/espressif__led_strip/src/led_strip_rmt_dev.c:76 (discriminator 2)

0x400dea76: led_strip_refresh at D:/202303/ESP32/pipeline_bt_sink/managed_components/espressif__led_strip/src/led_strip_api.c:81 (discriminator 2)

0x400d91cd: led_set_color at D:/202303/ESP32/pipeline_bt_sink/main/play_bt_music_example.c:1235
(inlined by) led_set_color at D:/202303/ESP32/pipeline_bt_sink/main/play_bt_music_example.c:1227

0x400d9222: led_task at D:/202303/ESP32/pipeline_bt_sink/main/play_bt_music_example.c:1369

ELF file SHA256: 4b6ea2f23981d742

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 153911750, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1416
load:0x40078000,len:14476
ho 0 tail 12 room 4
load:0x40080400,len:4
0x40080400: _init at ??:?

load:0x40080404,len:3356
entry 0x4008059c
I (512) cpu_start: Multicore app
I (512) quad_psram: This chip is ESP32-D0WDR2-V3
I (512) esp_psram: Found 2MB PSRAM device
I (515) esp_psram: Speed: 80MHz
I (518) esp_psram: PSRAM initialized, cache is in low/high (2-core) mode.
I (526) cpu_start: Pro cpu up.
I (530) cpu_start: Starting app cpu, entry point is 0x40081738
0x40081738: call_start_cpu1 at C:/Espressif/frameworks/esp-idf-v5.1.2/components/esp_system/port/cpu_start.c:157

I (520) cpu_start: App cpu up.
I (788) esp_psram: SPI SRAM memory test OK
I (798) cpu_start: Pro cpu start user code
I (798) cpu_start: cpu freq: 240000000 Hz
I (798) cpu_start: Application information:

[suda-morris]

@hyzgit Can you try with a newer bugfix release, e.g. 5.1.4?

[robertlipe]

I can't find the code to driver/rmt/ that's being called into question in this project, but I analyzed a very similar sounding failure on ESP32-S3 with large strips NightDriver/FastLED. (The same code on the other dual-core Xtensa parts was fine.)

PlummersSoftwareLLC/NightDriverStrip#515

The fundamental problem there seemed to be an interaction between SPI "disk" access locking the bus and the interrupt code running in instruction RAM and finding that one of the busses disappeared from beneath us while running. That may or may not apply, but I found evidence of variations of that problem in several ESP32/WS281x projects. memcpy() can be unique in being a long-ish running function that may need access to multiple memory busses.

@hyzgit, if you can post a software reproduction case and a reasonable approximation of "occasionally" (i.e. should a developer need a month or a week to declare it working, or will it fail reliably within one minute or so?) the hardware repro case should be easier since you don't actually need lights to test the RMT drivers.