IDF FreeRTOS uses vTaskSuspendAll()/xTaskResumeAll() to stop preemption
on a particular core. However, those functions behave differently in FreeRTOS SMP.
This commit replaces all calls of vTaskSuspendAll()/xTaskResumeAll() with
vTaskPreemptionDisable()/vTaskPreemptionEnable() when compiling with SMP FreeRTOS.
The following files were deleted:
- components/esp_hw_support/include/soc/cpu.h
- components/soc/esp32s3/include/soc/cpu.h
The following functions are deprecated:
- get_sp()
The following functions declared in soc/cpu.h are now moved to esp_cpu.h:
- esp_cpu_configure_region_protection()
The following functions declared in soc/cpu.h are now moved to components/xtensa/include/esp_cpu_utils.h:
- esp_cpu_process_stack_pc()
All files with soc/cpu.h inclusion are updated to include esp_cpu.h instead.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
spi_flash has been updated and its functions work from flash by default instead of IRAM that cause issue
add Kconfig value into espcoredump to enable spi_flash legacy mode (CONFIG_SPI_FLASH_USE_LEGACY_IMPL) when core dump is selected
fix spi_flash issues to work correctly with legacy mode when CONFIG_SPI_FLASH_USE_LEGACY_IMPL is used
1. separate rom include files and linkscript to esp_rom
2. modefiy "include rom/xxx.h" to "include esp32/rom/xxx.h"
3. Forward compatible
4. update mqtt
The fix is for the situation when cache disabling mechanism causes
a deadlock with user tasks. Situation is as follows:
1. spi_flash operation is started from low-priority task on CPU0
2. It uses IPC to wake up high-priority IPC1 task on CPU1, preventing
all other tasks on CPU1 from running. This is needed to safely
disable the cache.
3. While the task which started spi_flash operation is waiting for IPC1
task to acknowledge that CPU1 is not using cache anymore, it is
preempted by a higher priority application task ("app0").
4. Task app0 busy-waits for some operation on CPU1 to complete. But
since application tasks are blocked out by IPC1 task, this never
happens. Since app0 is busy-waiting, the task doing spi flash
operation never runs.
The more or less logical soltion to the problem would be to also do
cache disabling on CPU0 and the SPI flash operation itself from IPC0
task. However IPC0 task stack would need to be increased to allow doing
SPI flash operation (and IPC1 stack as well). This would waste some
memory. An alternative approach adopted in this fix is to call FreeRTOS
functions to temporary increase the priority of SPI flash operation task
to the same level as the IPC task.
Fixes https://github.com/espressif/arduino-esp32/issues/740
Fixes https://github.com/espressif/esp-idf/issues/1157
1. When dual core cpu run access DPORT register, must do protection.
2. If access DPORT register, must use DPORT_REG_READ/DPORT_REG_WRITE and DPORT_XXX register operation macro.
Flash operation complete flag was cleared by the core initiating flash
operation. If the other core was running an ISR, then IPC task could
be late to enter the loop to check s_flash_op_complete by the time next
flash operation started. If the flag is cleared on the CPU waiting on
this flag, then the race condition can not happen.
MR !441 (7c155ab) has fixed issue with esp_intr_noniram_{disable,enable}
calls not being properly protected by spi_flash_op_{lock,unlock}.
Unit test was added, but the unit test environment tests only dual-core
config. Similar issue was present in the code path for the single-core
config, where esp_intr_noniram_{disable,enable} calls were unprotected.
This change fixes the protection issue and updates the unit test to
run properly in single core config as well.
The issue with running unit tests for single core config will be
addressed in a separate MR.
