FreeRTOS tasks may now freely use the PIE coprocessor and HWLP feature.
Just like the FPU, usiing these coprocessors result in the task being pinned
to the core it is currently running on.
When adjusting the interrupt level treshold on P4/C6 during a critical section exit
it would take a few cycles before this is taken into account by the CPU.
This meant that under some circumstances, e.g. 02, we could do
yield()->vPortExitCritical()->vPortEnterCritical()
without getting rescheduled.
This causes issues for freertos as it assumes the task will not continue into the
vPortEnterCritical before the scheduler has schedulded it again.
This meant that e.g. xTaskNotifyWait would yield, but then immeditaly continue as if
it was already notified.
This commit added the RISC-V utility functions to set the interrupt
threshold for CLIC targets by using direct register value writes.
This makes the functions more efficient during run-time.
This is done to improve the critical section enter and exit performance on esp32p4.
Some files that should have their copyrights checked are still placed on the
copyright ignore list.
- These entries have been tidied up
- Copyrights of those files have been updated.
fix(panic): fixed cache error being reported as illegal instruction
Closes IDF-6398, IDF-5657, IDF-7015, and IDF-6733
See merge request espressif/esp-idf!27430
On riscv chips accessing cache mapped memory regions over the ibus would
result in an illegal instructions exception triggering faster than the cache
error interrupt/exception.
Added a cache error check in the panic handler, if any cache errors are active
the panic handler will now report a cache error, even if the trigger exception
was a illegal instructions.
This commit mainly targets the ESP32-P4. It adds supports for coprocessors on
RISC-V based targets. The coprocessor save area, describing the used coprocessors
is stored at the end of the stack of each task (highest address) whereas each
coprocessor save area is allocated at the beginning of the task (lowest address).
The context of each coprocessor is saved lazily, by the task that want to use it.
This commit fixes an issue where xPortCanYield() function may not be
able to detect an ISR context when HW interrupt nesting is active on
a CLIC interrupt controller such as on esp32p4.
- add hardware stack guard based on assist-debug module
- enable hardware stack guard by default
- disable hardware stack guard for freertos ci.release test
- refactor rtos_int_enter/rtos_int_exit to change SP register inside them
- fix panic_reason.h header for RISC-V
- update docs to include information about the new feature