Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Potential stack problem on STM32

Posted by Thomas Kindler on December 15, 2009
Hi!

We've just discovered a potential problem of the Cortex-M3 port on the STM32. We're using FreeRTOS 6.0.1 in a custom project based on the STM32 firmware library examples.

The problem shows up after starting the scheduler, and causes seemingly random data corruption.

The official start scripts provided in the Firmware Library set the initial stack to 0x20000400 after a reset:

CMSIS/Core/CM3/startup/gcc/startup_stm32f10x_hd.s:

[..]
.equ Initial_spTop, 0x20000400
[..]

[..]
g_pfnVectors:
.word Initial_spTop
.word Reset_Handler
.word NMI_Handler
[..]

So the processor will use 1kB of stack initially. The real stack value is initialized in the first few instructions of the reset handler:

LDR r0, =_estack // see linker script, typically 0x10000 on a 64k device.
MSR msp, r0

The problem is, that FreeRTOS' vPortStartFirstTask() will _reset_ the stack pointer to the initial value taken from the NVIC table!

void vPortStartFirstTask( void )
{
__asm volatile(
" ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. */
" ldr r0, [r0] \n"
" ldr r0, [r0] \n"
" msr msp, r0 \n" /* Set the msp back to the start of the stack. */
" svc 0 \n" /* System call to start first task. */
);
}

This will reload the MSP to 0x20000400 and causes hard-to-debug memory corruption afterwards.

There are two possible work-arounds:

- replace the NVIC lookup by "ldr r0,
=_estack \n", and place a warning in the port's documentation
- or convince ST to modify their start
scripts

I think, option 1 is the best solution. Option 2 is bad, because the stack might be in external RAM that needs initialization after reset.

best regards,
Thomas Kindler

RE: Potential stack problem on STM32

Posted by Dave on December 15, 2009
Position 0 of the vector table holds the location of the stack. This is the convention across all Cortex M3 devices and this is where the core itself will load the stack from before any code even gets executed.

The freertos code cannot be changed as per your option 1 because it is the same code that is used on all Cortex M3 chips, no matter who makes them (Atmel, Luminary/TI, NXP, etc. all use the same source files).

If ST insist on doing something bizarre then the best solution is just not to use the ST start up code. Which of the STM32 projects contains this code?

RE: Potential stack problem on STM32

Posted by Thomas Kindler on December 15, 2009
> Position 0 of the vector table holds the location of the stack.

Yeah, but only the _initial_ one.. the "real" stack might be in external RAM which needs to be configured first.

As it stands, FreeRTOS doesn't support this scenario.

> Which of the STM32 projects contains this code?

Only the startup file for high-density devices, as they're the only ones to support external memory.

RE: Potential stack problem on STM32

Posted by Richard on December 15, 2009

> Only the startup file for high-density devices, as they're the only ones to
> support external memory.

Is this start up code in the FreeRTOS download?

Regards.

RE: Potential stack problem on STM32

Posted by thomask77 on December 15, 2009
> Is this start up code in the FreeRTOS download?

No - I did a quick check, and all the examples leave the initial_sp alone (and none of them use external memory).

But it's included in the STM32 Firmware Library and ARM's official CMSISV1P10.ZIP, see Core/CM3/startup/arm/startupstm32f10x_FSMC.s .

It might become more common, when there are more chips with external memory interfaces.

A warning or notice in the documentation would be nice. (Or even an "assert(initial_sp >= sp);" ? ;)

Best regards!


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner