Main stack pointer stm32wle5xx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-25 05:54 AM
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.
Solved! Go to Solution.
- Labels:
-
STM32CubeIDE
-
STM32WL series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-31 08:54 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-25 10:47 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-26 01:05 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-26 03:41 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-27 04:35 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-31 08:54 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-01-31 11:29 PM
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.