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 --tags to find it): v4.1.2-383-g23e8233506
  • Build System: idf.py
  • Compiler version (run xtensa-esp32-elf-gcc --version to 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

  1. When the app starts, it starts the BLE server and advertising.
  2. When the client connects to the server, pairing is initiated on the client side, e.g. Android/iOS smartphone.
  3. 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

Most upvoted comments

The problem has been fixed. You can use the master branch or our latest 4.4 branch for testing.