# Hint: STM32 HD stack problem

**URL:** <https://forums.freertos.org/t/hint-stm32-hd-stack-problem/5315>\
**Category:** Kernel\
**Created:** [June 16, 2009, 9:36am UTC](https://forums.freertos.org/t/hint-stm32-hd-stack-problem/5315 "2009-06-16T09:36:33Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [June 16, 2009, 9:36am UTC](https://forums.freertos.org/t/hint-stm32-hd-stack-problem/5315/1 "2009-06-16T09:36:33Z")

</div>

**[cgerlach5](https://sourceforge.net/u/cgerlach5/)** wrote on [Tuesday, June 16, 2009](https://sourceforge.net/p/freertos/discussion/382005/thread/ea9054bd/#ecc9):

Hi All,

I just searched a while so I share it here before someone else is wasting time…

I am using a STM32 High-Density device with FreeRTOS and the ST FWlib 3.0 and had system crashes.  
Reason:  
The supplied startup code in the FWlib sets the stack pointer in the vector table (1st entry) to the fixed address 0x20000400. After initializing the external memory interface (if any) it sets the MSP register to the desired value (\_estack defined in the linker script).  
Normaly this should be ok but FreeRTOS resets the stack pointer (MSP) to the value stored in the vector table (when staring the first thread). This is ok and saves stack space.

The too ideas are nice but do not play together very well…

My solution was to edit the startup code&nbsp; (in $(FWLIB)/CMSIS/Core/CM3/startup) to place &\_estack into the vector table (I am not using external RAM).

Clemens

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [June 16, 2009, 11:50am UTC](https://forums.freertos.org/t/hint-stm32-hd-stack-problem/5315/2 "2009-06-16T11:50:42Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Tuesday, June 16, 2009](https://sourceforge.net/p/freertos/discussion/382005/thread/ea9054bd/#ecc9/7278):

Hmm, interesting.&nbsp; All CM3 devices are supposed to have the stack location in the first position within the vector table, FreeRTOS locates the vector table through the system control registers, and resets the stack back to its start position.&nbsp; Are you saying the STM32 startup code defines a different stack in the linker script to that pointed to by the vector table?&nbsp; I will need to look at that in more detail - thanks for the heads up.&nbsp; What is at 0x20000400?&nbsp;

This must be resurged in the linker script?

Regards.

---

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [June 16, 2009, 10:35pm UTC](https://forums.freertos.org/t/hint-stm32-hd-stack-problem/5315/3 "2009-06-16T22:35:38Z")

</div>

**[cgerlach5](https://sourceforge.net/u/cgerlach5/)** wrote on [Tuesday, June 16, 2009](https://sourceforge.net/p/freertos/discussion/382005/thread/ea9054bd/#ecc9/1bc8):

Hi Richard,

the problem only occurs with the STM32 startup code for the high-density&nbsp;&nbsp;  
devices. Since firmware lib 3.0.0 they are included. I think their intention  
for using this scheme was to provide a stack for the startup code (RAM&nbsp;&nbsp;&nbsp;&nbsp;  
starts at 0x20000000), setup the external memory controller and then move&nbsp;  
the stack to the end of the ram (which may be inside the external memory).

I think FreeRTOS behavior is correct. It just collides with the (example)  
routines from ST. But if someone (for whatever reason) wants to put the stack  
into external RAM FreeRTOS’ way of resetting the stack may be a problem.

From $(fwlib)/Libraries/CMSIS/Core/CM3/startup/gcc/startup\_stm32f10x\_hd.c:

#define Initial\_spTop&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0x20000400&nbsp;&nbsp;&nbsp;&nbsp; \<- this is in internal ram (cg)

[…]

\_\_attribute\_\_ ((section(".isr\_vector")))  
void (\* const g\_pfnVectors[])(void) =  
{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
&nbsp;&nbsp;&nbsp; (void \*)Initial\_spTop,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /\* The initial stack pointer \*/  
&nbsp;&nbsp;&nbsp; Reset\_Handler,  
&nbsp;&nbsp;&nbsp; …

[…]

void Reset\_Handler(void)  
{  
&nbsp; SystemInit\_ExtMemCtl();

&nbsp; /\* restore original stack pointer \*/  
&nbsp; asm(" LDR r0, =\_estack");&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \<- \_estack defined by linker script  
&nbsp; asm(" MSR msp, r0");

&nbsp; /\* Initialize data and bss \*/  
&nbsp;&nbsp; \_\_Init\_Data();

&nbsp; /\* Call the application’s entry point.\*/  
&nbsp; main();  
}

Maybe FreeRTOS’ stack reset behavior sould be documented in the port  
information. Also the use of the dual stack pointers is not mentioned  
there…

BTW: Thank’s for the great OS!

Clemens