esp-idf: [TW#14555] Crash on WROVER working with flash pSRAM memory (IDFGH-857)

I am working on a WROVER module using the latest ESP-IDF and toolchain for WROVER as of the date of this post. When I run my application (which is very large … too much to simply supply you as a sample), I crash with the following exception log:

Guru Meditation Error: Core  0 panic'ed (Cache disabled but cached memory region accessed)
Register dump:
PC      : 0x400953ed  PS      : 0x00060b34  A0      : 0x80095b3c  A1      : 0x3ffce760  
0x400953ed: esp_rom_spiflash_read_data at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./spi_flash_rom_patch.c:412

A2      : 0x3ffae270  A3      : 0x001d2500  A4      : 0x3f800764  A5      : 0x00000050  
A6      : 0xf0000040  A7      : 0x00000005  A8      : 0x0000000f  A9      : 0x00000001  
A10     : 0x00042080  A11     : 0x3f800764  A12     : 0x00000ffc  A13     : 0x00000002  
A14     : 0x00000000  A15     : 0xff000000  SAR     : 0x00000020  EXCCAUSE: 0x00000007  
EXCVADDR: 0x00000000  LBEG    : 0x400012c5  LEND    : 0x400012d5  LCOUNT  : 0xfffffff6  

Backtrace: 0x400953ed:0x3ffce760 0x40095b3c:0x3ffce780 0x4008341b:0x3ffce7a0 0x40172332:0x3ffce800 0x401730c5:0x3ffce830 0x40174109:0x3ffce860 0x40174405:0x3ffce8d0 0x401759bd:0x3ffce910 0x40172d84:0x3ffce950 0x400df295:0x3ffce980 0x400deb18:0x3ffce9f0 0x4000bcc8:0x3ffcea10 0x4016894c:0x3ffcea30 0x400e5026:0x3ffcea50 0x400f5d2a:0x3ffceac0 0x400f9f38:0x3ffceb20 0x400f57b0:0x3ffceb40 0x400f5a84:0x3ffceba0 0x400f5c9d:0x3ffcec30 0x400f5ec8:0x3ffcec90 0x40108dac:0x3ffced60 0x400def66:0x3ffced80
0x400953ed: esp_rom_spiflash_read_data at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./spi_flash_rom_patch.c:412

0x40095b3c: esp_rom_spiflash_read at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./spi_flash_rom_patch.c:586

0x4008341b: spi_flash_read at /home/kolban/esp32/wrover/esp-idf/components/spi_flash/./flash_ops.c:405

0x40172332: esp32_spi_flash_read at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./esp_spiffs.c:66

0x401730c5: spiffs_phys_rd at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_cache.c:143

0x40174109: spiffs_object_find_object_index_header_by_name_v at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_nucleus.c:1114

0x40174405: spiffs_obj_lu_find_entry_visitor at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_nucleus.c:1114

0x401759bd: spiffs_object_find_object_index_header_by_name at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_nucleus.c:1655

0x40172d84: SPIFFS_stat at /home/kolban/esp32/esptest/apps/workspace/duktape/components/spiffs/./spiffs_hydrogen.c:795

0x400df295: vfs_stat at /home/kolban/esp32/esptest/apps/workspace/duktape/main/./duktape_spiffs.c:76

0x400deb18: esp_vfs_stat at /home/kolban/esp32/wrover/esp-idf/components/vfs/./vfs.c:283 (discriminator 3)

0x4016894c: stat at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/syscalls/../../../.././newlib/libc/syscalls/sysstat.c:13

0x400e5026: js_fs_statSync at /home/kolban/esp32/esptest/apps/workspace/duktape/main/./module_fs.c:232

0x400f5d2a: duk__handle_call_inner at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f9f38: duk_handle_call_unprotected at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f57b0: duk__js_execute_bytecode_inner at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f5a84: duk_js_execute_bytecode at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f5c9d: duk__handle_call_inner at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400f5ec8: duk_handle_call_protected at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x40108dac: duk_pcall at /home/kolban/esp32/esptest/apps/workspace/duktape/build/duktape/duk_api_stack.c:3752

0x400def66: duktape_task at /home/kolban/esp32/esptest/apps/workspace/duktape/main/./duktape_task.c:276


CPU halted.

As we see, we are failing deep in the heart of what appears to be ROM based code and far outside of my comprehension skills. I will be happy to switch on any additional diagnostics requested or demonstrate live via screen share.

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 20 (13 by maintainers)

Commits related to this issue

Use real flash mode and frequency for bootloader (#873) * Use real flash mode and frequency for bootloader * Use real flash mode and frequency for bootloader — committed to 0xFEEDC0DE64/esp-idf by ivankravets 7 years ago

Most upvoted comments

Currently, when using the pSRAM, you must make sure that buffers passed to spi_flash_read function (and spi_flash_write as well) are not located in external memory. If the buffer coming from the upper layer (in your case that is SPIFFS, spiffs_phys_rd ) can be allocated in external memory, you need to create a temporary buffer using heap_caps_malloc(size, MALLOC_CAP_DMA); to get some internal memory, read into this temporary buffer, and then copy to the buffer passed in by the application (which may be in pSRAM region).

The reason for this is that when we access SPI flash, we disable the cache, which is the mechanism which is used to memory-map SPI flash and SPI RAM into CPU’s address space. With cache disabled, attempts to access memory-mapped SPI flash and SPI RAM will fail. This is why the buffer passed to spi_flash_read/spi_flash_write must be in the internal memory.

We will make this automatic within spi_flash_read functions, before integrating pSRAM support into master. For now, you need to do this yourself in your application.

Another thing to note: the stack of the task calling spi_flash_* functions must also be located in the internal memory, not in pSRAM. If it was in pSRAM, it would suddenly become inaccessible once cache is disabled inside spi_flash functions, which is certainly not going to end well. So make sure you that the stack is allocated in the internal memory. @Spritetm may give more guidance on that, as I am not sure how this is currently controlled in the pSRAM support branch.

igrr on Aug 3, 2017

I think you mean pvPortMallocCaps

negativekelvin on Aug 4, 2017