# Concurrency Constraints for Flash on SPI0/1

[中文]

The SPI0/1 bus is shared between the cache and the SPI1 peripheral (controlled by the drivers including this SPI Flash driver). Operations to SPI1 may cause significant influence to the cache and hence the whole system. There are no such constraints and impacts for flash chips connected to other SPI buses, which are not covered in this document.

There are three kinds of activities that can happen on SPI0/1 bus:

- Flash writing operations (via SPI1). For example, erasing, page programming, or status register writing commands (e.g., `SE`, `PP`, and `WRSR`). During these commands, the flash is in a unreadable state. The CPU and the cache have to wait until the writing command is completed. APIs below can trigger writing commands:

  > - Calling non_encrypted SPI flash write API (`esp_flash_write()`, `esp_flash_erase_region()`, etc.)

  > - Calling `esp_flash_write_encrypted()`

- Short operations (via SPI1, includes non-writing flash commands). APIs below can trigger short operations:

  > - Calling non_encrypted SPI flash read API (`esp_flash_read()`, etc.)

  > - Or other drivers on SPI1 bus for user defined SPI operations (enable experimental feature CONFIG_SPI_FLASH_SHARE_SPI1_BUS)

- Cache read (via SPI0). Following API and operations can trigger cache read:

  > - Code execution from SPI Flash or PSRAM

  > - Fetch static data of .data/.rodata/.bss segment from SPI Flash or PSRAM

  > - All other read/write operation to the PSRAM via the heap or esp_himem

  > - Read from area mapped to SPI Flash, includes:

  >   > - mmap-like functions: `spi_flash_mmap()`, `spi_flash_mmap_pages()`, `esp_mmu_map()`, `bootloader_mmap()`, and `esp_partition_mmap()`.

  >   > - Functions relying on `spi_flash_mmap()`: `esp_partition_find()`, `esp_partition_register_external()`.

  >   > - Encrypted flash read/write APIs `esp_flash_read_encrypted()` and `esp_flash_write_encrypted()` (on esp32, or for data validation).

Caches are disabled during all SPI1 operations. Most tasks will be disabled, and access to Flash/PSRAM is forbidden. See Cache Disabled (Default) for more details.

See OS Functions and SPI Bus Lock for the detailed information of software implementation.

## Cache Disabled (Default)

Caches are disabled during SPI1 operations. All SPI1 operations will automatically and transparently disable the caches.

When the caches are disabled, all non-IRAM-safe interrupts will be disabled, and all other tasks are suspended. The other core will be polling in a busy loop. Only IRAM-safe interrupt handlers will be executed. These will be restored when the Flash operation completes.

See IRAM-Safe Interrupt Handlers for information on how to prevent an interrupt handler from being disabled when the cache is disabled.

When the cache is disabled, all CPUs should execute code and access data only from internal RAM. For differences between internal RAM (e.g., IRAM, DRAM) and flash cache, please refer to the application memory layout documentation.

### IRAM-Safe Interrupt Handlers

For interrupt handlers which need to execute when the cache is disabled (e.g., for low latency operations), set the `ESP_INTR_FLAG_IRAM` flag when the interrupt handler is registered.

You must ensure that all data and functions accessed by these interrupt handlers, including the ones that handlers call, are located in IRAM or DRAM. See How to Place Code in IRAM.

If a function or symbol is not correctly put into IRAM/DRAM, and the interrupt handler reads from the flash cache during a flash operation, it will cause a crash. This may be due to an Illegal Instruction exception (for code which should be in IRAM) or garbage data being read (for constant data which should be in DRAM).

Note

When working with strings in ISRs, it is not advised to use `printf` and other output functions. For debugging purposes, use `ESP_DRAM_LOGE()` and similar macros when logging from ISRs. Make sure that both `TAG` and format string are placed into `DRAM` in that case.

### Non-IRAM-Safe Interrupt Handlers

If the `ESP_INTR_FLAG_IRAM` flag is not set when registering, the interrupt handler will not be executed when the caches are disabled. Once the caches are restored, the non-IRAM-safe interrupts will be re-enabled. After this moment, the interrupt handler will run normally again. This means that as long as caches are disabled, the corresponding hardware events will not occur.

Was this page helpful?

- Thank you! We received your feedback.
- If you have any comments, fill in Espressif Documentation Feedback Form.

- We value your feedback.
- Let us know how we can improve this page by filling in Espressif Documentation Feedback Form.