The example was trying to create a timer with period 0 which is not a
valid period.
This was reported here - https://forums.freertos.org/t/multiple-timers/13884
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
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.
Example usage is actually correct, so remove the -1. but update
the incorrect parameter description for pucStreamBufferStorageArea
and pucMessageBufferStorageArea.
* uncrustify with github workflows
* Fix find expression
* Add uncrustify configuration file
* Uncrustify some files
* uncrustify some more files
* uncrustify more files
* Fix whitespace at end of lines
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
* Introduce configRUN_TIME_COUNTER_TYPE which enables developers to define the type used to hold run time statistic counters. Defaults to uint32_t for backward compatibility. #define configRUN_TIME_COUNTER_TYPE to a type (for example, uint64_t) in FreeRTOSConfig.h to override the default.
Introduce ulTaskGetIdleRunTimePercent() to complement the pre-existing ulTaskGetIdleRunTimeCounter(). Whereas the pre-existing function returns the raw run time counter value, the new function returns the percentage of the entire run time consumed by the idle task. Note the amount of idle time is only a good measure of the slack time in a system if there are no other tasks executing at the idle priority, tickless
idle is not used, and configIDLE_SHOULD_YIELD is set to 0.
* Add ultaskgetidleruntimepercent to lexicon.txt.
* Update History file.
Add the MPU version of ulTaskGetIdleRunTimePercent().
* Update include/FreeRTOS.h to correct comment as per aggarg@ suggestion.
* Fix alignment in mpu_wrappers.h.
Commit changes to mpu_prototypes.h which were missed from the original commit.
* updated history.txt for 10.4.4
* Update the release date in History.txt
* added link to SMP branch to History.txt
* Added comment explaining the + in the version string
* corrected typos in the + comment
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com>
Co-authored-by: Paul Bartell <pbartell@amazon.com>
Overwrite an existing entry for a given xQueue handle when vQueueAddToRegistry is called with an xQueue handle of a queue that is already in the QueueRegistry.
configSTACK_ALLOCATION_FROM_SEPARATE_HEAP was added recently in
https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/267. This macro was
used in portable.h before its default value was defined, resulting in a
warning when built with -Wundef. This changes moves the default value
definition for configSTACK_ALLOCATION_FROM_SEPARATE_HEAP to portable.h
to ensure that it is defined before first use.
portUSING_MPU_WRAPPERS check in mpu_wrappers.h was updated in
https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/285. The new check
results in a warning when built with -Wundef because
portUSING_MPU_WRAPPERS is not defined yet. This changes adds the default
value definition for portUSING_MPU_WRAPPERS to portable.h to ensure that
it is defined before first use.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The change adds support for allocating task stacks from separate heap.
When configSTACK_ALLOCATION_FROM_SEPARATE_HEAP is defined as 1 in
FreeRTOSConfig.h, task stacks are allocated and freed using
pvPortMallocStack and vPortFreeStack functions. This allows the
application writer to provide a separate allocator for task stacks.
When configSTACK_ALLOCATION_FROM_SEPARATE_HEAP is defined as 0, task
stacks are allocated and freed using FreeRTOS heap functions
pvPortMalloc and vPortFree.
For backward compatibility, configSTACK_ALLOCATION_FROM_SEPARATE_HEAP
defaults to 0.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
This change removes the FreeRTOS System Calls (aka MPU wrappers) for the
following kernel APIs:
- xTaskCreateRestricted
- xTaskCreateRestrictedStatic
- vTaskAllocateMPURegions
A system call allows an unprivileged task to execute a kernel API which
is otherwise accessible to privileged software only. The above 3 APIs
can create a new task with a different MPU configuration or alter the
MPU configuration of an existing task. This an be (mis)used by an
unprivileged task to grant itself access to a region which it does not
have access to.
Removing the system calls for these APIs ensures that an unprivileged
task cannot execute this APIs. If an unprivileged task attempts to
execute any of these API, it will result in a Memory Fault.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>