systimer was stopped because the option SYSTIMER_TIMER_UNIT1_CORE1_STALL_EN is set by default 1, it blocks counting.
For Unicore should be:
SYSTIMER_TIMER_UNIT1_CORE0_STALL_EN 1
SYSTIMER_TIMER_UNIT1_CORE1_STALL_EN 0
* ##__VA_ARGS__ is replaced by __VA_OPT__(,)
and __VA_ARGS if C++20 is used.
* Affected header files are: esp_log.h,
portmacro.h and esp_check.h
* Closes https://github.com/espressif/esp-idf/pull/6692
portGET_ARGUMENT_COUNT uses a GCC extension ##__VA_ARGS__. It forces
the user to compile the code with GNU extensions enabled instead of ISO
language standard. The suggested change is to replace ##__VA_ARGS__ with
__VA_OPT__(,) __VA_ARGS__ which is supported by the current version of
GCC used in ESP-IDF for both C and C++ ISO standards.
This fix would enable ESP-IDF users to compile their code with ISO C++20
standard in future releases.
Signed-off-by: Jakob Hasse <jakob.hasse@espressif.com>
1. Add conditions based on Kconfig options for functions which are
compiled based on those options.
2. Static allocation is always enabled, move corresponding functions
into the common list.
Since dd849ffc, _rodata_start label has been moved to a different
linker output section from where the TLS templates (.tdata, .tbss)
are located. Since link-time addresses of thread-local variables are
calculated relative to the section start address, this resulted in
incorrect calculation of THREADPTR/$tp registers.
Fix by introducing new linker label, _flash_rodata_start, which points
to the .flash.rodata output section where TLS variables are located,
and use it when calculating THREADPTR/$tp.
Also remove the hardcoded rodata section alignment for Xtensa targets.
Alignment of rodata can be affected by the user application, which is
the issue dd849ffc was fixing. To accommodate any possible alignment,
save it in a linker label (_flash_rodata_align) and then use when
calculating THREADPTR. Note that this is not required on RISC-V, since
this target doesn't use TPOFF.
Noted as a problem with thread local storage returning a different task's
pointers, but some other were APIs also accessing current task unsafely.
Regression in FreeRTOS 10 update a3c90bf59a
Causes test added in parent commit to pass.
This race happens if the deleted task is running on the other CPU,
and is already spinning in a critical section waiting for xTaskQueueMutex
because it's about to be blocked for a resource.
The "deleted" task would end up blocked, possibly indefinitely, and
never actually deleted or its resources cleaned up by the idle tasks.
Details:
vTaskDelete() adds the target task to the xTasksWaitingTermination list,
expecting it to be yielded off CPU and then cleaned up later. However as soon as
vTaskDelete() releases xTaskQueueMutex, the target task runs and moves itself to the
xDelayedTaskList1. Because interrupts are already disabled on that CPU,
the "yield" to the other CPU sent by the vTaskDelete() comes afterward so
doesn't help.
