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.
It seems gcc is not producing debug information for sections which
are not properly marked as "ax", resulting in missing debug info
for _vector_table, _interrupt_handler and _panic_handler. This can be
verified e.g. with
readelf --debug=info ./build/esp-idf/riscv/CMakeFiles/__idf_riscv.dir/vectors.S.obj
readelf -SW ./build/esp-idf/riscv/CMakeFiles/__idf_riscv.dir/vectors.S.obj
for hello_world example on esp32c3 target. Mark the .exception_vectors.text and
.exception_vectors_table.text sections as writable and allocatable so the debug
info sections are generated.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
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
Changed rv_utils_intr_edge_ack and esp_cpu_intr_edge_ack to
take uint32_t instead of int to avoid build errors.
The test is to test in particular that __builtin_ffsll, used in
xt_utils.h, which is included via esp_cpu.h, compiles fine
in C++20 with -Wsign-conversion enabled.
Closes https://github.com/espressif/esp-idf/pull/10895
Alexey Lapshin