| commit | c13719d2d03a452d0c8b9f00d2c135047a85d2a4 | [log] [tgz] |
|---|---|---|
| author | Amit Tomar <amittomer25@gmail.com> | Thu Dec 30 02:23:10 2021 +0530 |
| committer | GitHub <noreply@github.com> | Wed Dec 29 13:53:10 2021 -0700 |
| tree | 60612a28e61eb07b24f3763cd7d9923e75b09f7b | |
| parent | 7b95420ad9e72253ddbf0cea45a0e17c9256b3ef [diff] |
fix alignment exception for ullPortInterruptNesting. (#317) * 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>
This repository contains FreeRTOS kernel source/header files and kernel ports only. This repository is referenced as a submodule in FreeRTOS/FreeRTOS repository, which contains pre-configured demo application projects under FreeRTOS/Demo directory.
The easiest way to use FreeRTOS is to start with one of the pre-configured demo application projects. That way you will have the correct FreeRTOS source files included, and the correct include paths configured. Once a demo application is building and executing you can remove the demo application files, and start to add in your own application source files. See the FreeRTOS Kernel Quick Start Guide for detailed instructions and other useful links.
Additionally, for FreeRTOS kernel feature information refer to the Developer Documentation, and API Reference.
If you have any questions or need assistance troubleshooting your FreeRTOS project, we have an active community that can help on the FreeRTOS Community Support Forum.
To clone using HTTPS:
git clone https://github.com/FreeRTOS/FreeRTOS-Kernel.git
Using SSH:
git clone git@github.com:FreeRTOS/FreeRTOS-Kernel.git
The root of this repository contains the three files that are common to every port - list.c, queue.c and tasks.c. The kernel is contained within these three files. croutine.c implements the optional co-routine functionality - which is normally only used on very memory limited systems.
The ./portable directory contains the files that are specific to a particular microcontroller and/or compiler. See the readme file in the ./portable directory for more information.
The ./include directory contains the real time kernel header files.
FreeRTOS files are formatted using the “uncrustify” tool. The configuration file used by uncrustify can be found in the FreeRTOS/FreeRTOS repository.
lexicon.txt contains words that are not traditionally found in an English dictionary. It is used by the spellchecker to verify the various jargon, variable names, and other odd words used in the FreeRTOS code base. If your pull request fails to pass the spelling and you believe this is a mistake, then add the word to lexicon.txt. Note that only the FreeRTOS Kernel source files are checked for proper spelling, the portable section is ignored.