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
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
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>
* 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
Co-authored-by: eddie9712 <qw1562435@gmail.com>
* 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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
vApplicationMallocFailedHook was declared in each Heap file. which forces users to declare it and can cause problems if the prototype of the function changes.
Co-authored-by: Pierre-Noel Bouteville <pnb990@gmail.com>
This is needed to support the case when SysTick timer is not clocked
from the same source as CPU. This support already exists in other
Cortex-M ports.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* replace duplicated if branch because empty by a comment to avoid warning/error with option GCC -Wduplicated-branches
* Missing ';'
* cosmetic comment
* update comment as suggested by Gaurav-Aggarwal-AWS
* cosmetic
Co-authored-by: Pierre-Noel Bouteville <pnb990@gmail.com>
* Add a guard around mpu_wrappers.c
This avoid linker errors when this file is accidently compiled in
projects using non-MPU ports.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Fix formatting check
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* 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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Add support for 16 MPU regions to GCC Cortex-M33 TZ port
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Add support for 16 MPU regions to Cortex-M33 NTZ GCC port
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The configuration was updated using
uncrustify -c .github/uncrustify.cfg -o .github/uncrustify.cfg --update-config-with-doc
to align with the actually used uncrustify version used, i.e., all
configuration is now explicitly set (and no longer implicit).
The files that are common to all ports ("portable/MemMang*" and
"portable/Common/mpu_wrappers.c" are now also autoformatted.
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com>
* Add CMake build
Allows to build and link FreeRTOS using CMake build system.
From top-level project it looks like this:
set(FREERTOS_PORT_GCC_ARM_CM4F ON)
set(FREERTOS_CONFIG_FILE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} CACHE STRING "")
add_subdirectory(third_party/FreeRTOS-Kernel)
Where FREERTOS_PORT_GCC_ARM_CM4F is FreeRTOS port name.
freertos is target name, which can be used in target_link_libraries()
* Add feature to set custom heap source file
Example how to set it from top-level project:
set(FREERTOS_HEAP ${CMAKE_CURRENT_LIST_DIR}/path_to/my_heap.c CACHE STRING "")
* Set cmake_minimum_required to 3.15
* Fail build when FREERTOS_CONFIG_FILE_DIRECTORY not set
* Rename library to freertos_kernel
* Rework FREERTOS_PORT option to act as combobox
* Use freertos_kernel_port cmake target
* Split port sources multiline
Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com>
Co-authored-by: Paul Bartell <pbartell@amazon.com>
* 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
* 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>
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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
