This function disables cache on CPU B and signals that the cache is disabled by setting the s_flash_op_can_start flag. This API wakes up a high priority task on CPU B and tells it to execute a given function, in this case, spi_flash_op_block_func.
When SPI flash API is called on CPU A (can be PRO or APP), start the spi_flash_op_block_func function on CPU B using the esp_ipc_call API.
In a dual-core setup, this is slightly more complicated as the SDK needs to make sure that the other CPU is not running any code from flash. In a single-core setup, the SDK does it by disabling interrupts/scheduler before performing the flash operation. In order to perform some flash operations, it is necessary to make sure that both CPUs are not running any code from flash for the duration of the flash operation: Note that since memory mapping happens in pages, it may be possible to read data outside of the partition provided to esp_partition_mmap, regardless of the partition boundary. Spi_flash_mmap() must be given a 64 KB aligned physical address.Įsp_partition_mmap() may be given any arbitrary offset within the partition, it will adjust the returned pointer to mapped memory as necessary. Spi_flash_munmap() unmaps previously mapped region.Įsp_partition_mmap() maps part of a partition into the instruction space or data space of the CPU.ĭifferences between spi_flash_mmap() and esp_partition_mmap() are as follows:
Spi_flash_mmap() maps a region of physical flash addresses into instruction space or data space of the CPU. Memory mapping API are declared in esp_spi_flash.h and esp_partition.h: Decryption is performed at the hardware level. Reading data from flash using a memory mapped region is the only way to decrypt contents of flash when flash encryption is enabled. Note that some pages are used to map the application itself into memory, so the actual number of available pages may be less than the capability of the hardware.
See the technical reference manual for more details and limitations about memory mapping hardware.
Memory mapping hardware can map flash into the data address space and the instruction address space. It is not possible to modify contents of flash memory by writing to a mapped memory region.
This mapping works only for read operations. These functions are declared in esp_partition.h:Įsp_partition_find() checks a partition table for entries with specific type, returns an opaque iterator.Įsp_partition_get() returns a structure describing the partition for a given iterator.Įsp_partition_next() shifts the iterator to the next found partition.Įsp_partition_iterator_release() releases iterator returned by esp_partition_find.Įsp_partition_find_first() - a convenience function which returns the structure describing the first partition found by esp_partition_find.Įsp_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.ĮSP32 features memory hardware which allows regions of flash memory to be mapped into instruction and data address spaces. This component provides API functions to enumerate partitions found in the partition table and perform operations on them. More information on partition tables can be found here. ESP-IDF projects use a partition table to maintain information about various regions of SPI flash memory (bootloader, various application binaries, data, filesystems).