Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in vPortCPUInitializeMutex #1588

Closed
bernd-edlinger opened this issue Feb 7, 2018 · 3 comments
Closed

Crash in vPortCPUInitializeMutex #1588

bernd-edlinger opened this issue Feb 7, 2018 · 3 comments

Comments

@bernd-edlinger
Copy link

I use spi ram extension.

I saw a crash in e676676:

/home/ed/esp/esp-idf/components/freertos/./port.c:311 (vPortCPUInitializeMutex)- assert failed!
abort() was called at PC 0x400861af on core 0
0x400861af: vPortCPUInitializeMutex at /home/ed/esp/esp-idf/components/freertos/./port.c:386


Backtrace: 0x40088677:0x3ffd1fd0 0x400887cf:0x3ffd1ff0 0x400861af:0x3ffd2010 0x400859cb:0x3ffd2030 0x40085a82:0x3ffd2050 0x40085c3c:0x3ffd2070 0x40083eb6:0x3ffd2090 0x40083fbf:0x3ffd20b0 0x400954e0:0x3ffd20d0 0x400d3d94:0x3ffd20f0 0x400d3e54:0x3ffd2120 0x40157ecc:0x3ffd2140 0x4015d837:0x3ffd2160 0x40112576:0x3ffd2190 0x4010abb2:0x3ffd22c0 0x4010b951:0x3ffd23c0 0x4010bbce:0x3ffd2400 0x4010ef5f:0x3ffd2460 0x4010f43f:0x3ffd2480 0x4010e7c7:0x3ffd24b0 0x40115d52:0x3ffd24d0 0x40116062:0x3ffd24f0 0x401161aa:0x3ffd2520 0x40112e51:0x3ffd2550 0x400f4a4a:0x3ffd2570 0x400ee062:0x3ffd2590 0x400d39f3:0x3ffd25b0 0x400d3ce3:0x3ffd25d0 0x400d1998:0x3ffd26c0
0x40088677: invoke_abort at /home/ed/esp/esp-idf/components/esp32/./panic.c:648

0x400887cf: abort at /home/ed/esp/esp-idf/components/esp32/./panic.c:648

0x400861af: vPortCPUInitializeMutex at /home/ed/esp/esp-idf/components/freertos/./port.c:386

0x400859cb: xQueueGenericReset at /home/ed/esp/esp-idf/components/freertos/./queue.c:2037

0x40085a82: prvInitialiseNewQueue at /home/ed/esp/esp-idf/components/freertos/./queue.c:2037
 (inlined by) xQueueGenericCreate at /home/ed/esp/esp-idf/components/freertos/./queue.c:408

0x40085c3c: xQueueCreateMutex at /home/ed/esp/esp-idf/components/freertos/./queue.c:2037

0x40083eb6: lock_init_generic at /home/ed/esp/esp-idf/components/newlib/./locks.c:79

0x40083fbf: _lock_init_recursive at /home/ed/esp/esp-idf/components/newlib/./locks.c:95

0x400954e0: __sfp at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/findfp.c:145

0x400d3d94: _fopen_r at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/fopen.c:138

0x400d3e54: fopen at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/fopen.c:181

0x40157ecc: mbedtls_pk_load_file at /home/ed/esp/esp-idf/components/mbedtls/library/pkparse.c:81

0x4015d837: mbedtls_x509_crt_parse_file at /home/ed/esp/esp-idf/components/mbedtls/library/x509_crt.c:1093
@bernd-edlinger
Copy link
Author

bernd-edlinger commented Feb 7, 2018

I believe this happens because the system is out of low memory when
my application tries to open a file, with needs a new mutex.
The port uses pvPortMalloc to allocate the mutex.
Because this just calls malloc it may return external memory.
But vPortCPUInitializeMutex has the following check:
configASSERT(esp_ptr_internal((const void *) mux));

@mahavirj
Copy link
Member

mahavirj commented Feb 7, 2018

Just for information, this looks similar to already reported issue here,
#1492

As mentioned above, fix for this is in progress, and should get integrated in IDF soon.

@bernd-edlinger
Copy link
Author

Fixed with 16de6bf.
Thanks!

0xFEEDC0DE64 pushed a commit to 0xFEEDC0DE64/esp-idf that referenced this issue May 5, 2021
espressif#1869 exposed a resource exhaustion issue. The current HAL layer for I2C support is designed to use a shared interrupt, But, during debugging to solve the interrupt overloading condition identified in espressif#1588, and the generation of pr espressif#1717, the interrupt allocation parameters were changed.  This change was unnecessary, the code will work successfully with shared interrupts.  So, there is no need to assign a private interrupt for each I2C peripheral.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants