Having two different spinlocks is problematic due to possibly
different order in which the locks will be taken. Changing the order
would require significant restructuring of kernel code which is
undesirable.
An additional place where taking xTickCountMutex was needed was in
vApplicationSleep function. Not taking xTickCountMutex resulted in
other CPU sometimes possibly advancing tick count while light sleep
entry/exit was happening. Taking xTickCountMutex in addition to
xTaskQueueMutex has shown a problem that in different code paths,
these two spinlocks could be taken in different order, leading to
(unlikely, but possible) deadlocks.
If CONFIG_FREERTOS_LEGACY_HOOKS is kept enabled then defining
idle/tick hooks will be applications responsibility as was the
case earlier.
Signed-off-by: Mahavir Jain <mahavir@espressif.com>
Bugfix to prevent a self deleting no affinity task's memory from being freed by the
idle task of the other core before the self deleting no affinity task is able to context
switch out. prvCheckTasksWaitingTermination now checks if the task is still on
pxCurrentTCB before freeing task memory.
This commit backports vTaskDelete() behavior from FreeRTOS v9.0.0 which
allows for the immediate freeing of task memory if the task being deleted
is not currently running and not pinned to the other core. This commit also
fixes a bug in prvCheckTasksWaitingTermination which prevented the
Idle Task from cleaning up all tasks awaiting deletion. Each iteration of the Idle
Task should traverse the xTasksWaitingTermination list and clean up all tasks
not pinned to the other core. The previous implementation would cause
prvCheckTasksWaitingTermination to return when encountering a task
pinned to the other core whilst traversing the xTasksWaitingTermination list.
The test case for vTaskDelete() has been updated to test for the bugfix and
backported deletion behavior.
This commit makes the configQUEUE_REGISTRY_SIZE and
configGENERATE_RUN_TIME_STATS configurable in menuconfig.
- configQUEUE_REGISTRY_SIZE can now be set in menuconfig.
- The functions vQueueAddToRegistry() and vQueueUnregisterQueue() were made
SMP compatbile
- pcQueueGetName() was backported from FreeRTOS v9.0.0
- Added test case for Queue Registry functions
- configGENERATE_RUN_TIME_STATS can now be enabled in menuconfig. CCOUNT or
esp_timer can be selected as the FreeRTOS run time clock in menuconfig as
well, although CCOUNT will overflow quickly.
- Run time stats collection (in vTaskSwitchContext) and generation (in
uxTaskGetSystemState) have been made SMP compatible. Therefore
vTaskGetRunTimeStats() now displays the run time usage of each task as a
percentage of total runtime of both CPUs
Squash
Test cases were added for the following functions
- xTaskNotify(), xTaskNotifyGive(), xTaskNotifyFromISR(), vTaskNotifyGiveFromISR(),
- xTaskNotifyWait(), ulTaskNotifyTake()
- vTaskDelayUntil()
The following function was made smp compatible and tested as well
- eTaskGetState()
This commit reverts the revert on the new task watchdog API. It also
fixes the following bug which caused the reversion.
- sdkconfig TASK_WDT_TIMEOUT_S has been reverted from the unit of ms back to the
unit of seconds. Fixes bug where projects using the new API without rebuilding sdkconfig
would cause the old default value of 5 to be interpreted in ms.
This commit also adds the following features to the task watchdog
- Updated idle hook registration to be compatible with dual core hooks
- Updated dual core hooks to support deregistration for cpu
- Legacy mode has been removed and esp_task_wdt_feed() is now replaced by
esp_task_wdt_reset(). esp_task_wdt_feed() is deprecated
- Idle hooks to reset are now registered/deregistered when the idle tasks are
added/deleted from the Task Watchdog instead of at Task Watchdog init/deinit
- Updated example
This commit makes configUSE_TRACE_FACILITY and
configUSE_STATS_FORMATTING_FUNCTIONS configurable in kconfig. Test cases fro the
functions enabled by the two configurations above have also been added.
Test cases for the following functions have been added...
- uxTaskGetSystemState()
- uxTaskGetTaskNumber()
- vTaskSetTaskNumber()
- xEventGroupClearBitsFromISR()
- xEventGroupSetBitsFromISR()
- uxEventGroupGetNumber()
- uxQueueGetQueueNumber()
- vQueueSetQueueNumber()
- ucQueueGetQueueType()
Test cases for the following functions were not required...
- prvListTaskWithinSingleList()
- prvWriteNameToBuffer()
- vTaskList()
Previously if multiple tasks had been added to xPendingReadyList for the CPU, only the first one was resumed.
Includes a test case for resuming multiple (pending) tasks on xTaskResumeAll().
Document the limitation that while scheduler is suspended on one CPU, it can't wake tasks on either CPU.
Legacy API of task watchdog used the same function esp_task_wdt_feed() to add
and feed a task. This caused issues of implicitly adding a task to the wdt list
if the function was used in shared code.
The new API introduces init, adding, feeding, deleting, deinit functions. Tasks
must now be explicitly added to the task watchdog using their handles. Deletion
must also be explicit using task handles. This resolves the issue of implicit
task additions to the task watchdog due to shared code calling
esp_task_wdt_feed().
Task watchdog is now fully configurable at runtime by calling the init and
deinit functions.
Also added functions to get the handles of idle tasks of the other core. This
helps when adding idle tasks to the watchdog at run time.
Configuring the task watchdog using menu config is still available, however
menu config will only result in calling the init and add functions for idle
tasks shortly after the scheduler starts.
Menu config also allows for using legacy behavior, however the legacy behavior
willcall the new API functions but with slight variations to make them legacy
compatible.
Documentation and example have also been updated
gcov_rtio.c headers updated to prevent error of freertos header files being
included in the wrong order.
Resolves issue TW#13265
Implements support for system level traces compatible with SEGGER
SystemView tool on top of ESP32 application tracing module.
That kind of traces can help to analyse program's behaviour.
SystemView can show timeline of tasks/ISRs execution, context switches,
statistics related to the CPUs' load distribution etc.
Also this commit adds useful feature to ESP32 application tracing module:
- Trace data buffering is implemented to handle temporary peaks of events load
Updated test case to include configASSERT cases (+1 squashed commits)
Squashed commits:
[871ec26f] Freertos:Bugfix uxTaskGetSystemState
Bug (github #12142) with uxTaskGetSystemState where
if called immediately after creating a bunch of tasks,
those tasks would be added twice into the TaskStatusArray.
Bug caused due to use old implementation using vTaskSuspendAll
which did not stop newly created task on other core from accessing the
read/waiting task lists whilst the list were being read by
uxTaskGetSystemState. Fixed bug by replacing vTaskSuspendAll
with taskENTER_CRITICAL and added test case for the bugfix
xPendingReadyList[1] was never initialised correctly, so if a task is added to this list (ie by xSemaphoreGiveFromISR()
or similar) while scheduler is disabled, then it causes a null pointer dereference.
Bug produces stack traces similar to:
0x40086e87: vListInsertEnd at /home/gus/esp/32/idf/components/freertos/./list.c:130
0x40084ba3: xTaskRemoveFromEventList at /home/gus/esp/32/idf/components/freertos/./tasks.c:3439
0x40083c54: xQueueGiveFromISR at /home/gus/esp/32/idf/components/freertos/./queue.c:2034
0x400f50a0: timer_group0_isr at /home/gus/esp/32/idf/components/freertos/test/./test_suspend_scheduler.c:27
0x40081d7d: _xt_lowint1 at xtensa_vectors.o:?
Make internal stack size variables in FreeRTOS 32-bit instead of 16-bit
Stock FreeRTOS uses an uint16 to store stack sizes, making it impossible to allocate a stack >64K. This changes this into an uint32, allowing for larger stacks.
See merge request !677
Assert when a new task is started on a nonexisting CPU
Previously, starting a task on a CPU ID higher than the amount of CPUs FreeRTOS is configured with would not start the task and possibly have unintended side effects due to some out-of-bounds array writes. Assert on this so the app aborts cleanly.
See merge request !701
