Gaurav-Aggarwal-AWS [Tue, 14 May 2024 10:45:54 +0000 (16:15 +0530)]
Fix race in prvProcessSimulatedInterrupts (#1055)
Earlier the code was suspending the current thread after calling
vTaskSwitchContext. This left a gap where the current thread could
access incorrect pxCurrentTCB after it was changed by
vTaskSwitchContext.
This commit addresses the problem by suspending the current thread
before calling vTaskSwitchContext.
It was reported here - https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/1054.
StefanBalt [Wed, 8 May 2024 11:37:52 +0000 (13:37 +0200)]
Add configUSE_TASK_FPU_SUPPORT to AARCH64 port (#1048)
* Add configUSE_TASK_FPU_SUPPORT to AARCH64 port
NEON SIMD is required by standard AARCH64 and its registers are
frequently utilized by standard functions such as memcpy().
This means that even simple tasks that do not use any floating point
arithmetics may still alter the contents of the FPU registers.
For this reason it makes sense to add support for
configUSE_TASK_FPU_SUPPORT to be able to enforce FPU register saving and
restoring globally.
The implementation was largely adopted from the ARM_CA9 port. However,
the FPU registers must be placed on the stack before the critical
nesting count to match the AARCH64 portASM.S.
Fix wrong source file list in CMake of GCC_ARM_CM0 port. (#1045)
Add GCC/ARM_CM0/mpu_wrappers_v2_asm.c and GCC/ARM_CM0/portasm.c as source files to 'freertos_kernel_port' library.
This fixes the FREERTOS_PORT "GCC_ARM_CM0" CMake configuration.
Currently in Armv8-M GCC/ArmClang ports, constant pool is used to
define literals needed for `ldr` instructions. However, those
constant pools are defined with `.align 4` which increases code size.
Instead of defining the constant pool with `.align 4`, let the
compiler hanlde the constant pool and the required alignment.
The `portable/ThirdParty/GCC/ARM_TFM/README.md` and
`portable/ThirdParty/GCC/ARM_TFM/os_wrapper_freertos.c` are updated to
support `TF-Mv2.0.0` of trusted-firmware-m release.
The difference between a stream buffer and a stream batching buffer is when
a task performs read on a non-empty buffer:
- The task reading from a non-empty stream buffer returns immediately
regardless of the amount of data in the buffer.
- The task reading from a non-empty steam batching buffer blocks until the
amount of data in the buffer exceeds the trigger level or the block time
expires.
wat [Mon, 18 Mar 2024 06:09:49 +0000 (15:09 +0900)]
Improvement for 64bit Windows port (#1011)
* 64bit TickType_t is supported on Windows port.(MSVC and MinGW)
Especially it is introduced for 64bit compiler.(x64 platform on MSVC and MinGW-w64)
* Unnecessary compiler warning for the cast operation is disabled locally.(MinGW-w64 only)
* Modify the condition for ignoring compiler warning for the cast operation.
Before modification: Compiler warning was ignored only on MinGW64
After modification: Compiler warning is ignored on MinGW32 and MinGW64
Reason of modification: The cast warning here is unavoidable not only on MinGW64 but also on MinGW32.
"__GNUC__" macro is used because MSVC does not recognize this #pragma directive.
Add a compile time check that emits a helpful error message if the user
attempts to create a daemon task startup hook without also creating the
timer/daemon task.
The timer/daemon task startup hook runs in the context of the timer/daemon
task. Therefore, it won't run even if configUSE_DAEMON_TASK_STARTUP_HOOK
is set to 1 if the timer task isn't created. The timer task is only created if
configUSE_TIMERS is not equal to 0.
chinglee-iot [Wed, 6 Mar 2024 07:34:21 +0000 (15:34 +0800)]
Not using pxIndex to iterate ready list in trace utility (#1000)
* pxIndex should only be used when selecting next task. Altering pxIndex
of a ready list will cause the scheduler to be unable to select the
right task to run. Using a for loop if traversing the list for trace
utility is required.
* Not defining listGET_OWNER_OF_NEXT_ENTRY when using SMP scheduler
Aniruddha Kanhere [Tue, 20 Feb 2024 16:49:41 +0000 (08:49 -0800)]
Fix small bugs in Kernel (#998)
* Fix small bugs
* Cast sizeof to BaseType_t
* Test removing assert to fix UT
* Revert change to tasks.c
Since configIDLE_TASK_NAME must be defined as a string according to
the documentation, the macro will always be NULL terminated. Which
means that the check `if( cIdleName[ xIdleTaskNameIndex ] == ( char ) 0x00 )`
will catch the end of string.
* Update coverity config; Add coverity version; Update pvPortMalloc declaration to match the definitions.
* Add port files to sed command
* Remove warnings about unused parameters in port code
---------
Co-authored-by: Rahul Kar <118818625+kar-rahul-aws@users.noreply.github.com>
chinglee-iot [Mon, 19 Feb 2024 06:39:31 +0000 (14:39 +0800)]
Support reset kernel state for restarting scheduler (#944)
* Adding the following functions to reset kernel state. These functions are only required for application which
needs to restart the scheduler.
- void vTaskResetState( void )
- void vTimerResetState( void )
- void vPortHeapResetState( void )
- void vCoRoutineResetState( void )
---------
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com> Co-authored-by: Chris Morgan <cmorgan@boston-engineering.com> Co-authored-by: Soren Ptak <ptaksoren@gmail.com> Co-authored-by: Rahul Kar <118818625+kar-rahul-aws@users.noreply.github.com> Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com> Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
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>
chinglee-iot [Tue, 6 Feb 2024 12:41:34 +0000 (20:41 +0800)]
Fix SMP task self void run state change (#984)
* 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
chinglee-iot [Thu, 1 Feb 2024 03:12:08 +0000 (11:12 +0800)]
Delete kernel created task in vTaskEndScheduler (#962)
* 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.
barnatahmed [Tue, 30 Jan 2024 19:44:27 +0000 (20:44 +0100)]
Cmake: Create a single static library including port
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.
Phillip Stevens [Tue, 30 Jan 2024 05:42:20 +0000 (16:42 +1100)]
Fix ThirdParty/GCC/ATmega formatting (#965)
Unnecessary white space was introduced in PR #768
which affected the formatting of assembly code. This PR
returns the correct formatting. No functional change.
Forty-Bot [Mon, 29 Jan 2024 05:37:43 +0000 (00:37 -0500)]
GCC: MSP430F449: Fix pxPortInitialiseStack on EABI (#947)
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.
Mubin Sayyed [Fri, 26 Jan 2024 03:21:44 +0000 (08:51 +0530)]
Sync up MicroblazeV9 port with Xilinx tree (#220)
* 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>
Chris Morgan [Wed, 29 Nov 2023 13:15:50 +0000 (08:15 -0500)]
POSIX port - Switch from allowing the user to specify the stack memory itself, to allowing them to specify the stack size
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
begriffs.com / projects / freertos / log