I have source code for STM32F0 and STM32L0 derivates. When I compile it with Kail armcc it works correct. When I compile it with the gcc then runs the programm in a hard fault exception. The different is only the portable for booth compiler.
For the MCU HAL I use the LL librarie from ST, which I have generated with CubeMX. When I also generate the FreeRTOS with CubeMX, than comes different version from FreeRTOS in the project. So I will use only one source code for FreeRTOS, I’ve downloaded the version from here. The problem exists with the version 10.2.1 and 10.3.1.
Switching between the compilers does not just change the FreeRTOS port layer, but also the linker script, libraries, and most likely the C start up code.
My first recommendation would be to ensure you have the stack overflow checking turned on, asserts defined, etc., Then if that does not identify the problem, simply step through the code in the debugger so you can see where the hard fault occurs.
Also, how are you generating the project for armcc and gcc? How are you switching the compilers? Are you using the CubeMX? If so, does the default generated project work?
Thanks for your hint. I’ve added the check of the stack overflow and implement the hook function with a assert(0). It run also into the hard fault exception.
My project is compiled with a makefile. In this makefile I switch between the differents for the compiler gcc and armcc. That is the linker configuration, all assembler code (startup code, ISR vector table and default handle) and the FreeRTOS portable implementation.
The project use dynamic memory allocation. SO I use at the moment the heap_4.c implementation for this. CubeMX is only for the start of the project used to generate the MCU initialisation.
The Cortex-M0 and M0+ have smale information for the hardfault exception, so is the search of the source not so easy.
Yes, I see that the last function uxListRemove() are inside from FreeRTOS with a access over a pointer which are point to a not supported address. By the cortex-M0+ dosn’t exists a hardfault status register. so I can only analyse the stack and the register context.
Now I found the problem. I have 4 user tasks and one task have a stack overrung from 584bytes. The stack check function variant 1 dosn’t find it. So I used the variant 2. Here was the same result, but I have seen the problem in the memory. After the first increase of the stack size (the overrun was now 264bytes) the check have detected this failure.
I missing here a besser check from over and underrun of the stack. For this check can add some bytes to the stack size.
The next problem is the configuration of the stack size. In the cmsis_os.h file is written that the stack size is configured in bytes, but it is configured in sizeof the type from the stack.
Stack checking isn’t perfect for most ports, but depends on (for level 1) the pointer being past the limit at the time of the scheduler running, or (for level 2) writing (and changing) one of the bytes in the guard band at the end of the stack. Thus if you overrun by a lot, sometimes the guard band is within an array that isn’t changed in the function, and then the function returns, so it isn’t detected, or it can happen that the system crashes before you get to the point of running the scheduler and it checking.