"Cache disabled but cached memory region accessed" using stdlib fun

[ct_reloc]

We are experiencing a system crash after enabling the ADF framework with the external PSRAM on a custom board with a ESP32-S3 MCU.

The crash is triggered in a specific code segment uncorrelated to the ADF code. It always crashes in a scanf call running in a task. The audio pipelines are built but not started yet.
In previous attempts we also see the same crash triggered from a snprintf call.

We know that with the PSRAM, it is important to have all the ISR code in IRAM, but what's happened in a stdlib function?

I leave below the log.
Thank you very much.

Code: Select all

Guru Meditation Error: Core  / panic'ed (Cache disabled but cached memory region accessed).
Write back error occurred while dcache tries to write back to flash
The following backtrace may not indicate the code that caused Cache invalid access


Core  0 register dump:
PC      : 0x40379f5a  PS      : 0x00060834  A0      : 0x820043a9  A1      : 0x3fca5280
--- 0x40379f5a: esp_cpu_wait_for_intr at C:/Espressif/frameworks/esp-idf-v5.2.3/components/esp_hw_support/cpu.c:145

A2      : 0x00000000  A3      : 0x0000cdcd  A4      : 0x8037e859  A5      : 0x3fc98430
A6      : 0x00060023  A7      : 0x00000001  A8      : 0x8202a44a  A9      : 0x3fca5240
A10     : 0x00000000  A11     : 0x0000cdcd  A12     : 0x8037e859  A13     : 0x3fc98430
A14     : 0x00060b23  A15     : 0x3fca5450  SAR     : 0x0000001e  EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000


Backtrace: 0x40379f57:0x3fca5280 0x420043a6:0x3fca52a0 0x4037fb85:0x3fca52c0 0x4037e4a1:0x3fca52e0
--- 0x40379f57: xt_utils_wait_for_intr at C:/Espressif/frameworks/esp-idf-v5.2.3/components/xtensa/include/xt_utils.h:81
 (inlined by) esp_cpu_wait_for_intr at C:/Espressif/frameworks/esp-idf-v5.2.3/components/esp_hw_support/cpu.c:132
0x420043a6: esp_vApplicationIdleHook at C:/Espressif/frameworks/esp-idf-v5.2.3/components/esp_system/freertos_hooks.c:59
0x4037fb85: prvIdleTask at C:/Espressif/frameworks/esp-idf-v5.2.3/components/freertos/FreeRTOS-Kernel/tasks.c:4307 (discriminator 1)
0x4037e4a1: vPortTaskWrapper at C:/Espressif/frameworks/esp-idf-v5.2.3/components/freertos/FreeRTOS-Kernel/portable/xtensa/port.c:134



Core  1 register dump:
PC      : 0x42037416  PS      : 0x00060434  A0      : 0x82030edc  A1      : 0x3fcb3230
--- 0x42037416: __ssvfscanf_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/src/newlib/newlib/libc/stdio/svfscanf.c:677

A2      : 0x3c057b10  A3      : 0x3fcb35b0  A4      : 0x00000000  A5      : 0x00000000
A6      : 0x00000000  A7      : 0x3fcb3230  A8      : 0x00000000  A9      : 0x00000001
A10     : 0x00000075  A11     : 0x00000056  A12     : 0x3c06b2c4  A13     : 0x3c06b420
A14     : 0x00000001  A15     : 0x3fca4040  SAR     : 0x00000018  EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000  LBEG    : 0x400556d5  LEND    : 0x400556e5  LCOUNT  : 0xfffffffd
--- 0x400556d5: r_rwbt_isr in ROM
0x400556e5: r_rwbt_isr in ROM



Backtrace: 0x42037413:0x3fcb3230 0x42030ed9:0x3fcb35b0 0x4200c669:0x3fcb3670 0x4200caf6:0x3fcb36c0 0x420095ee:0x3fcb3730 0x4200966a:0x3fcb37b0 0x420097ba:0x3fcb37d0 0x4037e4a1:0x3fcb3880
--- 0x42037413: __ssvfscanf_r at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/src/newlib/newlib/libc/stdio/svfscanf.c:673
0x42030ed9: sscanf at /builds/idf/crosstool-NG/.build/HOST-x86_64-w64-mingw32/xtensa-esp-elf/src/newlib/newlib/libc/stdio/sscanf.c:439 (discriminator 1)
0x4200c669: CellEG21_networkStatusCSUpdate at XXXXX/main/lib/driver/cell_eg21/cell_eg21.c:935
[...] Upper stack calls[...]

[MicroController]

We know that with the PSRAM, it is important to have all the ISR code in IRAM, but what's happened in a stdlib function?

Actually, having (ISR) code in IRAM is unrelated to PSRAM (unless you execute code from PSRAM). The cache is disabled whenever flash memory is written to.
Note that not only code needs to be in IRAM but also all constant data this code may need. Specifically, the format strings (literals) you pass as arguments to printf/scanf are likely located in flash and therefore inaccessible while the cache is disabled.

Solution:

Code: Select all

void IRAM_ATTR gpio_isr_handler(void* arg)
{
   const static DRAM_ATTR uint8_t INDEX_DATA[] = { 45, 33, 12, 0 };
   const static char *MSG = DRAM_STR("I am a string stored in RAM");
}

[ct_reloc]

Thank you for pointing that out. I missed that detail.

However, in my code the scanf call is made from a task so I suppose that no SPI access is running because the documentation says that:

In some situations ESP-IDF will temporarily disable access to external SPI Flash and SPI RAM via caches. For example, this happens with spi_flash APIs are used to read/write/erase/mmap regions of SPI Flash. In these situations, tasks are suspended, and interrupt handlers not registered with ESP_INTR_FLAG_IRAM are disabled

https://docs.espressif.com/projects/esp ... n-accessed


So, is there anything else that disable the cache or did I miss anything else?

[ct_reloc]

It seems that enabling the sdkconfig option:

"Move Read-Only Data in Flash to PSRAM"

solves the issue.
So something related to some rodata access can be actually possible.

Do you have any hints?

[MicroController]

Code: Select all

Guru Meditation Error: Core  / panic'ed (Cache disabled but cached memory region accessed).
Write back error occurred while dcache tries to write back to flash

Haven't seen that specific error message before, so I'll just throw in some guesses:
Potentially, the "Cache disabled but..." message is inaccurate here and in fact output for any cache error thrown; then it may actually not have anything to do with a disabled cache.

I don't know that "dcache tries to write back to flash" is how flash writes are supposed to work, which makes me suspect that maybe your code somehow erroneously tried to write to a memory address which is actually mapped to flash and can't be written to. The specific symptom may or may not go away when the address written to is moved to PSRAM instead of flash, but a corruption of the some PSRAM data may occur instead.