xQueueSemaphoreTake unknown abort()

[Palonso]

Hi,

I'm trying to OTA update an ESP-WROVER device and I have the next output console log:

Code: Select all

D (19:42:16.077) esp_https_ota: Written image length 217617
D (19:42:16.201) esp_https_ota: Written image length 217906
D (19:42:16.230) esp_https_ota: Written image length 218195
D (19:42:16.334) esp_https_ota: Written image length 218484
D (19:42:16.339) esp_https_ota: Written image length 218773
assertion "!( ( xTaskGetSchedulerState() == ( ( BaseType_t ) 0 ) ) && ( xTicksToWait != 0 ) )" failed: file "/home/pablo/esp/esp-idf431/components/freertos/queue.c", line 1456, function: xQueueSemaphoreTake

abort() was called at PC 0x401b551c on core 1
0x401b551c: __assert_func at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)


Backtrace:0x400967ca:0x3ffd5a10 0x40096fe9:0x3ffd5a30 0x4009b362:0x3ffd5a50 0x401b551c:0x3ffd5ac0 0x40097c69:0x3ffd5af0 0x40085394:0x3ffd5b30 0x40085499:0x3ffd5b60 0x400df8b9:0x3ffd5b80 0x400855c1:0x3ffd5ba0 0x401bd3b1:0x3ffd5bc0 0x4013a8fa:0x3ffd5be0 0x4013817a:0x3ffd5c10 0x40138957:0x3ffd5c30 0x4009740a:0x3ffd5c70
0x400967ca: panic_abort at /home/pablo/esp/esp-idf431/components/esp_system/panic.c:368

0x40096fe9: esp_system_abort at /home/pablo/esp/esp-idf431/components/esp_system/system_api.c:112

0x4009b362: abort at /home/pablo/esp/esp-idf431/components/newlib/abort.c:46

0x401b551c: __assert_func at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/stdlib/assert.c:62 (discriminator 8)

0x40097c69: xQueueSemaphoreTake at /home/pablo/esp/esp-idf431/components/freertos/queue.c:1456 (discriminator 2)

0x40085394: lock_acquire_generic at /home/pablo/esp/esp-idf431/components/newlib/locks.c:155

0x40085499: _lock_acquire at /home/pablo/esp/esp-idf431/components/newlib/locks.c:163

0x400df8b9: get_adjusted_boot_time at /home/pablo/esp/esp-idf431/components/newlib/time.c:103

0x400855c1: _gettimeofday_r at /home/pablo/esp/esp-idf431/components/newlib/time.c:178

0x401bd3b1: gettimeofday at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/newlib/newlib/libc/syscalls/sysgettod.c:11

0x4013a8fa: platform_tick_get_ms at /home/pablo/esp/esp-idf431/components/mqtt/esp-mqtt/lib/platform_esp32_idf.c:32

0x4013817a: mqtt_delete_expired_messages at /home/pablo/esp/esp-idf431/components/mqtt/esp-mqtt/mqtt_client.c:1333

0x40138957: esp_mqtt_task at /home/pablo/esp/esp-idf431/components/mqtt/esp-mqtt/mqtt_client.c:1416

0x4009740a: vPortTaskWrapper at /home/pablo/esp/esp-idf431/components/freertos/port/xtensa/port.c:168


ELF file SHA256: bf272f6ba147f6a3

Rebooting...
I (13) boot: ESP-IDF v4.3.1-dirty 2nd stage bootloader
I (13) boot: compile time 14:18:04

Somehow the esp_mqtt_task tries to delete expired messages and it fails when it tries to get the system time, when trying to get a semaphore, which makes no sense since I also get the time (and run more task) in other parts of the main code.

The other thing I get is that the "xTicksToWait != 0" part which fails in the if sentence, how can that parameter be zero when is call internally so should never be 0.

Any idea?

Best regards,
P

[chegewara]

That make sense if you have memory corruption problem and semaphore handle get corrupted eventually.

[Palonso]

That's not possible, I barely have the device for a month and this also happens with another device I have.

Memory corruption seems a little too soon for it.

I was wondering about IRAM functions, if that could have something to do, since the 'lock_aquire' function that fails is in it. And That's also the function that later calls the semaphore.

[chegewara]

It is not a flash memory corruption. It is ram memory corruption in code (just guessing from experience).

[Palonso]

UPDATE:

I tried commenting the problematic lines (1416 and 1411 in mqtt_client.c) in the IDF source code, and the problem still persist in the 'platform_tick_get_ms();' function, which at some point tries to get a semaphore that fails to.

On the other hand,

It is not a flash memory corruption. It is ram memory corruption in code (just guessing from experience).

This goes deep inside IDF since it comes from 'gettimeofday()' function, how can I solve/trace those RAM corruptions?

Any idea?

Regards,
P