Problem with SPI interrupt during SPIFFS access (IDFGH-1617)

[DMD-Engineering]

ESP32 Wrover Module
arduino-esp32 v1.0.2

I discovered a problem that happens when an spi_slave interrupt occurs during SPIFFS access.
I have the spi_slave initialized to use DMA, and get the following error when this occurs:

Guru Meditation Error: Core 1 panic'ed (Cache disabled but cached memory region accessed)

From the following Exception Decoder listing it must be that the SPIFFS disables cache (which is expected and normal) and when the spi_slave interrupt happens the "freeze_cs" function generates an exception since it is in flash and not in RAM.

Looking at the "spi_slave.c" file, one can see that the "static void freeze_cs" function is indeed a function not in RAM. I believe this is a mistake, since there is a corresponding "static inline void restore_cs" function than will be placed in RAM since it's an inline function and the calling ISR function is in RAM.

Proposed solution is to change:
static void freeze_cs(spi_slave_t *host)
to:
static inline void freeze_cs(spi_slave_t *host)

Does this change make sense?

I'd like to make the change and test it, but I do not know how to recompile to generate an updated library file for esp32-arduino. Can anyone provide instructions on how to make this change to the library?

Thanks!

Decoding stack results
0x400e7f58: freeze_cs at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/driver/spi_slave.c line 89
0x400954bf: esp_rom_spiflash_read_status at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spi_flash/spi_flash_rom_patch.c line 261
0x400954f6: esp_rom_spiflash_wait_idle at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spi_flash/spi_flash_rom_patch.c line 35
0x40095595: esp_rom_spiflash_erase_sector_internal at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spi_flash/spi_flash_rom_patch.c line 121
0x40095a2a: esp_rom_spiflash_erase_sector at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spi_flash/spi_flash_rom_patch.c line 451
0x40082d59: spi_flash_erase_range at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spi_flash/flash_ops.c line 237
0x400f6419: esp_partition_erase_range at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spi_flash/partition.c line 294
0x400fd723: spiffs_api_erase at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs_api.c line 58
0x400ff13e: spiffs_erase_block at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_nucleus.c line 236
0x40101a91: spiffs_gc_erase_block at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_gc.c line 15
0x40101bff: spiffs_gc_quick at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_gc.c line 92
0x400ff3c9: spiffs_obj_lu_find_free at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_nucleus.c line 457
0x400ff718: spiffs_page_move at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_nucleus.c line 828
0x400ffcf6: spiffs_object_update_index_hdr at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_nucleus.c line 1019
0x400fe778: SPIFFS_fupdate_meta at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/spiffs/src/spiffs_hydrogen.c line 988
0x400fd229: vfs_spiffs_update_mtime at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/esp_spiffs.c line 731
0x400fd299: vfs_spiffs_open at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/spiffs/esp_spiffs.c line 458
0x400f326a: esp_vfs_open at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/vfs/vfs.c line 388
0x400f4c2d: _fopen_r at ../../../.././newlib/libc/stdio/fopen.c line 141
0x400f4cb4: fopen at ../../../.././newlib/libc/stdio/fopen.c line 181
0x400d6986: VFSFileImpl::VFSFileImpl(VFSImpl*, char const*, char const*) at C:\Users\DMD\Documents\Arduino\hardware\expressif\esp32\libraries\FS\src\vfs_api.cpp line 236
0x400d6e4f: std::__shared_ptr ::__shared_ptr , VFSImpl*&, char const*, char const*&>(std::_Sp_make_shared_tag, std::allocator const&, VFSImpl*&, char const*&&, char const*&) at c:\users\dmd\appdata\local\arduino15\packages\esp32\tools\xtensa-esp32-elf-gcc\1.22.0-80-g6c4433a-5.2.0\xtensa-esp32-elf\include\c++\5.2.0\ext/new_allocator.h line 120
0x400d7165: VFSImpl::open(char const*, char const*) at c:\users\dmd\appdata\local\arduino15\packages\esp32\tools\xtensa-esp32-elf-gcc\1.22.0-80-g6c4433a-5.2.0\xtensa-esp32-elf\include\c++\5.2.0\bits/shared_ptr.h line 319
0x400d65c8: fs::FS::open(char const*, char const*) at C:\Users\DMD\Documents\Arduino\hardware\expressif\esp32\libraries\FS\src\FS.cpp line 191
0x400d35e6: loop() at C:\Users\DMD\Documents\Arduino\DMD_Sketches\DMD_WiFi/DMD_WiFi.ino line 506
0x400e5af1: loopTask(void*) at C:\Users\DMD\Documents\Arduino\hardware\expressif\esp32\cores\esp32\main.cpp line 19
0x4008b3ad: vPortTaskWrapper at /Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/port.c line 143

[DMD-Engineering]

A further look shows other functions called from the ISR that are also not in IRAM:
xQueueGenericSendFromISR
xQueueReceiveFromISR
portYIELD_FROM_ISR
esp_intr_disable
esp_intr_enable

And since the ISR can yield, there may not be an easy solution to this problem.

[negativekelvin]

Those functions are in IRAM and yielding by itself shouldn't cause a problem because it will yield to the ipc task until the flash operation is done. So it is worth trying.
espressif/arduino-esp32#1142 (comment)

[DMD-Engineering]

@negativekelvin Thanks! I'm trying to understand this a little better. Is the following correct?

A SPIFFS function requiring flash cache disable/access is executing in IRAM. During this time no code should execute from flash due to flash busy with programming/erase functions. Now, say that during this time the spi_slave ISR happens. In addition to the spi_slave ISR itself, if those functions mentioned above are also in IRAM then all is good. But, all the tasks yielded to would also have to be in IRAM too, correct?

BTW, I didn't see where in the source that those functions above are defined to be in IRAM. Could you help point me to that?

Thank much!

[negativekelvin]

Yes. But i don't think you can yield to a task other than the ipc task which has highest priority and is in iram. So the task that was unblocked by the isr won't run until after the flash operation is done. For v3.2 branch it is here

esp-idf/components/esp32/ld/esp32.common.ld

Line 157 in 7f03e70

*libfreertos.a:(.literal .text .literal.* .text.*)