I have a task in my code that received data through SPI every seconds and I put a log in this task.
Code: Select all
ESP_LOGI(LOG_MODULE, "%s", __FUNCTION__);
spi_cm_app.c:1387 is where the log function is called.I (1736525) SPI_APP: SPI_CM_APP_NewInfo
abort() was called at PC 0x40082d1b on core 0
0x40082d1b: lock_init_generic at C:/ESP/esp-idf/components/newlib/locks.c:81
ELF file SHA256: 92ed14ae19f1ecd9
Backtrace: 0x4008e785:0x3ffde300 0x4008eb19:0x3ffde320 0x40082d1b:0x3ffde340 0x40082e32:0x3ffde360 0x401fc3e6:0x3ffde380 0x401f94f0:0x3ffde4a0 0x401fc465:0x3ffde7b0 0x402063b1:0x3ffde7e0 0x40093da5:0x3ffde810 0x400dbddf:0x3ffde860 0x400dd376:0x3ffde880 0x400dd7a1:0x3ffde920 0x40090049:0x3ffdea70
0x4008e785: invoke_abort at C:/ESP/esp-idf/components/esp32/panic.c:157
0x4008eb19: abort at C:/ESP/esp-idf/components/esp32/panic.c:174
0x40082d1b: lock_init_generic at C:/ESP/esp-idf/components/newlib/locks.c:81
0x40082e32: _lock_init_recursive at C:/ESP/esp-idf/components/newlib/locks.c:95
0x401fc3e6: __sbprintf at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/vfprintf.c:476
0x401f94f0: _vfprintf_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/vfprintf.c:868 (discriminator 5)
0x401fc465: vprintf at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp32-elf/src/newlib/newlib/libc/stdio/vprintf.c:34
0x402063b1: esp_log_writev at C:/ESP/esp-idf/components/log/log.c:189
0x40093da5: esp_log_write at C:/ESP/esp-idf/components/log/log.c:199
0x400dbddf: SPI_CM_APP_NewInfo at D:/Projects/Folder/SW-Design/Folder/components/spi_cm/spi_cm_app.c:1387
0x400dd376: SPI_CM_LOGI_ProcessCommand at D:/Projects/Folder/SW-Design/Folder/components/spi_cm/spi_cm_logi.c:381 (discriminator 6)
0x400dd7a1: SPI_CM_LOGI_ReceiveTask at D:/Projects/Folder/SW-Design/Folder/components/spi_cm/spi_cm_logi.c:544 (discriminator 6)
0x40090049: vPortTaskWrapper at C:/ESP/esp-idf/components/freertos/port.c:143
Rebooting...
I (12) boot: ESP-IDF v4.1-dirty 2nd stage bootloader
I checked locks.c:81 and I found that:
Code: Select all
...
else
{
/* Create a new semaphore
this is a bit of an API violation, as we're calling the
private function xQueueCreateMutex(x) directly instead of
the xSemaphoreCreateMutex / xSemaphoreCreateRecursiveMutex
wrapper functions...
The better alternative would be to pass pointers to one of
the two xSemaphoreCreate___Mutex functions, but as FreeRTOS
implements these as macros instead of inline functions
(*party like it's 1998!*) it's not possible to do this
without writing wrappers. Doing it this way seems much less
spaghetti-like.
*/
xSemaphoreHandle new_sem = xQueueCreateMutex(mutex_type);
if (!new_sem) {
abort(); /* No more semaphores available or OOM */
}
*lock = (_lock_t)new_sem;
}
...
Do you know if there is a limit in the number of semaphore?
I try to increase the task stack size without any success.
Do you have any idea?
Thank you,
Jean