esp32-s3 reboot after some writes to sd card

[napster7c6]

Hello everyone!

I use esp32-s3-mini-1 and SD card (one wire dat0). I have big programm with few tasks, and in main_app I write files to SD (every 2,5-3 sec, about 269-275 bytes)on maximum speed. And after some write cycles esp32 reboots with error.
I have two cards and two devices and test all variables, and problem with using sd card? but I don't undarstand where.

When I use first SD card = 16Gb (14910 Mb), 40MHz, esp reboots always after 171 (~ 8 minutes) cycles of writing with error:

Code: Select all

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

Core  0 register dump:
PC      : 0x400556d5  PS      : 0x00060d30  A0      : 0x8202805d  A1      : 0x3fcf3ab0
A2      : 0x00000000  A3      : 0xfffffffc  A4      : 0x000000ff  A5      : 0x0000ff00
A6      : 0x00ff0000  A7      : 0xff000000  A8      : 0x00000000  A9      : 0x3fcf3ab0
A10     : 0x00060d23  A11     : 0x00000000  A12     : 0x00060d20  A13     : 0x00000000
A14     : 0x3fce3218  A15     : 0x3fce9b40  SAR     : 0x0000000c  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000  LBEG    : 0x400556d5  LEND    : 0x400556e5  LCOUNT  : 0xffffffff

Backtrace:0x400556d2:0x3fcf3ab0 |<-CORRUPTED

Always on the same place of code, where I use fprintf() to file.
And once it reboots with same error on line with fopen()

Code: Select all

Backtrace:0x40375c2e:0x3fcf39b00x4037bb19:0x3fcf39d0 0x403828fa:0x3fcf39f0 0x40376ec3:0x3fcf3a60 0x403770c6:0x3fcf3a80 0x42027f35:0x3fcf3aa0 0x42027fd8:0x3fcf3ad0 0x4202808d:0x3fcf3b00 0x4200e3d2:0x3fcf3b20 0x4200ba24:0x3fcf3b40 0x42006acb:0x3fcf3b80 |<-CORRUPTED

Then I tried anothe SD card = 4Gb (3840 Mb), 20MHz, esp reboots always after 89 cycles (~ 4 minutes) of writing with same error. But! on another place on snprintf() function (a little before first place).

I thought, that problem was with main_app stack size (was 4095, watermark was ~1100+) and added 1024 bytes to stack. Now watermark is about 2500 bytes. But it still reboots.

And if I started device without SD card - all work and try to write (but not write) more than hour without problems.

What to do? Where problem can be?

[ESP_igrr]

Hi napster7c6,

Given the following parts of the crash dump:

Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
EXCVADDR: 0x00000000

it looks like what happens is a NULL pointer dereference.

(You can read the "Fatal Errors" section of the docs to learn more about understanding panic handler output.)

Please check your code and ensure you are not passing a NULL pointer to fprintf and other functions. Make sure you are checking results of functions such as fopen, memory allocation functions, and so on.

[napster7c6]

Hi, I alredy read it, and I check pointer and in code and I checked it by logged ESP_LOGE(...). It was first what I've done. Then I found, that it can be stack overload (but adding +1kB to stack has no effect).

I can't decode first error, where backtrace is with two addresses, but I decode second error, with big backtrace:

Code: Select all

0x40375c2e: panic_abort at D:/esp/esp-idf/components/esp_system/panic.c:402
0x4037bb19: esp_system_abort at D:/esp/esp-idf/components/esp_system/esp_system.c:128
0x403828fa: abort at D:/esp/esp-idf/components/newlib/abort.c:46
0x40376ec3: lock_init_generic at D:/esp/esp-idf/components/newlib/locks.c:75
0x403770c6: __retarget_lock_init_recursive at D:/esp/esp-idf/components/newlib/locks.c:293
0x42027f35: __sfp at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/findfp.c:175
0x42027fd8: _fopen_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/fopen.c:126
0x4202808d: fopen at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/fopen.c:168
0x4200e3d2: sdCard_writeStr2NewFile at D:/1SVN/external/SURRUS/SM-4G/REV1/firmware_esp/trunk/components/Modules/sdCard/sdCard.c:201
0x4200ba24: TelemetryDataManager_saveCurrentRecord at D:/1SVN/external/SURRUS/SM-4G/REV1/firmware_esp/trunk/components/Modules/telemetryDataManager/telemetryDataManager.c:235
0x42006acb: app_main at D:/1SVN/external/SURRUS/SM-4G/REV1/firmware_esp/trunk/main/main.c:831
0x4203fa68: main_task at D:/esp/esp-idf/components/freertos/port/port_common.c:141 (discriminator 2)
0x4037e961: vPortTaskWrapper at D:/esp/esp-idf/components/freertos/port/xtensa/port.c:131

[napster7c6]

You was right! First problem solved! I rewrite part of code with pointers - add intermediate variable, into which I put the pointer and after this action check pointer.

How it was:

Code: Select all

snprintf(msgString, sizeof(msgString), "%s", Data_currentRecordToJson(&msgIdx)); // собрали строку новых данных

here checked poiner in Data_currentRecordToJson(&msgIdx)

Now:

Code: Select all

pointer_to_json_str = Data_currentRecordToJson(&msgIdx);
if (pointer_to_json_str != NULL)
{
	snprintf(msgString, sizeof(msgString), "%s", pointer_to_json_str); // собрали строку новых данных
}

Changing this part of code solved problem with both SD cadrs with snpintf and fprinf.
Now there is problem with fopen, and it shows after 171 cycles of writing with both SD cards and looks like:

Code: Select all

E (463938) main_app1:  

abort() was called at PC 0x40376ec7 on core 0
0x40376ec7: lock_init_generic at D:/esp/esp-idf/components/newlib/locks.c:75

Backtrace:0x40375c32:0x3fcf41b00x4037bb1d:0x3fcf41d0 0x403828fe:0x3fcf41f0 0x40376ec7:0x3fcf4260 0x403770ca:0x3fcf4280 0x42027f85:0x3fcf42a0 0x42028028:0x3fcf42d0 0x420280dd:0x3fcf4300 0x4200e3d7:0x3fcf4320 0x4200ba28:0x3fcf4340 0x42006b2d:0x3fcf4380 0x4203fab8:0x3fcf45c0 0x4037e965:0x3fcf45e0
0x40375c32: panic_abort at D:/esp/esp-idf/components/esp_system/panic.c:402
0x4037bb1d: esp_system_abort at D:/esp/esp-idf/components/esp_system/esp_system.c:128
0x403828fe: abort at D:/esp/esp-idf/components/newlib/abort.c:46
0x40376ec7: lock_init_generic at D:/esp/esp-idf/components/newlib/locks.c:75
0x403770ca: __retarget_lock_init_recursive at D:/esp/esp-idf/components/newlib/locks.c:293
0x42027f85: __sfp at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/findfp.c:175
0x42028028: _fopen_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/fopen.c:126
0x420280dd: fopen at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32s3-elf/src/newlib/newlib/libc/stdio/fopen.c:168
0x4200e3d7: sdCard_writeStr2NewFile at D:/1SVN/external/SURRUS/SM-4G/REV1/firmware_esp/trunk/components/Modules/sdCard/sdCard.c:203
0x4200ba28: TelemetryDataManager_saveCurrentRecord at D:/1SVN/external/SURRUS/SM-4G/REV1/firmware_esp/trunk/components/Modules/telemetryDataManager/telemetryDataManager.c:235
0x42006b2d: app_main at D:/1SVN/external/SURRUS/SM-4G/REV1/firmware_esp/trunk/main/main.c:835
0x4203fab8: main_task at D:/esp/esp-idf/components/freertos/port/port_common.c:141 (discriminator 2)
0x4037e965: vPortTaskWrapper at D:/esp/esp-idf/components/freertos/port/xtensa/port.c:131

I find similar problem here https://github.com/espressif/esp-idf/issues/1715 and it is in same place in component/newlib/locks.
my esp-idf version 4.4

[ESP_igrr]

According to the linked issue, this happens if there is not enough heap memory to initialize a mutex. Could you check if you are running out of heap memory, e.g. by printing the size of heap memory available before opening the file?

[napster7c6]

Hello again! I was distracted by updating the esp-idf to version 5.1 and it was ... not easy)
I checked heap size in the main_app cycle by using

Code: Select all

heap_caps_get_free_size(MALLOC_CAP_8BIT)

and somewhere is leakage, heap decreases by about 2200+ bytes every cycle. And I know that it is in module with SD card, will look for.
Thank you)

[napster7c6]

Topic can be closed, all problems are solved