esp-idf: gatt_security_server example crash (Cache disabled but cached memory region accessed) (IDFGH-7342)
Environment
- Development Kit: ESP32-Wrover-Kit
- Module or chip used: ESP32-WROVER-B
- IDF version (run
git describe --tagsto find it): v4.1.2-383-g23e8233506 - Build System: idf.py
- Compiler version (run
xtensa-esp32-elf-gcc --versionto find it): xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0 - Operating System: Ubuntu 16.04
- Power Supply: USB or battery
Problem Description
Repeatable crash (Cache disabled but cached memory region accessed) in example: gatt_security_server example. It crashes during the pairing process if enabled a small value of SPIRAM_MALLOC_ALWAYSINTERNAL, e.g. 50
Enabled options via menuconfig
Component config > ESP32-specific > Support for external, SPI-connected RAM > SPI RAM config:
(50) Maximum malloc() size, in bytes, to always put in internal memory
Component config > ESP32-specific > Support for external, SPI-connected RAM > SPI RAM config > SPI RAM access method:
(x) Make RAM allocatable using malloc() as well
The following is not enabled to ensure BT stack does not use dynamic allocation
BT_ALLOCATION_FROM_SPIRAM_FIRST
BT_BLE_DYNAMIC_ENV_MEMORY
Expected Behavior
- When the app starts, it starts the BLE server and advertising.
- When the client connects to the server, pairing is initiated on the client side, e.g. Android/iOS smartphone.
- After the smartphone confirms the pairing, the server app is able to complete the pairing process and saves the bonded device information.
Actual Behavior
In step3, the BLE server app crashes and the crash is repeatable with the following message:
Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed)
Steps to reproduce
Simply enable the sdkconfig flags as described in the problem description. It crashes every time when pairing is performed. If the value of SPIRAM_MALLOC_ALWAYSINTERNAL is larger, say 100, the crash is gone.
Code to reproduce this issue
use the example gatt_security_server example without code modification.
Debug Logs
Trying out to locate where it crashes, by inserting some debug log in esp-idf/components/bt/host/bluedroid/btc/core/btc_dm.c
static void btc_dm_ble_auth_cmpl_evt (tBTA_DM_AUTH_CMPL *p_auth_cmpl)
{
...
if (p_auth_cmpl->success) {
...
printf(">>> before btc_storage_get_remote_addr_type()\n");
if (btc_storage_get_remote_addr_type(&bdaddr, &addr_type) != BT_STATUS_SUCCESS) {
printf(">>>before btc_storage_set_remote_addr_type()\n");
btc_storage_set_remote_addr_type(&bdaddr, p_auth_cmpl->addr_type, true);
}
printf(">>> before btc_storage_set_ble_dev_auth_mode()\n");
btc_storage_set_ble_dev_auth_mode(&bdaddr, p_auth_cmpl->auth_mode, true);
printf(">>> before btc_dm_save_ble_bonding_keys()\n");
btc_dm_save_ble_bonding_keys();
printf(">>> after btc_dm_save_ble_bonding_keys()\n");
...
When the app crashes, the debug log is seen.
I (1869) SEC_GATTS_DEMO: app_main init bluetooth
I (2039) SEC_GATTS_DEMO: The number handle = 8
I (2079) SEC_GATTS_DEMO: advertising start success
I (12729) SEC_GATTS_DEMO: ESP_GATTS_CONNECT_EVT
W (15369) BT_SMP: FOR LE SC LTK IS USED INSTEAD OF STK
I (15559) SEC_GATTS_DEMO: key type = [ESP_LE_KEY_LENC]
I (15559) SEC_GATTS_DEMO: key type = ESP_LE_KEY_PENC
I (15559) SEC_GATTS_DEMO: key type = ESP_LE_KEY_LID
I (15789) SEC_GATTS_DEMO: key type = ESP_LE_KEY_PID
>>> before btc_storage_get_remote_addr_type()
>>> before btc_storage_set_ble_dev_auth_mode()
>>> before btc_dm_save_ble_bonding_keys()
Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed)
Other items if possible
- [x ] sdkconfig file (attach the sdkconfig file from your project folder) sdkconfig.txt
The issue is in fact found in a large ESP32 application that needs to reserve most IRAM/internal memory to FreeRTOS tasks’ stack memory. So far, most components work perfectly with the memory optimization except for the crash issue found in Bluedroid.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 17 (5 by maintainers)
Commits related to this issue
- components/coex: Make sure sempher and queue used in isr is in DRAM Closes https://github.com/espressif/esp-idf/issues/9032 Closes https://github.com/espressif/esp-idf/issues/8928 Closes https://gith... — committed to espressif/esp-idf by blueMoodBHD 2 years ago
- components/coex: Make sure sempher and queue used in isr is in DRAM Closes https://github.com/espressif/esp-idf/issues/9032 Closes https://github.com/espressif/esp-idf/issues/8928 Closes https://gith... — committed to espressif/esp-idf by blueMoodBHD 2 years ago
- components/coex: Make sure sempher and queue used in isr is in DRAM Closes https://github.com/espressif/esp-idf/issues/9032 Closes https://github.com/espressif/esp-idf/issues/8928 Closes https://gith... — committed to espressif/esp-idf by blueMoodBHD 2 years ago
- components/coex: Make sure sempher and queue used in isr is in DRAM Closes https://github.com/espressif/esp-idf/issues/9032 Closes https://github.com/espressif/esp-idf/issues/8928 Closes https://gith... — committed to espressif/esp-idf by blueMoodBHD 2 years ago
- components/coex: Make sure sempher and queue used in isr is in DRAM Closes https://github.com/espressif/esp-idf/issues/9032 Closes https://github.com/espressif/esp-idf/issues/8928 Closes https://gith... — committed to espressif/esp-idf by blueMoodBHD 2 years ago
The problem has been fixed. You can use the master branch or our latest 4.4 branch for testing.