On RISC-V chips with SPIRAM support (esp32c5, esp32c61, esp32h4, esp32p4,
esp32s31), esp_restart_noos() was disabling the cache while the current
stack pointer could still be in external RAM. Any stack access after cache
disable (function call, local variable spill) would then fault with
"Cache disabled but cached memory region accessed".
Xtensa chips (esp32, esp32s2, esp32s3) already had this guard via the
SET_STACK macro. Add the equivalent for RISC-V:
- Add rv_utils_set_sp() to riscv/rv_utils.h (plain "mv sp, %0" with a
memory clobber; no window register management needed on RISC-V)
- In each affected system_internal.c, under
CONFIG_FREERTOS_TASK_CREATE_ALLOW_EXT_MEM, check whether the current
SP is in PSRAM and if so switch it to the top of internal BSS before
any cache disable or writeback operation
- Fix xTaskCreateStaticPinnedToCore() stack size argument in the
spiram_stack test (was passing bytes instead of word count)
- Mark the null-pointer write in func_do_exception() as volatile to
prevent the compiler from optimizing it away
- Extend the [spiram_stack] tests to RISC-V by sharing fibonacci() and
the task/finish helpers across architectures, guarding only the
Xtensa-specific WINDOWBASE/WINDOWSTART prints
This change improves build consistency across external projects integrated
through CMake by ensuring that compiler flags defined in configuration files
are passed correctly to the toolchain. It covers the majority of use cases,
as external projects are typically also CMake-based. For projects that use
a custom build system, users will still need to specify the required flags
manually.
Also:
- Split the secure service table into two parts: one DRAM-resident and the
other DROM-resident. The former holds the services invoked when the cache is
disabled or suspended while the latter holds rest of the services.
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.
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.
Marius Vikhammer
Guillaume Souchere
harshal.patil
Omar Chebib
Alexey Lapshin
Mahavir Jain
Laukik Hase
armando
laokaiyao
Chen Jichang
Jiang Jiang Jian
wuzhenghui
Alexey Gerenkov
Liu Xiao Yu
Konstantin Kondrashov
Jiang Jiang Jian
Frantisek Hrbata
Wan Lei
Sudeep Mohanty