Crash_Override/OVMS3-idf
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

components/esp32,spi_flash: update some comments

Browse source
This commit is contained in:
Ivan Grokhotkov 2016-09-12 19:54:35 +08:00
parent 1b6022bd07
commit 23d5c7579b
3 changed files with 12 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
components/esp32/cpu_start.c
View file

@ -190,7 +190,6 @@ void IRAM_ATTR user_start_cpu1(void) {
;
}
ets_printf("Starting scheduler on APP CPU.\n");
// Start the scheduler on APP CPU
xPortStartScheduler();
}

4
components/esp32/include/esp_ipc.h
View file

@ -25,6 +25,8 @@ typedef void (*esp_ipc_func_t)(void* arg);
* FreeRTOS provides several APIs which can be used to communicate between
* different tasks, including tasks running on different CPUs.
* This module provides additional APIs to run some code on the other CPU.
*
* These APIs can only be used when FreeRTOS scheduler is running.
*/
@ -56,6 +58,7 @@ void esp_ipc_init();
* @param arg arbitrary argument to be passed into function
*
* @return ESP_ERR_INVALID_ARG if cpu_id is invalid
* ESP_ERR_INVALID_STATE if FreeRTOS scheduler is not running
* ESP_OK otherwise
*/
esp_err_t esp_ipc_call(uint32_t cpu_id, esp_ipc_func_t func, void* arg);
@ -75,6 +78,7 @@ esp_err_t esp_ipc_call(uint32_t cpu_id, esp_ipc_func_t func, void* arg);
* @param arg arbitrary argument to be passed into function
*
* @return ESP_ERR_INVALID_ARG if cpu_id is invalid
* ESP_ERR_INVALID_STATE if FreeRTOS scheduler is not running
* ESP_OK otherwise
*/
esp_err_t esp_ipc_call_blocking(uint32_t cpu_id, esp_ipc_func_t func, void* arg);

18
components/spi_flash/esp_spi_flash.c
View file

@ -36,15 +36,14 @@
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.
SPI flash driver starts two tasks (spi_flash_op_block_task), one pinned to
each CPU. Each task is associated with its own semaphore.
When SPI flash API is called on CPU A (can be PRO or APP), we wake up the task
on CPU B by "giving" the semaphore associated with it. Tasks resumes, disables
cache on CPU B, and acknowledges that it has taken the semaphore by setting
a flag (s_flash_op_can_start). Flash API function running on CPU A waits for
this flag to be set. Once the flag is set, it disables cache on CPU A and
starts flash operation.
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.
@ -52,8 +51,7 @@
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. Task on CPU B returns
to suspended state by "taking" the semaphore.
CPU A as well and returns control to the calling code.
Additionally, all API functions are protected with a mutex (s_flash_op_mutex).