Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


CMSIS-RTOS can't function properly due to issue in FreeRTOSConfig.h in FW 1.10.0

I’m trying to run a class on getting started in embedded systems, working up to using an RTOS and I’m having a few issues with the CMSIS-RTOS implementation in openSTM32.

I am working with the STM32F401C-Disco board and the HAL.

I create a new project using the “Ac6 STM32 MCU Project” Project type. Give it a name. Choose the STM32F401C-DISCO board. Tell it to use the Cube HAL. “As sources in the application project” and choose FreeRTOS to be included.

The version of the HAL firmware that it downloaded is “STM32Cube_FW_F4_V1.10.0” which is odd as this is not available in Cube from ST yet, ST still are only offering V1.9.0. Then I create the project.


In startup/startup_stm32f401xc.s we see that on line 158 it installs the symbol for “SysTick_Handler”. In Middlewares/Third_Party/FreeRTOS/Source/include/FreeRTOSConfig.h we see on lines 167-169 that the symbol USE_RTOS_SYSTICK has been defined and that the line:
”# define xPortSysTickHandler Systick_Handler” becomes active.

Problem, the vector table contains SysTick_Handler (with 3 capital letters) and the tick handler symbol is Systick_Handler (with 2 capital letters). The tick handler routine is never installed except for a weak routine.

The point, Tick is not the same as tick. There is a capitalization problem in the symbols.

Putting together a simple app, will always lead it to fail as soon as the first tick happens, right around the time that osKernelStart tries to start the first task.

Fixing the reference in FreeRTOSConfig.h gives a program that runs for a very short time before it corrupts the stack.

Generating a base program in CubeMX and importing it into Eclipse gives a set of base code, using firmware 1.9.0, with the same tasks, will happily run 3 tasks for days.

France

Hi Andrei,

Thanks for the report and sorry for the typo; I just check and it will be corrected in a future minor release that will be available soon.

Regarding the stack corruption, it may be due to different configuration options selected by default; which stack is corrupted? the main stack or some task stack?

We will try to check this and will keep you informed as soon as we progress on this.

Bernard (Ac6)


Stack corruption:

I will be working on it again soon, I found the capitalization thing last night at half past midnight.

My recollection is that the task at the highest address got corrupted.

(from memory)
I had 3 tasks
blinky at 500ms (LED toggle using the HAL), normal priority
blinky at 250ms, normal priority
calculation task doing calculation performance testing continually with no yields or waits, low priority so it will consume all unusable cycles.

The calculation task will do some calculations then printf some statistics, crunch for about 100M loops then print out statistics.

In the debugger I could see that the stack for each task was not being consumed. I would have expected that, if there was a memory leak, the stack would slowly fill and overflow, but the stack was completely stable.

I could see the printf buffer in the calculation task, being allocated in the task heap, was just above the top of one of the blinky task stacks.

After a while (about 15 minutes) with a lot of “halt and check stack”, the program would go into the tight loop at the Default_Handler (line 129 of startup_stm32f401xc.s) . I took a look at the registers and, if I remember correctly, the interrupting PC was 0. The stack for my blinky task was smashed and the task switch picked up a bogus PC. (does that make sense?)

I’ll see what I can do about recreating it all.

Andrei (as seen on the Embedded.fm podcast)


Some info hint if that can help base on my experiecne with freertos stm32 ac6 (cubemx)
The default stack size (128 or 256) is quite too small, stack of 512+ is not yet enough in some case (use of fatfs lib recurison etc ..)

The default heap size can be problematic as you use printf that can be source of quirck
I had issue with earlier ac6 due to the “0” intial heap relying on later stack break by _sbreak (need for malloc likley required by printf)
but that logic was broken with freertros due to speciific stack for task.
sbreak fail if malloc was called form non main task (cos sp is not the main heap/stack free ram area)
that was causing trouble in cascade hardly making any sense (invalid ptr call hard fault etc ... )