OVMS3-idf

History

Ivan Grokhotkov b6693225c1 spi_flash: implement partition API, drop trivial wrappers This implements esp_partition_read, esp_partition_write, esp_partition_erase_range, esp_partition_mmap. Also removed getters which didn't add much sugar after all.		2016-10-27 17:58:42 +08:00
..
include	spi_flash: implement partition API, drop trivial wrappers	2016-10-27 17:58:42 +08:00
cache_utils.c	spi_flash: move cache operations into separate file	2016-10-27 17:57:29 +08:00
cache_utils.h	spi_flash: move cache operations into separate file	2016-10-27 17:57:29 +08:00
component.mk	Remove SPIUnlock from linker script symbols	2016-10-21 17:50:37 +11:00
flash_mmap.c	spi_flash: implement mmap/munmap	2016-10-27 17:57:29 +08:00
flash_ops.c	spi_flash: change argument types	2016-10-27 17:58:42 +08:00
Kconfig	Kconfig: use 4 spaces to instead 1 tab	2016-09-28 13:24:58 +08:00
partition.c	spi_flash: implement partition API, drop trivial wrappers	2016-10-27 17:58:42 +08:00
README.rst	spi_flash: move cache operations into separate file	2016-10-27 17:57:29 +08:00
spi_flash_rom_patch.c	Replace ROM SPIUnlock function with a version that can't lock flash	2016-10-21 16:12:51 +11:00

README.rst

Driver for SPI flash read/write/erase operations
================================================

Implementation notes
--------------------

In order to perform some flash operations, we need to make sure both CPUs
are not running any code from flash for the duration of the flash operation.
In a single-core setup this is easy: we disable interrupts/scheduler and do
the flash operation. In the dual-core setup this is slightly more complicated.
We need to make sure that the other CPU doesn't run any code from flash.


When SPI flash API is called on CPU A (can be PRO or APP), we start
spi_flash_op_block_func function on CPU B using esp_ipc_call API. This API
wakes up high priority task on CPU B and tells it to execute given function,
in this case spi_flash_op_block_func. This function disables cache on CPU B and
signals that cache is disabled by setting s_flash_op_can_start flag.
Then the task on CPU A disables cache as well, and proceeds to execute flash
operation.

While flash operation is running, interrupts can still run on CPU B.
We assume that all interrupt code is placed into RAM.

Once flash operation is complete, function on CPU A sets another flag,
s_flash_op_complete, to let the task on CPU B know that it can re-enable
cache and release the CPU. Then the function on CPU A re-enables the cache on
CPU A as well and returns control to the calling code.

Additionally, all API functions are protected with a mutex (s_flash_op_mutex).

In a single core environment (CONFIG_FREERTOS_UNICORE enabled), we simply
disable both caches, no inter-CPU communication takes place.