This commit synchronizes the following xTaskRemoveFrom...EventList() with
upstream v10.4.3. Multi-core modifications are then reapplied to the
functions.
The functions updated are:
- xTaskRemoveFromEventList()
- vTaskRemoveFromUnorderedEventList()
The following multi-core macros have been removed as they are no longer
required.
- tskCAN_RUN_HERE()
- taskYIELD_OTHER_CORE()
This commit synchronizes the following vTaskPlaceOnEventList...() with
upstream v10.4.3.
The functions updated are:
- vTaskPlaceOnEventList()
- vTaskPlaceOnUnorderedEventList()
- vTaskPlaceOnEventListRestricted()
The traceTASK_DELAY_UNTIL() macro has also been updated.
This commit reverts the previous "taskENTER_CRTIICAL();" so that the argument
is now provided for better code readability. The names of the spinlocks have
also been updated.
This commit updates various FreeRTOS functions to call the newly added
prvCheckForYield() and prvCheckForYieldUsingPriority() when checking for
yielding. This allows the source code to match upstream more closely.
When a FreeRTOS function unblocks a task, that function will check whether
the unblocked task requires a yield to be called. This is currently done by
having each function individually check if the unblocked task has a higher
priority than the both cores, and yielding the appropriate core.
This commit adds the macros list below to abstract away the yielding checking
procedure. This will allow the code to match upstream more closely.
- prvCheckForYield()
- prvCheckForYieldUsingPriority()
The event group unit tests would previously use a single call bit (the
"BIT_CALL" macro) to unblock all the test tasks. However, if one or more tasks
were delayed in calling xEventGroupWaitBits(), the other tasks would clear the
test bits, leading to the test deadlocking.
This commit updates the bits used so that each task gets their own CALL and
RESPONSE bits.
For RISC-V and Xtensa targets, in case a panic needs to happen when
Task WDT is triggered (ESP_TASK_WDT_PANIC), the interruptee's stack
is now used for printing the backtrace.
Abort after Task Watchdog is triggered can happen on APP CPU (second core).
Closes https://github.com/espressif/esp-idf/issues/7207
The description of how the xTaskGenericNotifyWait parameter is handled in the
xTaskGenericNotifyWait() function was inaccurate.
In this commit, the description was updated to match the implementation of xTaskGenericNotifyWait().
This commit marks all functions in interrupt_controller_hal.h, cpu_ll.h and cpu_hal.h as deprecated.
Users should use functions from esp_cpu.h instead.
This function removes the following legacy atomic CAS functions:
From compare_set.h (file removed):
- compare_and_set_native()
- compare_and_set_extram()
From portmacro.h
- uxPortCompareSet()
- uxPortCompareSetExtram()
Users should call esp_cpu_compare_and_set() instead as this function hides the details
of atomic CAS on internal and external RAM addresses.
Due to the removal of compare_set.h, some missing header includes are also fixed in this commit.
This commit fixes vTaskSuspendAll() and xTaskResumeAll() in the following ways.
- For vTaskSuspendAll()
- Sync function source code with upstream single core version
- Clearly mark IDF additions
- For xTaskResumeAll()
- Sync function source code with upstream single core version
- Clearly mark IDF additions
- Fix bug where cores other than core 0 were allowed to unwind pended ticks
This commit fixes the following issues:
- Clearly mark IDF additions in vTaskStepTick() and xTaskCatchUpTicks()
- Add back vTaskSuspendAll()/xTaskResumeAll() to xTaskCatchUpTicks(). Scheduler
suspension and resumption is required to unwind the pended ticks.
Previously, xTaskIncrementTick() would always trigger a yield (i.e., return pdTRUE)
when called on core 1. This would mean core 1 would call vTaskSwitchContext() on
every tick, leading to uneccesary CPU overhead.
This commit fixes xTaskIncrementTick() in the following ways:
- Clearly mark IDF additions in xTaskIncrementTick()
- Moved esp_vApplicationTickHook() to be called direclty in xPortSysTickHandler() in order to
simplify xTaskIncrementTick().
- Only core 0 calls xTaskIncrementTick() in order to simplify the function's logic. Core 0 is
solely responsible for managing xTickCount and xPendedTicks
- All other cores call xTaskIncrementTickOtherCores() instead which is a simplified version of
xTaskIncrementTick() and handles the following:
- Check if core 0 has unblocked a higher priority task to run
- Check if the current core requires time slicing
- Call vApplicationTickHook()
This commit fixes the following:
- Fixes a bug wherein the timer status is active for oneshot timers that
expire before they are started.
- Callback calls for periodic timers where made before the timers were
auto-reloaded.
- Timer expiry trace was being set after the timer callback is called.
Closes https://github.com/espressif/esp-idf/issues/8014
Idle tick hook that indicates completion of scheduler init must be launched
on other core than the one where main task runs. Earlier it was assumed that
main task shall always run on PRO cpu but that behavior can be changed with
ESP_MAIN_TASK_AFFINITY_CPU1 and hence this fix.
Closes https://github.com/espressif/esp-idf/issues/9247
Closes IDFGH-7705
FreeRTOS uses a single "xSchedulerRunning" variable to tack whether the
scheduler has started, and this variable is set to "pdTRUE" by core 0
via calling vTaskStartScheduler().
However, with SMP FreeRTOS, there is a race condition where core 0 has
already started the scheduler and another core has not called xPortStartScheduler()
yet and calls some FreeRTOS API. Thus the resultant FreeRTOS API can
cause errors as it thinks the scheduler has started.
This commit adds a temporary workaround (by having each core maintain their
own "xSchedulerRunning" variable.
The "FreeRTOS Event Groups" main task will only wait a single tick for the created
tasks to set their response bits. This short delay may not be sufficent if the tick
frequency is high.
This commit updates the test so that
- the main task waits indefinitely for all the response bits to be set.
- created tasks are cleand up by the main task
FreeRTOS synchronization primitives (e.g., queues, eventgroups) use various event lists (i.e., task lists) to track what
tasks are blocked on a current primitive. Usually these event lists are accessed via one of the event lists functions
(such as vTask[PlaceOn|RemoveFrom]UnorderedEventList()), which in turn ensure that the global task list spinlock
(xTaskQueueMutex) is taken when accessing these lists.
However, some functions in event_groups.c manually traverse their event lists. Thus if a tick interrupt occurs on
another core during traversal and that tick interrupt unblocks a task on the event list being traversed, the event list
will be corrupted.
This commit modifies the following event_groups.c functions so that they take the global task list lock before
traversing their event list.
- xEventGroupSetBits()
- vEventGroupDelete()
The CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH allows some FreeRTOS functions to be placed
into flash, thus saving some IRAM. However, this feature was previously not supported for
SMP FreeRTOS.
This commit adds CONFIG_FREERTOS_PLACE_FUNCTIONS_INTO_FLASH support for SMP FreeRTOS. There
are now separate linker fragment files for IDF FreeRTOS and SMP FreeRTOS, named "linker.lf"
and "linker_smp.lf" respectively.
The TLSP deletion callback feature is not compatible with the CONFIG_FREERTOS_ENABLE_STATIC_TASK_CLEAN_UP
option. However, the "freertos_options" unit test configuration will enable that option.
This commit disables all CONFIG_FREERTOS_ENABLE_STATIC_TASK_CLEAN_UP related features when compiling with
SMP FreeRTOS.
prvYieldCore() leads to an array-out-of-bounds error when compiled with
-Os optimization and configNUM_CORES = 1. This commit avoids this
compile warning by compiling out the part of code which is unnecessary
when configNUM_CORES is 1.
The Xtensa FreeRTOS port does not save the threadptr register when
doing a voluntary yield. This can result in a crash when multiple
tasks used the threadptr register and call "taskYIELD()".
This commit adds the threadptr register to the solicited stack frame.
Marius Vikhammer