CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL values <=256 crash when debugging

[dedvalson]

It appears that when hardware breakpoints are in use via JTAG there is some memory being allocated in external memory that needs to be in internal memory. Setting CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL to a high value will mask this by pushing the allocation into internal memory.

It is very easy to reproduce this. Start with the ESP-IDF HelloWorld and use menuconfig to enable external RAM and set CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL to a value of 256 or lower. If you then execute the program with JTAG debugging taking place and breakpoints active the program will crash before reaching app_main.

The console output when this takes place is as follows:

Code: Select all

I (268) cpu_start: App cpu up.
I (1173) spiram: SPI SRAM memory test OK
I (1173) heap_init: Initializing. RAM available for dynamic allocation:
I (1174) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1180) heap_init: At 3FFB2FF0 len 0002D010 (180 KiB): DRAM
I (1186) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1192) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1199) heap_init: At 4008CDC0 len 00013240 (76 KiB): IRAM
I (1205) cpu_start: Pro cpu start user code
I (1210) spiram: Adding pool of 4096K of external SPI memory to heap allocator
I (225) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (226) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
Guru Meditation Error: Core  1 panic'ed (LoadProhibited) at pc=400d4705. Setting bp and returning..

Since the debugger is active it does not produce a stack trace but I was able to obtain the following from my debugger:

Code: Select all

find_task_in_twdt_list(handle = 0x3ffb58c0, all_reset = 0x3ffb57a0)
	at C:\SysGCC\esp32-16\esp-idf\v3.3b\components\esp32\task_wdt.c(94)
esp_task_wdt_reset
	at C:\SysGCC\esp32-16\esp-idf\v3.3b\components\esp32\task_wdt.c(313)
idle_hook_cb
	at C:\SysGCC\esp32-16\esp-idf\v3.3b\components\esp32\task_wdt.c(80)
esp_vApplicationIdleHook
	at C:\SysGCC\esp32-16\esp-idf\v3.3b\components\esp32\freertos_hooks.c(51)
prvIdleTask(pvParameters = 0x0)
	at C:\SysGCC\esp32-16\esp-idf\v3.3b\components\freertos\tasks.c(3382)
vPortTaskWrapper(pxCode = 0x40088938 <prvIdleTask>, pvParameters = 0x0)
	at C:\SysGCC\esp32-16\esp-idf\v3.3b\components\freertos\port.c(143)

I don't think the crash location is all that relevant though because I think it is just the victim of earlier memory corruption. The location of the crash moves around with different values for CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL;

This takes place with IDF version 3.3 or 4.0

If anyone has suggestions to better diagnose this or work around it I would appreciate your thoughts.

Thanks,

Don

[ESP_Angus]

Hi Don,

Thanks for reporting this. We'll investigate and get back to you ASAP.

Angus

[ESP_igrr]

Hi dedvalson,

At the moment we don't support breakpoints in Flash in situations when PSRAM is used. If you are using PSRAM, please limit the breakpoints to RAM software breakpoints plus 2 hardware breakpoints.
We will add support for Flash breakpoints along with PSRAM in the next OpenOCD release.

[dedvalson]

Hi dedvalson,

At the moment we don't support breakpoints in Flash in situations when PSRAM is used. If you are using PSRAM, please limit the breakpoints to RAM software breakpoints plus 2 hardware breakpoints.
We will add support for Flash breakpoints along with PSRAM in the next OpenOCD release.

Thanks for the responses. That is consistent with what I am seeing. If I limit as you describe the problem doesn't seem to occur.

Don

[ESP_igrr]

Sorry for the late update. Support for flash breakpoints when PSRAM is enabled was added in OpenOCD release v0.10.0-esp32-20200309: https://github.com/espressif/openocd-es ... 2-20200309.