Chapter 2. API Reference
Flash API or other drivers on SPI1 bus, any operations like read/write/erase or other user defined SPI operations,
regardless to the main flash or other SPI slave devices.
On ESP32-S2, these caches must be disabled while reading/writing/erasing.
When the caches are disabled This means that all CPUs must be running code from IRAM and must only be
reading data from DRAM while flash write operations occur. If you use the API functions documented here, then the
caches will be disabled automatically and transparently. However, note that it will have some performance impact on
other tasks in the system.
There are no such constraints and impacts for flash chips on other SPI buses than SPI0/1.
For differences between IRAM, DRAM, and flash cache, please refer to the application memory layout documenta-
tion.
See also OS functions, SPI Bus Lock.
IRAM-Safe Interrupt Handlers If you have an interrupt handler that you want to execute while a flash operation
is in progress (for example, 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 due to Illegal Instruction exception (for code which should be in IRAM)
or garbage data to be read (for constant data which should be in DRAM).
Note: When working with string 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.
Attention: The SPI0/1 bus is shared between the instruction & data cache (for firmware execution) and the SPI1
peripheral (controlled by the drivers including this SPI flash driver). Hence, calling SPI Flash API on SPI1 bus
(including the main flash) will cause significant influence to the whole system. See Concurrency Constraints for
flash on SPI1 for more details.
Partition table API
ESP-IDF projects use a partition table to maintain information about various regions of SPI flash memory (bootloader,
various application binaries, data, filesystems). More information on partition tables can be found here.
This component provides API functions to enumerate partitions found in the partition table and perform operations
on them. These functions are declared in esp_partition.h:
• esp_partition_find() checks a partition table for entries with specific type, returns an opaque iterator.
• esp_partition_get() returns a structure describing the partition for a given iterator.
• esp_partition_next() shifts the iterator to the next found partition.
• esp_partition_iterator_release() releases iterator returned by esp_partition_find.
• esp_partition_find_first() - a convenience function which returns the structure describing the
first partition found by esp_partition_find.
• esp_partition_read(), esp_partition_write(), esp_partition_erase_range()
are equivalent to spi_flash_read(), spi_flash_write(), spi_flash_erase_range(), but
operate within partition boundaries.
Espressif Systems 743
Submit Document Feedback
Release v4.4