Updated timers.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL() with tmrENTER/EXIT_CRITICAL().
- Added vTimerEnterCritical() and vTimerExitCritical() to map to the
data group critical section macros.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated stream_buffer.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with sbENTER/EXIT_CRITICAL_FROM_ISR().
- Added vStreambuffersEnterCritical/FromISR() and
vStreambuffersExitCritical/FromISR() to map to the data group critical
section macros.
- Added prvLockStreamBufferForTasks() and prvUnlockStreamBufferForTasks() to suspend the stream
buffer when executing non-deterministic code.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated event_groups.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with event_groupsENTER/EXIT_CRITICAL/_FROM_ISR().
- Added vEventGroupsEnterCritical/FromISR() and
vEventGroupsExitCriti/FromISR() functions that map to the data group
critical section macros.
- Added prvLockEventGroupForTasks() and prvUnlockEventGroupForTasks() to suspend the event
group when executing non-deterministic code.
- xEventGroupSetBits() and vEventGroupDelete() accesses the kernel data group
directly. Thus, added vTaskSuspendAll()/xTaskResumeAll() to these fucntions.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated queue.c to use granular locking
- Added xTaskSpinlock and xISRSpinlock
- Replaced critical section macros with data group critical section macros
such as taskENTER/EXIT_CRITICAL/_FROM_ISR() with queueENTER/EXIT_CRITICAL_FROM_ISR().
- Added vQueueEnterCritical/FromISR() and vQueueExitCritical/FromISR()
which map to the data group critical section macros.
- Added prvLockQueueForTasks() and prvUnlockQueueForTasks() as the granular locking equivalents
to prvLockQueue() and prvUnlockQueue() respectively
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Updated critical section macros with granular locks.
Some tasks.c API relied on their callers to enter critical sections. This
assumption no longer works under granular locking. Critical sections added to
the following functions:
- `vTaskInternalSetTimeOutState()`
- `xTaskIncrementTick()`
- `vTaskSwitchContext()`
- `xTaskRemoveFromEventList()`
- `vTaskInternalSetTimeOutState()`
- `eTaskConfirmSleepModeStatus()`
- `xTaskPriorityDisinherit()`
- `pvTaskIncrementMutexHeldCount()`
Added missing suspensions to the following functions:
- `vTaskPlaceOnEventList()`
- `vTaskPlaceOnUnorderedEventList()`
- `vTaskPlaceOnEventListRestricted()`
Fixed the locking in vTaskSwitchContext()
vTaskSwitchContext() must aquire both kernel locks, viz., task lock and
ISR lock. This is because, vTaskSwitchContext() can be called from
either task context or ISR context. Also, vTaskSwitchContext() must not
alter the interrupt state prematurely.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
- Updated prvCheckForRunStateChange() for granular locks
- Updated vTaskSuspendAll() and xTaskResumeAll()
- Now holds the xTaskSpinlock during kernel suspension
- Increments/decrements xPreemptionDisable. Only yields when 0, thus allowing
for nested suspensions across different data groups
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Changed xPreemptionDisable to be a count rather than a pdTRUE/pdFALSE. This
allows nested calls to vTaskPreemptionEnable(), where a yield only occurs when
xPreemptionDisable is 0.
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
xTaskPriorityInherit() is called inside a critical section from queue.c. This
commit moves the critical section into xTaskPriorityInherit().
Co-authored-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
In the RL78 FAR data model, pxPortInitialiseStack() did not initialize
the register image for the task parameter (pvParameters) correctly.
A:DE registers were saved with dummy values instead of the actual pointer.
Effect: on first context restore the function prologue read a corrupted
parameter. NEAR builds were not affected.
This patch aligns the FAR path with the calling convention and compiler
version:
- IAR V2: pass pvParameters via registers → DE = low 16 bits, A = high 8
- IAR V1 (fallback): keep legacy stack write
Also keeps the original stack-frame layout and updates the comment to
reflect that pointer sizes depend on __DATA_MODEL__.
Result: tasks in FAR receive the correct parameter at entry; NEAR remains
unchanged.
Co-authored-by: Thomas Quiniou <tquiniou@fdi-access.com>
The goal of this commit is to add the GCC/ARMClang non-MPU
port variant for ARM Cortex-R82 processor which is
ARMv8-R AArch64 based.
The work done is inspired by the GCC ARM_AARCH64 FreeRTOS port.
This port has the following features:
* Uses single security state (non TrustZone).
* Supports SMP (Symmetric multi-processing).
* Doesn't support Hypervisor (EL2).
* Doesn't support neither PMSA (MPU) nor VMSA (MMU).
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
* cortex-M ports: Clarify hardware-saved exception frame size variable
- Rename ulStackFrameSize to ulHardwareSavedExceptionFrameSize to
reflect the hardware-saved exception frame (8 or 26 words based
on FPU/lazy stacking).
- Add comments explaining standard vs extended frames.
- Apply across Cortex-M ports.
- No functional change, improves readability.
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* kernel-checker-script: Modify Arm copyright header regex
Arm's copyright header regex is modified with the following:
* Accept both single year copyright headers (e.g., "2024")
and year range copyright headers (e.g., "2024-2025").
* Accept both single-line copyright header and also
multi-line header.
* Add the escape backslash to accept only literal dot
not any character.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
---------
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
If a user configures the configASSERT macro to expand to nothing,
a call to the Win32 API SetWaitableTimer() doesn't get compiled.
This can happen if, for example, configASSERT(x) set defined as
assert(x) (from assert.h) which expands to nothing when NDEBUG is
set (common for "release" builds).
This commit does the following:
* Remove xEventGroupClearBitsFromISR and
xEventGroupSetBitsFromISR functions direct mapping
to xTimerPendFunctionCallFromISR in case the trace
facility is feature not set. This should match the
current implementation in which the application calling
xEventGroupClearBitsFromISR
without defining the trace macros
(i.e. traceENTER_xEventGroupClearBitsFromISR is
a blank function in this case) will end up calling
xTimerPendFunctionCallFromISR function directly.
This enhances the readability of the code by not
guarding the xEventGroup<Set/Clear>BitsFromISR
functions' declaration and definition based on
the trace facility macro (i.e. configUSE_TRACE_FACILITY).
* Refactor the guarding macros for MPU_xEventGroupClearBitsFromISR
and MPU_xEventGroupSetBitsFromISR functions to match the
change above.
The current implementation leads to redefinition warnings
as `event_groups.h`redefines xEventGroupClearBitsFromISR
and xEventGroupSetBitsFromISR based on
`configUSE_TRACE_FACILITY' after they have been defined based
on configUSE_MPU_WRAPPERS_V1 in `mpu_wrappers.h`. The
implemented changes should resolve these warnings.
Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com>
Add GCC_ARM_CRX_MPU to the set of FREERTOS_PORT patterns that trigger
adding mpu_wrappers.c and mpu_wrappers_v2.c to freertos_kernel_port
target_sources.
* [MSVC-MingW] Move windows headers to port.c
This prevents the inclusion of windows.h. into all header files using
FreeRTOS.h and thus defining several macros conflicting with common
definitions.
* [MSVC-MingW] Include correct header for compiler intrinsics
---------
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
GNU as makes unrecognized sections loadable and writable by default, but
LLVM's assembler requires specifying flags explicitly. Without them, the
linker generates "has non-ABS relocation" errors when trying to link the
resulting object files.
Previously, the shared thread key was deleted in xPortStartScheduler
after scheduler was ended. This created a race condition where
prvThreadKeyDestructor (responsible for freeing thread-specific heap
memory) would not be called if xPortStartScheduler deleted the key
before the last task deletion, as destructors are not invoked after key
deletion (see https://github.com/walac/glibc/blob/master/nptl/pthread_create.c#L145-L150).
Move thread key deletion to process exit to ensure all thread-specific
memory is properly freed.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Define configENABLE_PAC and configENABLE_BTI before including portable.h
to prevent "used before definition" warnings when these macros are not
set in FreeRTOSConfig.h.
Fixes: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/1293
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
- In list.h fix a typo in comments.
- In portable/ThirdParty/GCC/Posix/port.c fix compiler warning about
"gcc -Wwrite-strings".
Signed-off-by: Florian La Roche <Florian.LaRoche@gmail.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
The uxItemSize parameter in xQueueGenericCreate and
xQueueGeneenericCreateStatic APIs expects a UBaseType_t type.
Previously, the semSEMAPHORE_QUEUE_ITEM_LENGTH macro incorrectly cast
the value to uint8_t, causing type mismatch warnings. This change
resolves the issue by properly casting the value to UBaseType_t.
This issue was reported here: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/1285.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Compiling with clang static code analysis, possible NULL pointer
dereference are found. Since configASSERT() can possibly return
and continue "normal" operation, the code in queue.c and
stream_buffer.c can be adjusted to avoid NULL pointer exceptions.
Signed-off-by: Florian La Roche <Florian.LaRoche@gmail.com>
* Fix race in POSIX port `vPortEndScheduler`
The `vPortEndScheduler` checks whether it's a FreeRTOS thread after signalling the scheduler thread to stop. This creates a race between the check and the destruction of the thread key. By moving the signal to the scheduler thread after the check, the race is prevented.
* Code review suggestions
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
---------
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
FreeRTOS MPU: Remove MPU region number check
This change removes the assertion and runtime check that enforces
matching between configTOTAL_MPU_REGIONS and physical MPU
regions,. This allows applications running on devices with 16 MPU
regions to manage 8 MPU regions while leaving the remaining 8
for the kernel.
Signed-off-by: Erick Reyes <erickreyes@google.com>
Use architecture-dependent UBaseType_t instead of fixed type for
ullMachineTimerCompareRegisterBase. This type is defined to uint32_t or
uint64_t based on XLEN, resolving warnings on 32-bit platforms.
Reported by landretk@ on the PR FreeRTOS/FreeRTOS-Kernel#1176.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
RISC-V: refine fpu reg context offset
pxCode and mstatus stored at index 0 and 1 are based on XLEN.
Therefore, the correct formula to calculate the FPU register index
should be ( ( 2 * portWORD_SIZE ) + ( regIndex * portFPU_REG_SIZE ) ).
Signed-off-by: wangfei_chen <wangfei_chen@realsil.com.cn>
* port: riscv: Split the number of registers and the size of the context
* port: riscv: Create some macros for the FPU context
* port: riscv: Add a couple of macros that store fpu context
* port: riscv: Update the stack init function to include the fpu context size
* port: riscv: Add a chip_specific_extensions file that includes the F extension
* Update dictionary to include some risc-v instructions
* port: riscv: Fix a few typos
* port: riscv: Apply @aggarg's sugestions
Disable stack overflow check for MPU ports
Stack overflow check is not straight forward to implement for MPU ports
because of the following reasons:
1. The context is stroed in TCB and as a result, pxTopOfStack member
points to the context location in TCB.
2. System calls are executed on a separate privileged only stack.
It is still okay because an MPU region is used to protect task stack
which means task stack overflow will trigger an MPU fault.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
