cancel
Showing results for 
Search instead for 
Did you mean: 

Main stack pointer stm32wle5xx

en
Associate II

Hi

i try to figure out, if my main stack pointer is correct. When debug my program, after execute startup.s file the value of msp is 0x20008000, but like this i used only half sram, right? This micro have 64KB of sram. I believe that the value of msp would be 0x20010000, on top of the sram. This mcu have sram1 start 0x20000000 end 0x20007FFF, and sram2 start 0x20008000 end 0x2000FFFF.

Follow my linker script:

/* Highest address of the user mode stack */

_estack = ORIGIN(RAM1) + LENGTH(RAM1); /* end of "SRAM1" Ram type memory */

_Min_Heap_Size = 0x200;     /* required amount of heap */

_Min_Stack_Size = 0x800; /* required amount of stack */

/* Memories definition */

MEMORY

{

 ROM   (rx)   : ORIGIN = 0x08000000, LENGTH = 256K

 RAM1  (xrw)  : ORIGIN = 0x20000000, LENGTH = 32K   /* Non-backup SRAM1 */

 RAM2  (xrw)  : ORIGIN = 0x20008000, LENGTH = 32K   /* Backup SRAM2 */

}

Thanks in advance.

Enrico.

1 ACCEPTED SOLUTION

Accepted Solutions

Hi,

From where did you get this linker script? Is it the templates for GCC part of the STM32CubeWL_V1.1.0?

These are the only linker script I was able to find which has these issues. If you create a new project in CubeIDE (regardless if Empty or STM32Cube), they should both generate appropriate linker scripts describing the full RAM memory as one region which will allow more stack usage.

Anyway, you can modify the linker script as you please or generate a new one from an Empty or STM32Cube project...

I think the only thing you have to do is this:

MEMORY
{
  ROM   (rx)   : ORIGIN = 0x08000000, LENGTH = 256K
  RAM1  (xrw)  : ORIGIN = 0x20000000, LENGTH = 64K   /* SRAM1+SRAM2 */
}

Internal ticket reference to fix the template in STM32CubeWL package: 121969.

Let us know if we can consider this case answered.

View solution in original post

6 REPLIES 6
StjepanS
Associate II

Hello en,

I believe your startup script looks like this at the start

Reset_Handler:

 ldr  r0, =_estack

 mov  sp, r0     /* set stack pointer */

So variable, _estack is found in your linker script, which you have provided.

_estack = ORIGIN(RAM1) + LENGTH(RAM1) = 0x20000000 + 32K = 0x20000000 + 0x8000 = 0x20008000

So, stack pointer is correct.

If you want for your sp to start on 0x20010000, change linker script to :

_estack = ORIGIN(RAM1) + LENGTH(RAM1) + LENGTH(RAM2)

Hope this helps,

Stjepan

en
Associate II

Thanks Stjepan for reply. So in this condition, when my sp value is 0x20008000 i used only half low part of sram memory? Because above the sp value, the compiler by default not put any variable, correct? Thanks.

Enrico.

StjepanS
Associate II

Not correct.

Understand, that on build layer, _estack is just an variable in which is stored address.(pointer)

Your linker stores variables/functions to addresses following linker script.

For better understanding, try Build Analyzer integrated in STM32Cube IDE. (Make sure .map file is generated).

You can see address of every variable / function in RAM.( not local / static variables).

For understanding linker script and how programm is sorted into memory, try this link :

https://itachi.pl/hardware/writing_linker_script_for_stm32_from_scratch

en
Associate II

Yes _estack is just a variable. But if my _estack point to address 0x20008000 max stack size will be 0x8000, instead if _estack ponit to 0x20010000, max stack size will be 0x10000, because the stack grow down. Sorry i do not explain correctly, i was referring to the max capacity of the stack. My linker put from 0x20000000 this section .data and .bss. And I was wondering why the sram2(start 0x20008000) was not used. Thanks.

Hi,

From where did you get this linker script? Is it the templates for GCC part of the STM32CubeWL_V1.1.0?

These are the only linker script I was able to find which has these issues. If you create a new project in CubeIDE (regardless if Empty or STM32Cube), they should both generate appropriate linker scripts describing the full RAM memory as one region which will allow more stack usage.

Anyway, you can modify the linker script as you please or generate a new one from an Empty or STM32Cube project...

I think the only thing you have to do is this:

MEMORY
{
  ROM   (rx)   : ORIGIN = 0x08000000, LENGTH = 256K
  RAM1  (xrw)  : ORIGIN = 0x20000000, LENGTH = 64K   /* SRAM1+SRAM2 */
}

Internal ticket reference to fix the template in STM32CubeWL package: 121969.

Let us know if we can consider this case answered.

en
Associate II

Hi Mattias

this script was generated by cubeMX 6.4.0, starting from the example project LoRaWAN_End_Node.ioc in firmaware package STM32Cube_FW_WL_V1.1.0. selecting "Makefile" as "Toolchian/IDE". If i select STM32CubeIDE, should be ok(RAM length 64K). Now for fix this issue i modify the linker with:

_estack = ORIGIN(RAM1) + LENGTH(RAM1) + LENGTH(RAM2);

Thanks.