Paul Bartell [Fri, 28 May 2021 14:23:29 +0000 (07:23 -0700)]
Update github Auto-Release workflow to add an option to set the main branch version in task.h (#337)
Adding text into this new field updates the following macros in task.h in the main branch:
tskKERNEL_VERSION_NUMBER (alphanumeric string)
tskKERNEL_VERSION_MAJOR (numeric only)
tskKERNEL_VERSION_MINOR (numeric only)
tskKERNEL_VERSION_BUILD (numeric only)
Create macro versions of uxListRemove() and vListInsertEnd() for use in xTaskIncrementTick(). This provides a minor optimisation to remove the need for a few function calls. (#241)
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com> Co-authored-by: Aniruddha Kanhere <60444055+AniruddhaKanhere@users.noreply.github.com>
Jeff Tenney [Tue, 13 Apr 2021 18:05:46 +0000 (11:05 -0700)]
Remove support for tmrCOMMAND_START_DONT_TRACE (#305)
* Remove support for tmrCOMMAND_START_DONT_TRACE
Prior to this commit, the timer task used tmrCOMMAND_START_DONT_TRACE
to reload a "backlogged" auto-reload timer -- one for which a reload
operation would have started a period that had already elapsed. If the
command queue contained a stop or delete command when
tmrCOMMAND_START_DONT_TRACE was put into the queue for a reload, the
timer unexpectedly restarted when the timer task processed
tmrCOMMAND_START_DONT_TRACE. This commit implements a new method of
reloading auto-reload timers and eliminates support for
tmrCOMMAND_START_DONT_TRACE. No other code sends this private command.
However, the symbol tmrCOMMAND_START_DONT_TRACE remains defined, with
its original command value, so as not to impact trace applications.
Also fix one-shot timers that were not reliably being marked as not
active:
- when they expired before the start command could be processed
- when the expiration was processed during the timer list switch
Also improve consistency:
- Always reload auto-reload timers *before* calling the callback.
- Always call traceTIMER_EXPIRED() just prior to the callback.
* fix indent
* Revert unnecessary change to prvTimerTask()
Change was intended to faithfully work through a backlog that spanned a
list switch, and before processing a stop or delete command. But, (1)
it isn't important to do that, and (2) the code didn't accomplish the
intention when *two* auto-reload timers were backlogged across a list
switch. Best to simply leave this part of the code as it was before.
* fix style
Co-authored-by: Joseph Julicher <jjulicher@mac.com>
Paul Bartell [Sat, 10 Apr 2021 00:06:58 +0000 (17:06 -0700)]
Overwrite existing QueueRegistry entries when a handle is added multiple times. (#306)
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.
Define default values of macros before first use (#298)
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.
RichardBarry [Sat, 20 Mar 2021 18:58:07 +0000 (11:58 -0700)]
A recent change in the FreeRTOS/FreeRTOS hub repo (which submodules this repo) introduced use of a new compile time constant configRUN_ADDITIONAL_TESTS. This check in adds a default for the constant that will be used in builds to which it does not apply. (#266)
Gaurav-Aggarwal-AWS [Fri, 12 Mar 2021 20:11:19 +0000 (12:11 -0800)]
Update comment in list.c (#276)
The tick interrupt priority must be configured to ensure that it cannot
interrupt a critical section. This change updates the comment to help
the application writer while debugging.
Paul Bartell [Sat, 6 Mar 2021 02:46:49 +0000 (18:46 -0800)]
Add some assertions and coverage exceptions to queue.c (#273)
* Add an LCOV_BRANCH exception for the check that sizeof( StaticQueue_t ) == sizeof( Queue_t )
* Add LCOV_BRANCH coverage exception for a configASSERT on pxQueueSetContainer with a condition that is unreachable.
* Add configASSERTs to alert when invalid parameters are passed into Queue Registry related functions.
* Assert that the semaphore handle passed into xQueueGetMutexHolder is not NULL.
* Correct some typos in queue.c
* Update lexicon.txt
Gaurav-Aggarwal-AWS [Wed, 24 Feb 2021 02:36:27 +0000 (18:36 -0800)]
Support allocating stack from separate heap (#267)
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.
Gaurav-Aggarwal-AWS [Mon, 7 Dec 2020 17:53:22 +0000 (09:53 -0800)]
Prevent unprivileged task from altering MPU configuration (#227)
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.
uxCriticalNesting is initialized to a large value at the start and set
to zero when the scheduler is started (xPortStartScheduler). As a
result, before the scheduler is started, a pair of enter/exit critical
section will leave the interrupts disabled because uxCriticalNesting
will not reach zero in the vPortExitCritical function. This is done to
ensure that the interrupts remain disabled from the time first FreeRTOS
API is called to the time when the scheduler is started. The scheduler
starting code is expected to enure that interrupts are enabled before
the first task starts executing.
Cortex-M33 ports were not enabling interrupts before starting the first
task and as a result, the first task was started with interrupts
disabled. This PR fixes the issue by ensuring that interrupts are
enabled before the first task is started.
magicse7en [Mon, 26 Oct 2020 18:47:21 +0000 (02:47 +0800)]
Xtensa: fix the coproc_area incorrect issue (#117)
* Xtensa: fix the coproc_area incorrect issue
foss-xtensa/amazon-freertos#2 mentioned a issue:
1.
In function pxPortInitialiseStack(StackType_t *pxTopOfStack....)
p = (uint32_t *)(((uint32_t) pxTopOfStack - XT_CP_SIZE) & ~0xf);
In function prvInitialiseNewTask (file: task.c)
pxTopOfStack = (pxStack + (ulStackDepth - 1)) & (~portBYTE_ALIGNMENT_MASK)
So the co-processor area is at
p = (uint32_t *)(((uint32_t)((pxStack + (ulStackDepth - 1)) & (~portBYTE_ALIGNMENT_MASK)) - XT_CP_SIZE) & ~0xf);
2.
In function vPortStoreTaskMPUSettings( .... , StackType_t pxBottomOfStack ...)
xMPUSettings->coproc_area = (StackType_t)((((uint32_t)(pxBottomOfStack + usStackDepth - 1)) - XT_CP_SIZE) & ~0xf);
The p is coproc_area that should be equal to xMPUSettings->coproc_area.
For example, assume pxStack is 0xa0000000, ulStackDepth is 0x2000,
portBYTE_ALIGNMENT_MASK is 0x7f, XT_CP_SIZE is 0x100.
The p = (uint32_t)(((uint32_t)((pxStack + (ulStackDepth - 1)) & (~portBYTE_ALIGNMENT_MASK)) - XT_CP_SIZE) & ~0xf)
= 0xa0001e80
The xMPUSettings->coproc_area = (StackType_t)((((uint32_t)(pxStack+ usStackDepth - 1)) - XT_CP_SIZE ) & ~0xf)
= 0xa0001ef0
Obviously, the p is not equal to the xMPUSettings->coproc_area, which will cause context switching error.
In function pxPortInitialiseStack of port.c:
sp = ( StackType_t * ) ( ( ( UBaseType_t ) ( pxTopOfStack + 1 ) - XT_CP_SIZE - XT_STK_FRMSZ ) & ~0xf );
We assume XT_CP_SIZE is 0xE4, XT_STK_FRMSZ is 0xA0, pxTopOfStack is 0xA0000000, sp is 0x9FFFFE80.
From port.c, we know the frame->a1 as below:
frame->a1 = ( UBaseType_t ) sp + XT_STK_FRMSZ; /* physical top of stack frame */
So frame->a1 is 0x9FFFFF20. Therefore the interrupt stack frame range is 0x9FFFFE80 ~ 0x9FFFFF20.
The coproc_area is: p = ( uint32_t * ) ( ( ( uint32_t ) pxTopOfStack - XT_CP_SIZE ) & ~0xf );
So its value is 0x9FFFFF10. Obviously, the interrupt stack frame overlaps the coproc_area.
Co-authored-by: Carl Lundin <53273776+lundinc2@users.noreply.github.com>
Gaurav-Aggarwal-AWS [Fri, 23 Oct 2020 00:09:35 +0000 (17:09 -0700)]
Fix missed yield in xTaskResumeFromISR (#207)
If a higher priority task than the currently running task was resumed
using xTaskResumeFromISR and the user chose to ignore the return value
of xTaskResumeFromISR to initiate a context switch using
portYIELD_FROM_ISR, we were not doing the context switch on the next run
of the scheduler. This change fixes this by marking a yield as pending
to ensure that the context switch is performed on the next run of the
scheduler.
RichardBarry [Sun, 11 Oct 2020 21:04:49 +0000 (14:04 -0700)]
Recently vTaskDelayUntil() was updated to xTaskDelayUntil() because the function now returns a value. The PR didn't make the same change in the MPU port, or update the constants required to include the xTaskDelayUntil() function in the build. (#199)
This PR:
Changes the INCLUDE_vTaskDelayUntil compile time constant to INCLUDE_xTaskDelayUntil.
Updates FreeRTOS.h to ensure backward compatibility for projects that already have INCLUDE_vTaskDelayUntil defined.
Updates the MPU prototypes, wrapper and implementation to use the updated xTaskDelayUntil() function.
Tests to be checked into the FreeRTOS/FreeRTOS repository after this PR.
RichardBarry [Sun, 11 Oct 2020 04:47:54 +0000 (21:47 -0700)]
xStreamBufferSend() caps the maximum amount of data a stream buffer can send to the maximum capacity of the buffer - however the value to which the length is capped was wrong, and is correct by this check in. Likewise when sending to a message buffer if the send length is too long the block time is set to 0 to ensure the sending task does not wait indefinitely for the impossible send to complete - but the length check was wrong, and is corrected by this check in. (#195)
begriffs.com / projects / freertos / log