* 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>
* Add better pointer declaration readability
I revised the declaration of single-line pointers by splitting it into
multiple lines. Now, every pointer is declared (and initialized
accordingly) on its own line. This refactoring should enhance
readability and decrease the probability of error when a new pointer is
added/removed or a current one has its initialization value modified.
Signed-off-by: Cristian Cristea <cristiancristea00@gmail.com>
* Remove unnecessary whitespace characters and lines
It removes whitespace characters at the end of lines (empty or
othwerwise) and clear lines at the end of the file (only one remains).
It is an automatic operation done by git.
Signed-off-by: Cristian Cristea <cristiancristea00@gmail.com>
Signed-off-by: Cristian Cristea <cristiancristea00@gmail.com>
* Update RISC-V IAR port to support vector mode.
* uncrustify
Co-authored-by: David Chalco <david@chalco.io>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com>
It was possible for an unprivileged task to invoke any function with
privilege by passing it as a parameter to MPU_xTaskCreate,
MPU_xTaskCreateStatic, MPU_xTimerCreate, MPU_xTimerCreateStatic, or
MPU_xTimerPendFunctionCall.
This commit ensures that MPU_xTaskCreate and MPU_xTaskCreateStatic can
only create unprivileged tasks. It also removes the following APIs:
1. MPU_xTimerCreate
2. MPU_xTimerCreateStatic
3. MPU_xTimerPendFunctionCall
We thank Huazhong University of Science and Technology for reporting
this issue.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.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>
This allows the application write to set FREERTOS_CONFIG_FILE_DIRECTORY
to whichever directory the FreeRTOSConfig.h file exists in.
This was reported here - https://github.com/FreeRTOS/FreeRTOS-Kernel/issues/545
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
When the heap is exhausted (no free block), start and end markers are
the only blocks present in the free block list:
+---------------+ +-----------> NULL
| | |
| V |
+ ----- + + ----- +
| | | | | |
| | | | | |
+ ----- + + ----- +
xStart pxEnd
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
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Add xPortRemoveInterruptHandler API
This API is added to the MicroBlazeV9 port. It enables the application
writer to remove an interrupt handler.
This was originally contributed in this PR - https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/523
* Change API signature to return void
This makes the API similar to vPortDisableInterrupt.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Co-authored-by: Gavin Lambert <uecasm@users.noreply.github.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>
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>
* 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>
* 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>
* RP2040: malloc needs to be thread safe for FreeRTOS whether both cores are used or not
* RP2040: CMake file had broken left over test code
* RP2040: portIS_FREE_RTOS_CORE() returned an incorrect value prior to scheduler init when the application was compiled without multicore support
* RP2040: Bad initialization code was causing IRQs to get disabled before main() was called when using non static allocation
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>
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.
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Mention that FreeRTOS_IRQ_Handler should not be used for FIQs and the
reason for assuming Group 1 for Interrupt Acknowledge and End Of
Interrupt registers.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Let the FreeRTOS IRQ handler properly store and restore the ICCIAR
register value around the vApplicationIRQHandler() call.
Signed-off-by: Stephane Viau <stephane.viau@oss.nxp.com>
Co-authored-by: Stephane Viau <stephane.viau@oss.nxp.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
The secure side context management code now checks that the secure
context being saved or restored belongs to the task being switched-out
or switched-in respectively.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
This commit improves ARMv8-M security by pre-allocating secure-side task
context structures and changing how tasks reference a secure-side
context structure when calling a secure function. The new configuration
constant secureconfigMAX_SECURE_CONTEXTS sets the number of secure
context structures to pre-allocate. secureconfigMAX_SECURE_CONTEXTS
defaults to 8 if left undefined.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* Tidy up the 8051 sdcc port
* Replace tabs with spaces in SDCC Cygnal port.c file.
Co-authored-by: John Lin <shaojun.lin@delonghigroup.com>
Co-authored-by: Paul Bartell <pbartell@amazon.com>
* Use cast to fix warnings.
* Remove all empty definitions of portCLEAN_UP_TCB( pxTCB ) and
portALLOCATE_SECURE_CONTEXT( ulSecureStackSize ) from ports.
When these are undefined, the default empty definition is defined
in FreeRTOS.h.
The difference between this port and portable/GCC/ARM_CA53_64_BIT is
that this port uses System Register interface to access CPU interface
while the other one uses Memory-mapped interface.
Signed-off-by: Gaurav Aggarwal
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.
event_wait_timed() was ignoring a timeout of 1000 ms.
Presumably this is because pthread_cond_timedwait() only
considers tv_nsec less than one second.
Convert the timeout in miliseconds to second and nanosecond
components to fix this.
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com>
* Adjust portPOINTER_SIZE_TYPE to correct size
portPOINTER_SIZE_TYPE wasn't yet set correctly to be 16 bit
* Fixed FreeRTOS file header to comply with automatic checks
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
* Revert "Reintroduce Espressif's IDF v4.2 changes to ESP32 port (#193)"
This reverts commit 3d4d17178f.
* Update ESP32 port files to work with ESP-IDF v4.2 as well as ESP-IDF v3.3
Add changes required to support ESP32-S2
* portmacro.h: Change return type of vApplicationSleep to void
This fixes build failure when automatic light sleep is enabled
* prevent header checks for files with different licensing
Co-authored-by: David Chalco <david@chalco.io>
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>
Critical sections in FreeRTOS are implemented using the following two
functions:
void vPortEnterCritical( void )
{
portDISABLE_INTERRUPTS();
uxCriticalNesting++;
}
void vPortExitCritical( void )
{
uxCriticalNesting--;
if( uxCriticalNesting == 0 )
{
portENABLE_INTERRUPTS();
}
}
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.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
* 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);
pxBottomOfStack = pxStack
=> xMPUSettings->coproc_area = (StackType_t*)((((uint32_t)(pxStack+ ulStackDepth - 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.
Signed-off-by: magicse7en <magicse7en@outlook.com>
* Update port.c
Co-authored-by: Carl Lundin <53273776+lundinc2@users.noreply.github.com>
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>
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.
* Renamed old port to ESP_IDF_V3
* Update ESP32 port files to support IDF v4.2.
* Add changes required to support ESP32-S2
Co-authored-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
* Posix: Fix no task switching issue if a task ended
When the main function of a task exits, no task switching happened.
This is because all the remaining tasks are waiting on the condition
variable. The fix is to trigger a task switch and mark the exiting
task as "Dying" to be suspened and exited properly from the scheduler.
* Posix: Assert and stop if the Task function returned
* Posix: just assert if a task returned from its main function
Co-authored-by: alfred gedeon <alfred2g@hotmail.com>
* Posix: Free Idle task resources after ending the scheduler
In case of using Posix simulator and ending the scheduler, it does
not free the resources allocated by the idle task. This
causes the memory checkers (Valgrind, Address Sanitizers, ..) to
complain.
* Posix: Free the condition variable memory in the correct place
In case of deleting a task from another task, the deletion happens
immediately and the thread is canceled but the memory allocated by
the task condition variable is not freed. This causes the memory
checkers (Valgrind, Address sanitizers, ..) to complain.
* Posix: End Timer thread and free its resources after ending the scheduler
* Maintenance: Add readme.txt in each Renesas RX folder to show recomended port
* Update readme.txt in each Renesas RX folder regarding to Notes *1 and *2 (both are RX100 port)
* Style: fix some broken/redirect links
* Fix: atmel url
* Fix microchip typo
* Fix url links
* Fix shortcut link
* Comment: fix line wrapping
* Style: fix line wrapping to 80 chars
* Add now microchip beside Atmel
* Fix link in History
* Add Now Microchip before Atmel link
* Comment: add *
* Change vPortSetupTimerInterrupt in order to have 64bits access on rv64
* Support RV32E - RISC-V architecture (GCC)
Signed-off-by: Emmanuel Puerto <emmanuel.puerto@sifive.com>
* Support FPU - RISC-V architecture (GCC)
Signed-off-by: Emmanuel Puerto <emmanuel.puerto@sifive.com>
* Fix interrupt managment and FPU initialization
* Synopsys Port: Adding support to Synopsys ARC v1 series cores
ARC v1 cores include ARC605, ARC610d, and ARC710d
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
* Synopsys ARC v1 port: run uncrustify to fix code style
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
* Synopsys port: modify license headers, change copyright only
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
* Add RX200 GCC compiler
Signed-off-by: Dinh Van Nam <vannam.dinh.xt@renesas.com>
* Update GCC compiler for:
* RX600v2
* RX600
* RX100
Signed-off-by: Dinh Van Nam <vannam.dinh.xt@renesas.com>
* Use configINCLUDE_PLATFORM_H_INSTEAD_OF_IODEFINE_H flag
* Use configINCLUDE_PLATFORM_H_INSTEAD_OF_IODEFINE_H flag RX100, RX200
Co-authored-by: Dinh Van Nam <vannam.dinh.xt@renesas.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>
* Update port.c
I discovered a very snicky and tricky race condition scenario when integrating tracealyzer code into our project.
A little background on CortexR5 : When the IRQ line (comming from the interrupt controller, to which every peripheral IRQ lines connect) of the processor rises and the IRQ Enable bit in the status register of the CPU permits it, the CPU traps into interrupt mode. Several things happen. First, the CPU finishes the instruction it was performing. Second, it places the content of the CPSR register into the SPSR_irq register. And third, the mode of the CPU is changed to IRQ_Mode and /!\ THE IRQ ENABLE BIT IN CPSR_irq IS AUTOMATICALLY CLEARED /!\. The reason is to ensure that upon landing into IRQ code, we find ourselves automatically in a critical section because we cannot be interrupted again because the bit is cleared. The programmer can, if he wants, re-enable IRQs inside IRQ code itself to allow interrupt nesting. But it has to be wanted and meditated.
Now, inside portASM.S, at the end of 'FreeRTOS_IRQ_Handler' assembly function, a call to 'vTaskSwitchContextConst' is made if the variable 'ulPortYieldRequired' was set by someone while executing the interrupt. Before branching to that function, a 'CPSID i' instruction was placed to ensure that interrupts are disabled in case someone re-enabled it. Inside 'vTaskSwitchContext', there is the macro 'traceTASK_SWITCHED_OUT' that gets populated when tracing is enabled.
The bug is right there.. If the macro is populated and inside that macro there is a matching call to 'ulPortSetInterruptMask' and 'vPortClearInterruptMask', a race condition can occure is there is a OS Tick timer interrupt waiting at the interrupt controller's door. Upon calling 'vTaskSwitchContext', the interrupts are not masked in the interrupt controller, the only barrier against the CPU servicing that tick interrupt while already performing the function is that the IRQ Enable bit cleared. 'ulPortSetInterruptMask'
does what's its supposed to do, but doesn't take into account the IRQ Enable bit in CPSR. Wheter or not the bit was cleared, the function sets it at the end. When calling the matching 'vPortClearInterruptMask', the function clears the interrupt mask in the interrupt controller. Because the IRQ Enable bit (that was cleared) has been set no matter what in 'ulPortSetInterruptMask', the CPU services the OS Tick Interrupt right away.
The bug is there : instead of completing the 'vTaskSwitchContext' function, the CPU re-enters the switch context path right after 'traceTASK_SWITCHED_OUT' thus corrupting the CPU state and eventually triggering either an undefined instruction, data or instruction abort.
* Update port.c
Error on my part, this is the right inline asm code to retreive CPSR register
* Update port.c
Forgot an * while writing comment..
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>
* Removed TICK_stop() macro from portable/GCC/{AVR_AVRDx, AVR_Mega0}/porthardware.h because it is not used anywhere.
* Updated indentation in portable/GCC/{AVR_AVRDx, AVR_Mega0}/* files.
* Added portable/IAR/{AVR_AVRDx, AVR_Mega0 folders.
The expected behaviour of portIS_PRIVILEGED is:
- return 0 if the processor is not running privileged.
- return 1 if the processor is running privileged.
Some TI ports do not return 1 when the processor is running privileged
causing the following check to fail: if( xRunningPrivileged != pdTRUE )
This commit change the check to: if( xRunningPrivileged == pdFALSE ). It
ensures that the check is successful even on the ports which return incorrect
value from portIS_PRIVILEGED when the processor is running privileged.
See https://forums.freertos.org/t/kernel-bug-nested-mpu-wrapper-calls-generate-an-exception/10391
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
configSYSTICK_CLOCK_HZ should be used to configure SysTick to support
the use case when the clock for SysTick timer is scaled from the main
CPU clock.
configSYSTICK_CLOCK_HZ is defined to configCPU_CLOCK_HZ when it is not
defined in FreeRTOSConfig.h.
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>
Update BSP APIs to latest version
Remove unused macro which could have caused warnings
(Code Style) Manually align some macros
Signed-off-by: Yuguo Zou <yuguo.zou@synopsys.com>
These definitions were not useful because the corresponding mapping was
removed from mpu_wrappers.h earlier.
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>
Some of the privileged symbols were not being placed in their respective
sections. This commit addresses those and places them in
privileged_functions or privileged_data section.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
If xTaskCreate API is used to create a task, the task's stack is
allocated on heap using pvPortMalloc. This places the task's stack
in the privileged data section, if the heap is placed in the
privileged data section.
We use a separate MPU region to grant a task access to its stack.
If the task's stack is in the privileged data section, this results in
overlapping MPU regions as privileged data section is already protected
using a separate MPU region. ARMv8-M does not allow overlapping MPU
regions and this results in a fault. This commit ensures to not use a
separate MPU region for the task's stack if it lies within the
privileged data section.
Note that if the heap memory is placed in the privileged data section,
the xTaskCreate API cannot be used to create an unprivileged task as
the task's stack will be in the privileged data section and the task
won't have access to it. xTaskCreateRestricted and
xTaskCreateRestrictedStatic API should be used to create unprivileged
tasks.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
When Link Time Optimization (LTO) is enabled, some of the LDR
instructions result in out of range access. The reason is that the
default generated literal pool is too far and not within the permissible
range of 4K.
This commit adds LTORG assembly instructions at required places to
ensure that access to literals remain in the permissible range of 4K.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Refer to https://www.freertos.org/a00133.html.
The issue with the implementation is that, if only stop kernel tick the program will keep executing current task.
The desired behavior is to at least return/jump to the next instruction after vTaskStartScheduler().
Signed-off-by: Yuhui Zheng <10982575+yuhui-zheng@users.noreply.github.com>
* fix: CLEAR MIE BIT IN INITIAL RISC-V MSTATUS VALUE
The MIE bit in the RISC-V MSTATUS register is used to globally enable
or disable interrupts. It is copied into the MPIE bit and cleared
on entry to an interrupt, and then copied back from the MPIE bit on
exit from an interrupt.
When a task is created it is given an initial MSTATUS value that is
derived from the current MSTATUS value with the MPIE bit force to 1,
but the MIE bit is not forced into any state. This change forces
the MIE bit to 0 (interrupts disabled).
Why:
If a task is created before the scheduler is started the MIE bit
will happen to be 0 (interrupts disabled), which is fine. If a
task is created after the scheduler has been started the MIE bit
is set (interrupts enabled), causing interrupts to unintentionally
become enabled inside the interrupt in which the task is first
moved to the running state - effectively breaking a critical
section which in turn could cause a crash if enabling interrupts
causes interrupts to nest. It is only an issue when starting a
newly created task that was created after the scheduler was started.
Related Issues:
https://forums.freertos.org/t/risc-v-port-pxportinitialisestack-issue-about-mstatus-value-onto-the-stack/9622
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
Enabling Link Time Optimization (LTO) causes some of the functions used
in assembly to be incorrectly stripped off, resulting in linker error.
To avoid this, these functions are marked with portDONT_DISCARD macro,
definition of which is port specific. This commit adds the definition
of portDONT_DISCARD for ARMv7-M ports.
Signed-off-by: Gaurav Aggarwal
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>
This is similar to the Windows port, allowing FreeRTOS kernel
applications to run as regular applications on Posix (Linux) systems.
You can use this in a 32-bit or 64-bit application (although there are
dynamic memory allocation trace points that do not support 64-bit
addresses).
Many of the same caveats of running an RTOS on a non-real-time system
apply, but this is still very useful for easy debugging/testing
applications in a simulated environment. In particular, it allows easy
use of tools such as valgrind.
You can call standard library functions from tasks but care must be
taken with any that internally take mutexes or block. This includes
malloc()/free() and many stdio functions (e.g., printf()).
Replacement malloc(), free(), realloc(), and calloc() functions are
provided which are safe. printf() needs to be called with a FreeRTOS
mutex help (or called from only a single task).
Each task is run in its own pthread, which makes debugging with
standard tools (such as GDB) easier backtraces for individual tasks
are available. Threads for non-running tasks are blocked in sigwait().
The stack for each task (thread) is allocated when the thread is
created, and the stack provided during task creation is not used. This
is so the stack has guard pages, to help with detecting stack
overflows.
Task switch is done by resuming the thread for the next task by
sending it the resume signal (SIGUSR1) and then suspending the current
thread.
The timer interrupt uses SIGALRM and care is taken to ensure that the
signal handler runs only on the thread for the current task.
The additional data needed per-thread is stored at the top on the
task's stack.
When a running task is being deleted, its thread is marked it as dying
so when we switch away from it it exits instead of suspending. This
ensures that even if the idle task doesn't run, threads are deleted
which allows for more threads to be created (if many tasks are being
created and deleted in rapid succession).
To further aid debugging, SIGINT (^C) is not blocked inside critical
sections. This allows it to be used break into GDB while in a critical
section. This means that care must be taken with any custom SIGINT
handlers as these are like NMIs.
This is somewhat inspired by an existing port by William Davy
(https://www.freertos.org/FreeRTOS-simulator-for-Linux.html) but it
takes a number of different approaches to make it switch tasks
reliableand there's little similarly with the original implementation.
- Critical sections block scheduling/"interrupts" by blocking signals
using pthread_sigmask(). This is more expensive than attempting to
use flags but works reliably and is analogous to the interrupt
enable/disable on real hardware.
- Care is take to ensure that the SIGALRM handler (for the timer tick)
is runnable only on the pthread for the running task. This makes
tasks switches more straight-forward and reliable as we can suspend
the thread while in the signal handler.
- Task switches save/restore the critical nesting on the stack.
- Only uses a single (SIGUSR1) signal which is ignored and thus GDB's
default signal handling options won't trap/print on this signal.
- Extra per-thread data is stored on the task's stack, making it
accessible in O(1) instead of performing a O(n) lookup of the array.
- Uses the task create/delete hooks in a similar way to the Windows
port, rather than overloading trace points.
xtensa_loadstore_handler.S uses _iram_end to prevent modification of IRAM
code. With the LoadStore exception handler in place, IRAM can also be
used for .bss and .data section. Hence the sanity check should be based
upon _iram_text_end and not _iram_end
Laukik Hase
Jeff Tenney
Cristian Cristea
Ming Yue
Gaurav Aggarwal
Paul Bartell
Gabor Toth
Jakub Lužný
Octaviarius
Gaurav-Aggarwal-AWS
Archit Gupta
RichardBarry
Chris Copeland
Gavin Lambert
0xjakob
NomiChirps
Xinyu Zhang
Graham Sanderson
Ravishankar Bhagavandas
AndreiCherniaev
alfred gedeon
Dusan Cervenka
Kody Stribrny
pierrenoel-bouteville-act
niniemann
Felipe Torrezan
imi415
Shubham Kulkarni
swaldhoer
yhsb2k
Amit Tomar
Fabian
leona
Kevin Thibedeau
andrewtjs
Stephane Viau
Qikai
sherryzhang
Jack Lam
Kristine Jassmann
Graham Sanderson
Thomas Pedersen
Joseph Julicher
j4cbo
Evgeny Ermakov
Meco Jianting Man
carlo-dev-git
Tobias Schulte
David Chalco
Thomas Pedersen
Cobus van Eeden
alfred gedeon
David Chalco
filipgeorge
Carl Lundin
Jon Snow
magicse7en
Reda Maher
NoMaY (a user of Japan.RenesasRulz.com)
Emmanuel Puerto
YuguoWH
Simon Beaudoin
m17336
DavidJurajdaNXP
Alfred Gedeon
Yuhui Zheng
Phillip Stevens
David Vrabel
RichardBarry
Vladimir Umek
Sachin Parekh