Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




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 ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists