* Fix tickless idle when stopping systick on zero...
...and don't stop SysTick at all in the eAbortSleep case.
Prior to this commit, if vPortSuppressTicksAndSleep() happens to stop
the SysTick on zero, then after tickless idle ends, xTickCount advances
one full tick more than the time that actually elapsed as measured by
the SysTick. See "bug 1" in this forum post:
https://forums.freertos.org/t/ultasknotifytake-timeout-accuracy/9629/40
SysTick
-------
The SysTick is the hardware timer that provides the OS tick interrupt
in the official ports for Cortex M. SysTick starts counting down from
the value stored in its reload register. When SysTick reaches zero, it
requests an interrupt. On the next SysTick clock cycle, it loads the
counter again from the reload register. To get periodic interrupts
every N SysTick clock cycles, the reload register must be N - 1.
Bug Example
-----------
- Idle task calls vPortSuppressTicksAndSleep(xExpectedIdleTime = 2).
[Doesn't have to be "2" -- could be any number.]
- vPortSuppressTicksAndSleep() stops SysTick, and the current-count
register happens to stop on zero.
- SysTick ISR executes, setting xPendedTicks = 1
- vPortSuppressTicksAndSleep() masks interrupts and calls
eTaskConfirmSleepModeStatus() which confirms the sleep operation. ***
- vPortSuppressTicksAndSleep() configures SysTick for 1 full tick
(xExpectedIdleTime - 1) plus the current-count register (which is 0)
- One tick period elapses in sleep.
- SysTick wakes CPU, ISR executes and increments xPendedTicks to 2.
- vPortSuppressTicksAndSleep() calls vTaskStepTick(1), then returns.
- Idle task resumes scheduler, which increments xTickCount twice (for
xPendedTicks = 2)
In the end, two ticks elapsed as measured by SysTick, but the code
increments xTickCount three times. The root cause is that the code
assumes the SysTick current-count register always contains the number of
SysTick counts remaining in the current tick period. However, when the
current-count register is zero, there are ulTimerCountsForOneTick
counts remaining, not zero. This error is not the kind of time slippage
normally associated with tickless idle.
*** Note that a recent commit https://github.com/FreeRTOS/FreeRTOS-Kernel/commit/e1b98f0
results in eAbortSleep in this case, due to xPendedTicks != 0. That
commit does mostly resolve this bug without specifically mentioning
it, and without this commit. But that resolution allows the code in
port.c not to directly address the special case of stopping SysTick on
zero in any code or comments. That commit also generates additional
instances of eAbortSleep, and a second purpose of this commit is to
optimize how vPortSuppressTicksAndSleep() behaves for eAbortSleep, as
noted below.
This commit also includes an optimization to avoid stopping the SysTick
when eTaskConfirmSleepModeStatus() returns eAbortSleep. This
optimization belongs with this fix because the method of handling the
SysTick being stopped on zero changes with this optimization.
* Fix imminent tick rescheduled after tickless idle
Prior to this commit, if something other than systick wakes the CPU from
tickless idle, vPortSuppressTicksAndSleep() might cause xTickCount to
increment once too many times. See "bug 2" in this forum post:
https://forums.freertos.org/t/ultasknotifytake-timeout-accuracy/9629/40
SysTick
-------
The SysTick is the hardware timer that provides the OS tick interrupt
in the official ports for Cortex M. SysTick starts counting down from
the value stored in its reload register. When SysTick reaches zero, it
requests an interrupt. On the next SysTick clock cycle, it loads the
counter again from the reload register. To get periodic interrupts
every N SysTick clock cycles, the reload register must be N - 1.
Bug Example
-----------
- CPU is sleeping in vPortSuppressTicksAndSleep()
- Something other than the SysTick wakes the CPU.
- vPortSuppressTicksAndSleep() calculates the number of SysTick counts
until the next tick. The bug occurs only if this number is small.
- vPortSuppressTicksAndSleep() puts this small number into the SysTick
reload register, and starts SysTick.
- vPortSuppressTicksAndSleep() calls vTaskStepTick()
- While vTaskStepTick() executes, the SysTick expires. The ISR pends
because interrupts are masked, and SysTick starts a 2nd period still
based on the small number of counts in its reload register. This 2nd
period is undesirable and is likely to cause the error noted below.
- vPortSuppressTicksAndSleep() puts the normal tick duration into the
SysTick's reload register.
- vPortSuppressTicksAndSleep() unmasks interrupts before the SysTick
starts a new period based on the new value in the reload register.
[This is a race condition that can go either way, but for the bug
to occur, the race must play out this way.]
- The pending SysTick ISR executes and increments xPendedTicks.
- The SysTick expires again, finishing the second very small period, and
starts a new period this time based on the full tick duration.
- The SysTick ISR increments xPendedTicks (or xTickCount) even though
only a tiny fraction of a tick period has elapsed since the previous
tick.
The bug occurs when *two* consecutive small periods of the SysTick are
both counted as ticks. The root cause is a race caused by the small
SysTick period. If vPortSuppressTicksAndSleep() unmasks interrupts
*after* the small period expires but *before* the SysTick starts a
period based on the full tick period, then two small periods are
counted as ticks when only one should be counted.
The end result is xTickCount advancing nearly one full tick more than
time actually elapsed as measured by the SysTick. This is not the kind
of time slippage normally associated with tickless idle.
After this commit the code starts the SysTick and then immediately
modifies the reload register to ensure the very short cycle (if any) is
conducted only once. This strategy requires special consideration for
the build option that configures SysTick to use a divided clock. To
avoid waiting around for the SysTick to load value from the reload
register, the new code temporarily configures the SysTick to use the
undivided clock. The resulting timing error is typical for tickless
idle. The error (commonly known as drift or slippage in kernel time)
caused by this strategy is equivalent to one or two counts in
ulStoppedTimerCompensation.
This commit also updates comments and #define symbols related to the
SysTick clock option. The SysTick can optionally be clocked by a
divided version of the CPU clock (commonly divide-by-8). The new code
in this commit adjusts these comments and symbols to make them clearer
and more useful in configurations that use the divided clock. The fix
made in this commit requires the use of these symbols, as noted in the
code comments.
* Fix tickless idle with alternate systick clocking
Prior to this commit, in configurations using the alternate SysTick
clocking, vPortSuppressTicksAndSleep() might cause xTickCount to jump
ahead as much as the entire expected idle time or fall behind as much
as one full tick compared to time as measured by the SysTick.
SysTick
-------
The SysTick is the hardware timer that provides the OS tick interrupt
in the official ports for Cortex M. SysTick starts counting down from
the value stored in its reload register. When SysTick reaches zero, it
requests an interrupt. On the next SysTick clock cycle, it loads the
counter again from the reload register. The SysTick has a configuration
option to be clocked by an alternate clock besides the core clock.
This alternate clock is MCU dependent.
Scenarios Fixed
---------------
The new code in this commit handles the following scenarios that were
not handled correctly prior to this commit.
1. Before the sleep, vPortSuppressTicksAndSleep() stops the SysTick on
zero, long after SysTick reached zero. Prior to this commit, this
scenario caused xTickCount to jump ahead one full tick for the same
reason documented here: 0c7b04bd3a
2. After the sleep, vPortSuppressTicksAndSleep() stops the SysTick
before it loads the counter from the reload register. Prior to this
commit, this scenario caused xTickCount to jump ahead by the entire
expected idle time (xExpectedIdleTime) because the current-count
register is zero before it loads from the reload register.
3. Prior to return, vPortSuppressTicksAndSleep() attempts to start a
short SysTick period when the current SysTick clock cycle has a lot of
time remaining. Prior to this commit, this scenario could cause
xTickCount to fall behind by as much as nearly one full tick because the
short SysTick cycle never started.
Note that #3 is partially fixed by 967acc9b20
even though that commit addresses a different issue. So this commit
completes the partial fix.
* Improve comments and name of preprocessor symbol
Add a note in the code comments that SysTick requests an interrupt when
decrementing from 1 to 0, so that's why stopping SysTick on zero is a
special case. Readers might unknowingly assume that SysTick requests
an interrupt when wrapping from 0 back to the load-register value.
Reconsider new "_SETTING" suffix since "_CONFIG" suffix seems more
descriptive. The code relies on *both* of these preprocessor symbols:
portNVIC_SYSTICK_CLK_BIT
portNVIC_SYSTICK_CLK_BIT_CONFIG **new**
A meaningful suffix is really helpful to distinguish the two symbols.
* Revert introduction of 2nd name for NVIC register
When I added portNVIC_ICSR_REG I didn't realize there was already a
portNVIC_INT_CTRL_REG, which identifies the same register. Not good
to have both. Note that portNVIC_INT_CTRL_REG is defined in portmacro.h
and is already used in this file (port.c).
* Replicate to other Cortex M ports
Also set a new fiddle factor based on tests with a CM4F. I used gcc,
optimizing at -O1. Users can fine-tune as needed.
Also add configSYSTICK_CLOCK_HZ to the CM0 ports to be just like the
other Cortex M ports. This change allowed uniformity in the default
tickless implementations across all Cortex M ports. And CM0 is likely
to benefit from configSYSTICK_CLOCK_HZ, especially considering new CM0
devices with very fast CPU clock speeds.
* Revert changes to IAR-CM0-portmacro.h
portNVIC_INT_CTRL_REG was already defined in port.c. No need to define
it in portmacro.h.
* Handle edge cases with slow SysTick clock
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
Co-authored-by: abhidixi11 <44424462+abhidixi11@users.noreply.github.com>
Co-authored-by: Joseph Julicher <jjulicher@mac.com>
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com>
It was possible for a third party that had already independently gained
the ability to execute injected code to achieve further privilege
escalation by branching directly inside a FreeRTOS MPU API wrapper
function with a manually crafted stack frame. This commit removes the
local stack variable `xRunningPrivileged` so that a manually crafted
stack frame cannot be used for privilege escalation by branching
directly inside a FreeRTOS MPU API wrapper.
We thank Certibit Consulting, LLC, Huazhong University of Science and
Technology and the SecLab team at Northeastern University for reporting
this issue.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Clarify Cortex M7 r0p1 errata number in r0p1 specific port.
* Add ARM Cortex M7 r0p0 / r0p1 Errata 837070 workaround to CM4 MPU ports.
Optionally, enable the errata workaround by defining configTARGET_ARM_CM7_r0p0 or configTARGET_ARM_CM7_r0p1 in FreeRTOSConfig.h.
* Add r0p1 errata support to IAR port as well
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Change macro name to configENABLE_ERRATA_837070_WORKAROUND
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gaurav Aggarwal <aggarg@amazon.com>
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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Style: make freertos.org = FreeRTOS.org also add https
* Style: Fix freertos into FreeRTOS
* Style: Fix freertos into FreeRTOS
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
* Style: Change FreeRTOS websites in comments
* Style: Change freertos to FreeRTOS in comments
* Style: Remove broken link
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
The TEX, Shareable (S), Cacheable (C) and Bufferable (B) bits define
the memory type, and where necessary the cacheable and shareable
properties of the memory region.
The default values for these bits, as configured in our MPU ports, are
sometimes not suitable for application. One such example is when the MCU
has a cache, the application writer may not want to mark the memory as
shareable to avoid disabling the cache. This change allows the
application writer to override default vales for TEX, S C and B bits for
Flash and RAM in their FreeRTOSConfig.h. The following two new
configurations are introduced:
- configTEX_S_C_B_FLASH
- configTEX_S_C_B_SRAM
If undefined, the default values for the above configurations are
TEX=000, S=1, C=1, B=1. This ensures backward compatibility.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
ARMv7-M supports 8 or 16 MPU regions. FreeRTOS Cortex-M4 MPU ports so
far assumed 8 regions. This change adds support for 16 MPU regions. The
hardware with 16 MPU regions must define configTOTAL_MPU_REGIONS to 16
in their FreeRTOSConfig.h.
If left undefined, it defaults to 8 for backward compatibility.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
The reason for the change is that the register is called System Handler
Priority Register 3 (SHPR3).
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Problem Description
-------------------
The current flash organization in ARMv7-M MPU ports looks as follows:
__FLASH_segment_start__ ------->+-----------+<----- __FLASH_segment_start__
| Vector |
| Table |
| + |
| Kernel |
| Code |
+-----------+<----- __privileged_functions_end__
| |
| |
| |
| Other |
| Code |
| |
| |
| |
__FLASH_segment_end__ ------>+-----------+
The FreeRTOS kernel sets up the following MPU regions:
* Unprivileged Code - __FLASH_segment_start__ to __FLASH_segment_end__.
* Privileged Code - __FLASH_segment_start__ to __privileged_functions_end__.
The above setup assumes that the FreeRTOS kernel code
(i.e. privileged_functions) is placed at the beginning of the flash and,
therefore, uses __FLASH_segment_start__ as the starting location of the
privileged code. This prevents a user from placing the FreeRTOS kernel
code outside of flash (say to an external RAM) and still have vector
table at the beginning of flash (which is many times a hardware
requirement).
Solution
--------
This commit addresses the above limitation by using a new variable
__privileged_functions_start__ as the starting location of the
privileged code. This enables users to place the FreeRTOS kernel code
wherever they choose.
The FreeRTOS kernel now sets up the following MPU regions:
* Unprivileged Code - __FLASH_segment_start__ to __FLASH_segment_end__.
* Privileged Code - __privileged_functions_start__ to __privileged_functions_end__.
As a result, a user can now place the kernel code to an external RAM. A
possible organization is:
Flash External RAM
+------------+ +-----------+<------ __privileged_functions_start__
| Vector | | |
| Table | | |
| | | |
__FLASH_segment_start__ ----->+------------+ | Kernel |
| | | Code |
| | | |
| | | |
| | | |
| Other | | |
| Code | +-----------+<------ __privileged_functions_end__
| |
| |
| |
__FLASH_segment_end__ ----->+------------+
Note that the above configuration places the vector table in an unmapped
region. This is okay because we enable the background region, and so the
vector table will still be accessible to the privileged code and not
accessible to the unprivileged code (vector table is only needed by the
privileged code).
Backward Compatibility
----------------------
The FreeRTOS kernel code now uses a new variable, namely
__privileged_functions_start__, which needs to be exported from linker
script to indicate the starting location of the privileged code. All of
our existing demos already export this variable and therefore, they will
continue to work.
If a user has created a project which does not export this variable,
they will get a linker error for unresolved symbol
__privileged_functions_start__. They need to export a variable
__privileged_functions_start__ with the value equal to
__FLASH_segment_start__.
Issue
-----
https://sourceforge.net/p/freertos/feature-requests/56/
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
