ARMv7-M allows overlapping MPU regions. When 2 MPU regions overlap, the
MPU configuration of the higher numbered MPU region is applied. For
example, if a memory area is covered by 2 MPU regions 0 and 1, the
memory permissions for MPU region 1 are applied.
We use 5 MPU regions for kernel code and kernel data protections and
leave the remaining for the application writer. We were using lowest
numbered MPU regions (0-4) for kernel protections and leaving the
remaining for the application writer. The application writer could
configure those higher numbered MPU regions to override kernel
protections.
This commit changes the code to use highest numbered MPU regions for
kernel protections and leave the remaining for the application writer.
This ensures that the application writer cannot override kernel
protections.
We thank the SecLab team at Northeastern University for reporting this
issue.
Update of three badly terminated macro definitions (#555)
* Update of three badly terminated macro definitions
- vTaskDelayUntil() to conform to usual pattern do { ... } while(0)
- vTaskNotifyGiveFromISR() and
- vTaskGenericNotifyGiveFromISR() to remove extra terminating semicolons
- This PR addresses issues #553 and #554
* Adjust formatting of task.h
Co-authored-by: Paul Bartell <pbartell@amazon.com>
Gaurav-Aggarwal-AWS [Mon, 8 Aug 2022 15:53:29 +0000 (21:23 +0530)]
Generalize Thread Local Storage (TLS) support (#540)
* Generalize Thread Local Storage (TLS) support
FreeRTOS's Thread Local Storage (TLS) support used variables and
functions from newlib, thereby making the TLS support specific to
newlib. This commit generalizes the TLS support so that it can be used
with other c-runtime libraries also. The default behavior for newlib
support is still kept same for backward compatibility.
The application writer would need to set configUSE_C_RUNTIME_TLS_SUPPORT
to 1 in their FreeRTOSConfig.h and define the following macros to
support TLS for a c-runtime library:
1. configTLS_BLOCK_TYPE - Type used to define the TLS block in TCB.
2. configINIT_TLS_BLOCK( xTLSBlock ) - Allocate and initialize memory
block for the task's TLS Block.
3. configSET_TLS_BLOCK( xTLSBlock ) - Switch C-Runtime's TLS Block to
point to xTLSBlock.
4. configDEINIT_TLS_BLOCK( xTLSBlock ) - Free up the memory allocated
for the task's TLS Block.
The following is an example to support TLS for picolibc:
The code block which traverses the list of free blocks to calculate heap
stats used a do..while loop that moved past the end marker when the heap
had no free block resulting in a NULL pointer dereference. This commit
changes the do..while loop to while loop thereby ensuring that we never
move past the end marker.
This was reported here - https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/534
Patrick Oppenlander [Tue, 2 Aug 2022 10:39:58 +0000 (20:39 +1000)]
add portDONT_DISCARD to pxCurrentTCB (#479)
This fixes link failures with LTO:
/tmp/ccJbaKaD.ltrans0.ltrans.o: in function `pxCurrentTCBConst2':
/root/project/FreeRTOS/portable/GCC/ARM_CM4F/port.c:249: undefined reference to `pxCurrentTCB'
/usr/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/bin/ld: /tmp/ccJbaKaD.ltrans0.ltrans.o: in function `pxCurrentTCBConst':
/root/project/FreeRTOS/portable/GCC/ARM_CM4F/port.c:443: undefined reference to `pxCurrentTCB'
Gaurav-Aggarwal-AWS [Thu, 23 Jun 2022 17:17:17 +0000 (10:17 -0700)]
Ensure that xTaskGetCurrentTaskHandle is included (#507)
This commits adds a check that INCLUDE_xTaskGetCurrentTaskHandle is
set to 1. A compile time error message is produced if it is not set to
1. This is needed because stream_buffer.c uses xTaskGetCurrentTaskHandle.
This was reported here - https://forums.freertos.org/t/xstreambufferreceive-include-xtaskgetcur/15283
Graham Sanderson [Wed, 22 Jun 2022 17:27:26 +0000 (12:27 -0500)]
RP2040: Remove incorrect assertion (#508)
After the xEventGroupWaitBits in vProtLockInternalSpinUnlockWithWait there was an assertion about
pxYiledSpinLock being NULL, however when xEventGroupWaitBits returns, IRQs have been re-enabled
and so it is no longer safe to assert on the state which is protected by IRQs being disabled.
Co-authored-by: graham sanderson <graham.sanderson@raspeberryi.com>
Ravishankar Bhagavandas [Tue, 21 Jun 2022 00:48:34 +0000 (17:48 -0700)]
Add callback overrides for stream buffer and message buffers (#437)
* Let each stream/message can use its own sbSEND_COMPLETED
In FreeRTOS.h, set the default value of configUSE_SB_COMPLETED_CALLBACK
to zero, and add additional space for the function pointer when
the buffer created statically.
In stream_buffer.c, modify the macro of sbSEND_COMPLETED which let
the stream buffer to use its own implementation, and then add an
pointer to the stream buffer's structure, and modify the
implementation of the buffer creating and initializing
alfred gedeon [Wed, 1 Jun 2022 22:00:10 +0000 (00:00 +0200)]
Add suppport for ARM CM55 (#494)
* Add supposrt for ARM CM55
* Fix file header
* Remove duplicate code
* Refactor portmacro.h
1. portmacro.h is re-factored into 2 parts - portmacrocommon.h which is
common to all ARMv8-M ports and portmacro.h which is different for
different compiler and architecture. This enables us to provide
Cortex-M55 ports without code duplication.
2. Update copy_files.py so that it copies Cortex-M55 ports correctly -
all files except portmacro.h are used from Cortex-M33 ports.
Declare vApplicationMallocFailedHook function in task.h instead in each C heap file (#483)
vApplicationMallocFailedHook was declared in each Heap file. which forces users to declare it and can cause problems if the prototype of the function changes.
Gaurav-Aggarwal-AWS [Thu, 3 Mar 2022 23:16:39 +0000 (15:16 -0800)]
Check for add overflow only once (#467)
Update the size calculations such that we only need to check for add
overflow only once. Also, change the way we detect add overflow so that
we do not need to cause an overflow to detect an overflow.
Gaurav-Aggarwal-AWS [Mon, 28 Feb 2022 19:59:00 +0000 (11:59 -0800)]
Move MSB check after final size calculation (#463)
We use the MSB of the size member of a BlockLink_t to track whether not
a block is allocated. Consequently, the size must not be so large that
the MSB is set. The check to see if the MSB in the size is set needs to
be done after the final size (metadata + alignment) is calculated.
Gaurav-Aggarwal-AWS [Thu, 24 Feb 2022 18:52:10 +0000 (10:52 -0800)]
Heap improvements (#462)
* Heap improvements
This commit makes the following improvements:
1. Add a check to heap_2 to track if a memory block is allocated to the
application or not. The MSB of the size field is used for this
purpose. The same check already exists in heap_4 and heap_5. This
check prevents against double free.
2. Add a new flag configHEAP_CLEAR_MEMORY_ON_FREE to heap_2, heap_4 and
heap_5. The application writer can set it to 1 in their
FreeRTOSConfig.h to ensure that a block of memory allocated using
pvPortMalloc is cleared (i.e. set to zero) when it is freed using
vPortFree. If left undefined, configHEAP_CLEAR_MEMORY_ON_FREE
defaults to 0 for backward compatibility. We recommend setting
configHEAP_CLEAR_MEMORY_ON_FREE to 1 for better security.
3. Add a new API pvPortCalloc to heap_2, heap_4 and heap_5. This API
has the following signature:
void * pvPortCalloc( size_t xNum, size_t xSize );
It allocates memory for an array of xNum objects each of which is of
xSize and initializes all bytes in the allocated storage to zero. If
allocation succeeds, it returns a pointer to the lowest byte in the
allocated memory block. On failure, it returns a null pointer.
Paul Bartell [Wed, 19 Jan 2022 21:12:57 +0000 (13:12 -0800)]
Add configUSE_MINI_LIST_ITEM configuration option to enable the MiniListItem_t type. (#433)
* Add configUSE_MINI_LIST_ITEM configuration option to enable the MiniListItem_t type.
When configUSE_MINI_LIST_ITEM == 0:
MiniListItem_t and ListItem_t are both typedefs of struct xLIST_ITEM.
When configUSE_MINI_LIST_ITEM == 1 (the default in projdefs.h):
MiniListItem_t is a typedef of struct xMINI_LIST_ITEM, which contains 3 fewer fields than a struct xLIST_ITEM.
This configuration saves approximately sizeof(TickType_t) + 2 * sizeof( void * ) bytes of ram, however it also violates strict aliasing rules which some compilers depend on for optimization.
configUSE_MINI_LIST_ITEM defaults to 1 when not defined.
* Add pp_indent_brace option to uncrustify config
Improves compliance with the FreeRTOS code style guide:
https://www.freertos.org/FreeRTOS-Coding-Standard-and-Style-Guide.html
Jeff Tenney [Mon, 10 Jan 2022 19:44:12 +0000 (12:44 -0700)]
Fix support for stepping tick by xExpectedIdleTime (#73)
* Fix support for stepping maximum number of ticks
This commit fixes support for tickless implementations that call
vTaskStepTick() with the maximum number of allowed ticks to step.
vTaskStepTick()
---------------
Function vTaskStepTick() provides a way for the tickless idle
implementation to account for ticks that elapse during tickless idle.
The maximum number of stepped ticks allowed is the number passed to
portSUPPRESS_TICKS_AND_SLEEP(). It is the number of ticks between
xTickCount and xNextTaskUnblockTime.
vTaskStepTick() is specifically intended for use with tickless idle,
so it always executes with the scheduler disabled. For reference,
compare it with the more general function xTaskCatchUpTicks().
Without this Change
-------------------
Prior to this commit, if a task is supposed to wake at xTickCount ==
0xFFFFFFFF, then when tickless idle ends, function vTaskStepTick()
sets the tick to 0xFFFFFFFF but the task remains on the delayed list
because xTaskIncrementTick() does not execute. One tick later,
xTaskIncrementTick() executes because it's time to increment xTickCount
to 0x00000000. An assertion failure occurs in
taskSWITCH_DELAYED_LISTS() because the delayed task list is not
empty. Other examples of valling vTaskStepTick() with the maximum
allowed number of ticks merely result in a task waking one tick late.
Default Tickless Implementations
--------------------------------
Note that the default tickless implementations never pass the maximum
allowed value to vTaskStepTick(). The default implementations use the
tick interrupt to finish the sleep and allow that one tick to be
counted normally via the tick ISR and xTaskIncrementTick().
* Protect xPendedTicks with critical section
Function xTaskIncrementTick() increments xPendedTicks when the
scheduler is disabled. That function typically executes inside the tick
ISR. So code in xTaskCatchUpTicks() must mask interrupts when modifying
xPendedTicks.
* uncrustify tasks.c
* Update tasks.c
Style changes only - added comment and indentation to the two modified files.
* uncrustify
* Add test coverage for new conditional
* Add typecast
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com> Co-authored-by: Joseph Julicher <jjulicher@mac.com> Co-authored-by: RichardBarry <3073890+RichardBarry@users.noreply.github.com>
Gaurav-Aggarwal-AWS [Thu, 6 Jan 2022 05:14:01 +0000 (21:14 -0800)]
Add a cap to the queue locks (#435)
Add a cap to the queue locks
cRxLock and cTxLock members of the queue data structure count the
number items received and sent to the queue while the queue was locked.
These are later used to unblock tasks waiting on the queue when the
queue is unlocked. The data type of these members is int8_t and this can
trigger overflow check assert if an ISR continuously reads/writes to the
queue in a loop as reported in this issue: https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/419.
Note due to the length of the operation is it not recommended to write to
the queue that many times from an ISR - stream buffers are a better option,
or alternatively, defer the operation to a task by just having the ISR send a
direct to task notification to unblock the task.
This PR caps the values of the cRxLock and cTxLock to the number of tasks in
the system because we cannot unblocks more tasks than there are in the system.
Note that the same assert could still be triggered is the application creates more
than 127 tasks.
Amit Tomar [Wed, 29 Dec 2021 20:53:10 +0000 (02:23 +0530)]
fix alignment exception for ullPortInterruptNesting. (#317)
* fix alignment exception for ullPortInterruptNesting.
While loading (LDR X5, ullPortInterruptNestingConst) the ullPortInterruptNesting
variable, the program control seems to be stuck and there is no abort or stack
trace observed (as there is no exception handler is installed to catch unaligned
access exception).
Program control moves forward, if one just declares this varible to be 2 bytes
aligned but then varible is not updated properly.
One of my colleague, pointed out that issue is due to the fact that
ullPortInterruptNesting must be at 8 bytes aligned address but since
"vApplicationIRQHandler" (that has 4 bytes of address) is sitting between
two 8 bytes aligned addresses that forces ullPortInterruptNesting to be at
4 byte aligned address, causing all sort of mess.
It works on QEMU (on ARM64) as it is, since there is no such check for
unaligned access but on real hardware it is prohibited.
Workaround to this problem is, either we skip 4 byets (using .align 4) after
vApplicationIRQHandler declaration or declare it the end of all declarations.
This commit does the latter one.
Signed-off-by: Amit Singh Tomar <atomar25opensource@gmail.com>
* Update portASM.S
Remove 1 tab = 4 spaces
Co-authored-by: Amit Singh Tomar <atomar25opensource@gmail.com> Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com> Co-authored-by: Joseph Julicher <jjulicher@mac.com>
Gaurav Aggarwal [Thu, 7 Oct 2021 02:00:39 +0000 (19:00 -0700)]
Add option to disable unprivileged critical sections
This commit introduces a new config
configALLOW_UNPRIVILEGED_CRITICAL_SECTIONS which enables developers to
prevent critical sections from unprivileged tasks. It defaults to 1 for
backward compatibility. Application should set it to 0 to disable
critical sections from unprivileged tasks.
Tobias Nießen [Thu, 11 Nov 2021 01:39:01 +0000 (02:39 +0100)]
Mention portMAX_DELAY in xEventGroupWaitBits docs (#411)
The public function xEventGroupWaitBits passes xTicksToWait to the
function vTaskPlaceOnUnorderedEventList, which passes the number of
ticks to prvAddCurrentTaskToDelayedList and sets xCanBlockIndefinitely
to pdTRUE, causing the latter to block indefinitely if
xTicksToWait == portMAX_DELAY and INCLUDE_vTaskSuspend == 1.
Kevin Thibedeau [Mon, 8 Nov 2021 21:51:25 +0000 (16:51 -0500)]
Build with -Wmissing-prototypes flags vPortYieldFromISR() in the Posix port. (#409)
There's already a portYIELD_FROM_ISR() macro that calls vPortYield() which wraps the FromISR code.
It doesn't appear that vPortYieldFromISR() is intended to be publicly accessible in this port so
I've marked it as private to silence the warning.
event_create() also got flagged due to missing void in prototype.
begriffs.com / projects / freertos / log