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>
* 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>
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.
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>
prvWriteMessageToBuffer wrote the first sbBYTES_TO_STORE_MESSAGE_LENGTH
bytes of the size_t-typed length to the buffer as the data length. While
this functions on little endian, it copies the wrong bytes on big
endian. This fix converts the length to configMESSAGE_BUFFER_LENGTH_TYPE
first, and then copies the exact amount, thus fixing the issue.
Additionally it adds an assert to verify the size is not greater than
the max value of configMESSAGE_BUFFER_LENGTH_TYPE; previously this would
truncate silently.
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>
Example usage is actually correct, so remove the -1. but update
the incorrect parameter description for pucStreamBufferStorageArea
and pucMessageBufferStorageArea.
* 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>
* Indent contents of a taskENTER_CRITICAL/taskEXIT_CRITICAL block.
Move a few configASSERT() statements out of a path where they would always be triggered to prevent "condition is always true" compiler warnings.
* Replace configASSERT() positions due to unintended semantic change from the version where asserts were at the top of the file.
Co-authored-by: RichardBarry <richardbarry.c@gmail.com>
Co-authored-by: Gaurav-Aggarwal-AWS <33462878+aggarg@users.noreply.github.com>
Gaurav-Aggarwal-AWS
Amit Tomar
clemenskresser
Joseph Julicher
Fabian
leona
Graham Sanderson
Pramith K V
R. Dunbar Poor
RichardBarry
Gaurav Aggarwal
Laukik Hase
Tobias Nießen
Kevin Thibedeau
prplz
andrewtjs
Archit Gupta
Stephane Viau
swaldhoer
Qikai
Andres O. Vela
Shubham Kulkarni
Zim Kalinowski
sherryzhang
Paul Adelsbach
Jack Lam