* Update task notification scheduler suspension
Previously ulTaskGenericNotifyTake() and xTaskGenericNotifyWait() would suspend
the scheduler while inside a critical section.
This commit changes the order by wrapping the critical sections in a scheduler
suspension block. This logic is more inuitive and allows the SMP scheduler
suspension logic to be simplified.
* tasks.c: Fix typo
* Use a complete sentence in comment
* Check portGET_CRITICAL_NESTING_COUNT when scheduler is running
* Prevent potential NULL pointer access when scheduler is not running
---------
Co-authored-by: Paul Bartell <pbartell@amazon.com>
Co-authored-by: chinglee-iot <61685396+chinglee-iot@users.noreply.github.com>
Co-authored-by: Ching-Hsin Lee <chinglee@amazon.com>
* Request a task to yield after been suspended or deleted to prevent this task puts itself back to another list
* Fix volatile variable access order to ensure ensure compliance with MISRA C 2012 Rule 13.5
---------
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
* Rename Arm_AARCH64 to ARM_AARCH64
* Rename Arm_AARCH64_SRE to ARM_AARCH64_SRE
* Update cmake for ARM port folder capitalization
* Update in portable/CmakeLists.txt
* Use capitalization name in port README.md
---------
Co-authored-by: Ching-Hsin Lee <chinglee@amazon.com>
Enable xTaskGetCurrentTaskHandleForCore() for single core builds
---------
Co-authored-by: Paul Bartell <pbartell@amazon.com>
Co-authored-by: Ching-Hsin Lee <chinglee@amazon.com>
* Initial set of SA fixes
* Revert function parameter name changes
* Reverted parameter name for Static version of function by mistake
* Update mpu_wrappers_v2.c to only include 20.7 fixes
* Update queue.c to remove non-20.7 fixes
* Update tasks.c to remove non-20.7 fixes
---------
Co-authored-by: bjbsmith <bjbsmith@uafeb6a6bcdce55.ant.amazon.com>
Co-authored-by: chinglee-iot <61685396+chinglee-iot@users.noreply.github.com>
* Update vTaskDelete() to delete a task directly when scheduler is stopped instead of putting it on the xTasksWaitingTermination list.
* Delete the idle tasks and timer task in vTaskEndScheduler().
* Reclaim resources for all the tasks on the xTasksWaitingTermination list in vTaskEndScheduler().
* Update POSIX to no longer delete FreeRTOS tasks in the port.
---------
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
Modify portable/CMakeLists.txt to create only one static library containing both the common kernel code and kernel port.
Change the freertos_kernel_port target from a STATIC library to an OBJECT library and introduce a new freertos_kernel_port_headers INTERFACE library target.
---------
Co-authored-by: ABARNAT <ahmed.barnat@actia-engineering.tn>
Co-authored-by: Soren Ptak <ptaksoren@gmail.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Unnecessary white space was introduced in PR #768
which affected the formatting of assembly code. This PR
returns the correct formatting. No functional change.
Add a check for configENABLE_MVE to M23, M33 ports
configENABLE_MVE is only applicable to Cortex-M55 and Cortex-M85 ports.
It must not be defined to 1 for other ARMv8_m ports.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The number of MPU regions is not configurable for Cortex-M3 port and
therefore, it is misleading to have configTOTAL_MPU_REGIONS in
portmacro.h.
It was added in PR #952.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Add code to allow building for x64 in MSVC
- Add code for x64 arch.
- Add initial value for local otherwise it won't get proper value in x64.
* Moving init local to portGET_HIGHEST_PRIORITY
- From code review.
* More changes following review
* Another style fix from review
* Update formatting
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
---------
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Co-authored-by: Nikhil Kamath <110539926+amazonKamath@users.noreply.github.com>
Co-authored-by: Soren Ptak <ptaksoren@gmail.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
According to the MSP430 EABI [1] section 3.3,
Arguments are assigned, in declared order, to the first available
register single, pair, or quad from the following list into which it
fits (with the following special exceptions). For MSP430 and
MSP430X, the argument registers are: R12, R13, R14, R15
Therefore, pvParameters should be passed in R12, as it is the first
argument, not R15. Keep passing the parameter in R15 for the
MSP430 EABI, if anyone is still using it.
[1] https://www.ti.com/lit/an/slaa534a/slaa534a.pdf
PR #914 caused Posix Port to fail to build on MacOS. This PR fixes
teh build failure.
This PR also adds a Matrix configuration to the GitHub kernel-demo
workflow to build the Posix Demos on MacOS.
---------
Co-authored-by: chinglee-iot <61685396+chinglee-iot@users.noreply.github.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
* MicroblazeV9: Add support for 64 bit microblaze
* MicroblazeV9: Add support for generation of run time task stats
* MicroblazeV9: Add default implementation for callback functions
---------
Signed-off-by: Mubin Usman Sayyed <mubin.usman.sayyed@xilinx.com>
* Allow access to any buffer in xPortIsAuthorizedToAccessBuffer if xSchedulerRunning is set to pdFALSE
* Allow access to any buffer in xPortIsAuthorizedToAccessBuffer if xSchedulerRunning is set to pdFALSE in the copied ARMv8M Port Files
* Add runtime check to see if the target even has a MPU
* Add missing extern symbols for __ARMCC_VERSION support
* Add default for configTOTAL_MPU_REGIONS and change a runtime assert to compile time error
* Simplify check and link to reference documentation
Co-authored-by: Soren Ptak <ptaksoren@gmail.com>
---------
Co-authored-by: Soren Ptak <ptaksoren@gmail.com>
Co-authored-by: jasonpcarroll <23126711+jasonpcarroll@users.noreply.github.com>
* Error when configSUPPORT_STATIC_ALLOCATION is set for MPU ports
* Uncrustify: triggered by comment.
---------
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Soren Ptak <ptaksoren@gmail.com>
Change from pthread_attr_setstack() to pthread_attr_setstacksize(), and automatically adjust the stack size
to be at least PTHREAD_STACK_MIN if it wasn't already, removing the size warning.
This permits the user to increase the pthread stack size beyond the PTHREAD_STACK_MIN default of 16384 if
desired, without producing a warning in the typical case where stacks are minimized for RAM limited targets.
Continue to store thread paramters on the provided stack, for consistency with the MCU targets.
Previously pthread_attr_setstack() was used to enable user defined stacks.
Note that:
1. The stack size can still be specified by the user.
2. pxPortInitialiseStack(), and pthread_addr_setstack() was failing on stacks of typical size, as
these are smaller than PTHREAD_STACK_MIN (16384) bytes, and printing out a series of warnings.
Improve usability by having the posix port automatically increase the stack size to be
at least PTHREAD_STACK_MIN as posix platforms have enough memory for this not to be a concern.
3. Reuse of stack memory will also result in valgrind 'invalid write' errors to what is demonstrably
valid memory. Root cause is that Valgrind is tracking a stack pointer as the stack is used.
Reuse of a stack buffer results in the stack being used at its start, in an area that Valgrind thinks
is far away from the start of the stack. There are ways to notify Valgrind of these changes
however this would require linking against and calling Valgrind functions from the FreeRTOS application using
the posix port, https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq.
Also, apparently it isn't permitted by posix to reuse stack memory once its been used in a pthread via pthread_attr_setstack(),
see https://stackoverflow.com/a/5422134
For a clean shutdown where memory is freed, it is necessary for all pthreads to be joined
at shutdown.
Previously there was explicit cancellation of the idle task and timer daemon task, however
there may be a number of other tasks in the system, both system created and user created,
and those tasks/threads were being left at shutdown.
This change calls pthread_cancel()/pthread_join() on all FreeRTOS managed pthreads upon
shutdown.
Improve upon the elegant approach of using signals to cause task/pthreads
suspension and scheduler execution by using directed signals.
This fixes:
- Deadlocks in non-FreeRTOS pthreads
- Multiple FreeRTOS tasks(pthreads) incorrectly running at the same time
By directing the signals using pthread_kill() the signal handler in the presently running
FreeRTOS task/pthread will be called, ensuring that the scheduler runs both in the context
of a FreeRTOS task/pthread and from the presently executing FreeRTOS task/pthread.
Details
==============
The POSIX port uses signals to preempt FreeRTOS tasks (implemented as pthreads), a very neat and elegant
approach to forcing tasks/pthreads to suspend and run the scheduler.
Signal handlers are process global.
Posix timers generate signals when the timer expires, and the signal is sent to the currently
running pthread.
In systems where there are pthreads that are NOT a result of creating FreeRTOS tasks, such as the
entry point thread that calls main(), or user created pthreads, this poses a serious issue.
While the POSIX port only allows a single FreeRTOS pthread to run at once, by causing all suspended
threads to not be scheduled due to their waiting on a pthread condition variable,
this isn't the case with non-FreeRTOS pthreads.
Thus it is possible that a non-FreeRTOS pthread is running when the timer expires and the signal
is generated. This results in the signal handler running in the non-FreeRTOS thread.
The sequence of events results in these events from signal handler context:
- vPortSystemTickHandler() being called
- The scheduler running
- Selecting another FreeRTOS task to run and switching the active task
- The newly selected task released from suspension by pthread_cond_signal()
- The presently active thread calling event_wait()
- The pthread calling pthread_cond_wait(), suspending the thread and allowing the host OS scheduler
to schedule another thread to run.
If this occurs from a non-FreeRTOS thread this results in:
- The active FreeRTOS pthread (Task A/Thread A) continuing to run (as the signal handler that calls
event_wait() ran instead in a non-FreeRTOS pthread.
- The pthread where the signal handler did run (Thread B) will call event_wait() and pthread_cond_wait(),
but on the condition variable of the previously active FreeRTOS task, oops. This causes the
non-FreeRTOS pthread to block unexpectedly relative to what the developer might have expected.
- The newly selected FreeRTOS Task (Task C/Thread C) will resume and start running.
At this point Task A/Thread A is running concurrently with Task C/Thread C. While this may not
necessarily be an issue, it does not replicate the expected behavior of a single Task running at
once.
Note that Thread B will resume if/when Task A/ThreadA is switched to. However, this could be delayed
by an arbitrary amount of time, or could never occur.
Also note that if there are multiple non-FreeRTOS pthreads that Thread D, E, F...etc could suffer the
same fate as Thread B, if the scheduler were to suspend Task C/Thread C and resume Task E/Thread E.
Implementation
==============
Timer details
-------------
A standalone pthread for the signal generation thread was chosen, rather than using
a posix timer_settime() handler function because the latter creates a temporary
pthread for each handler callback. This makes debugging much more difficult due to
gdb detecting the creation and destruction of these temporary threads.
Signal delivery
--------------
While signal handlers are per-thread, it is possible for pthreads to selectively block
signals, rather than using thread directed signals. However, the approach of blocking
signals in non-FreeRTOS pthreads adds complexity to each of these non-FreeRTOS pthreads
including ensuring that these signals are blocked at thread creation, prior to the thread
starting up. Directed signals removes the requirement for non-FreeRTOS pthreads to be aware
of and take action to protect against these signals, reducing complexity.
Christoph Seitz
bradleysmith23
Rahul Kar
Darian
chinglee-iot
Paul Bartell
Eric Jackson
barnatahmed
Phillip Stevens
Gaurav-Aggarwal-AWS
Soren Ptak
José Simões
Forty-Bot
Mubin Sayyed
Mikhail Paulyshka
IsaacDynamo
Tony Josi
Chris Morgan
Ching-Hsin Lee