2021-11-10 09:01 AM
I'm trying to make a custom external flash loader for my STM32F746 uC based board and i found some templates for this purpose from this link that is belongs to the ST workshop on this YouTube link. So when i dug into the corresponding files i saw that in a linker script file named linker.ld the RAM memory region is defined from base address 0x20000004 though i know that the RAM memory region in STM32 uCs starts from address 0x20000000:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000004, LENGTH = 320K
}
I searched for many other templates file existing in this link and also they are using the same way for RAM memory region base address.
So the problem is why we must define RAM memory address from 0x20000004 for external flash loader algorithm to store in and not from 0x20000000 instead. Could anyone please help me to explain the reason and tell me that what will happen if we do the:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 320K
}
instead of previous one and what errors might be occurred?
Thanks.
2021-11-10 11:11 AM
No, the tools load the application into RAM, and *THEY* want it built for 0x20000004 as they add a code sequence at 0x20000000 to call the code within.
You're overthinking this, and applying the wrong knowledge, incorrectly.
The loader expects to determine the code entry points via symbols the linker places in the .ELF (.STLDR) file
>instead of previous one and what errors might be occurred?
The linker will build/bind the code to the wrong location, and the loader will likely fail, either immediately or with some latent failure.
2021-11-10 11:41 AM
@Community member
Thanks for your fast answer. What do you mean by "the tools"?
As i understand from your answer, you say that when a tool like ST-Link Utility tries to take some action on external flash so it expects that external flash loader algorithm is placed in somewhere in RAM that starts from 0x20000004.
Is that right?
2021-11-10 12:37 PM
Tools -> STM32 Cube Programmer and ST-LINK Utilities.
This loader code is injected into RAM and called/run via the debug interface to interact with your attached external memory device.
Other areas in the RAM are used to stage data as it is read/written, and act as the stack space for the loader code.
2021-11-10 12:43 PM
More broadly similar JTAG/SWD tools like ST-LINK, J-LINK and U-LINK employ similar methods to run loader code on the target.
I've posted a broad array of prebuilt external loaders for different STM32, memory devices and pin combinations.
https://github.com/cturvey/stm32extldr
2021-11-10 01:14 PM
@Community member
Thank you very much.
As the last question could you please explain that the first word in RAM memory (0x20000000 to 0x20000004) is used for what by this tools and what they put into this area that we must not use it for storing our external flash loader algorithm in and we must store it in address from 0x20000004?
wish you the best
2021-11-10 02:09 PM
Used as the return address in the link register (LR) , when calling the exported sub-functions, ie Init(), Write(), Verify(), etc
20000000 LOC loc_20000000:
20000000 BE00 bkpt $0000
20000002 0000 lsls r0, r0, #0
20000004 SUB16 sub_20000004:
20000004 B500 push {lr}
20000006 B085 sub sp, #20
20000008 F000 FBF8 bl sub_200007FC
2000000C 2000 movs r0, #0
2000000E 9000 str r0, [sp, #0]
20000010 2000 movs r0, #0
20000012 9001 str r0, [sp, #4]
20000014 2000 movs r0, #0
20000016 9002 str r0, [sp, #8]
20000018 2000 movs r0, #0
2000001A 9003 str r0, [sp, #12]
2000001C 201F movs r0, #31
2000001E 9004 str r0, [sp, #16]
20000020 A800 add r0, sp, #0
20000022 F000 FC19 bl sub_20000858
..
2021-11-10 02:14 PM
16:10:16:007 : UPLOADING ...
16:10:16:026 : Size : 1024 Bytes
16:10:16:026 : Address : 0x90000000
16:10:16:026 : Read progress:
16:10:16:027 : Reading data...
16:10:16:027 : halt ap 0
16:10:16:027 : w ap 0 reg 15 PC (0x20000000)
16:10:16:027 : w ap 0 reg 17 MSP (0x20000500)
16:10:16:027 : w ap 0 reg 16 xPSR (0x01000000)
16:10:16:027 : w ap 0 @0x20001DC0 0x00000200 bytes Data 0x00000000
16:10:16:031 : w ap 0 @0x20000000 0x00000004 bytes Data 0x0000BE00 <- Writes BKPT
16:10:16:087 : w ap 0 @0x20000004 0x00001998 bytes Data 0xB085B500 <- Writes Loader Image
16:10:16:088 : Loader read...
16:10:16:088 : Init flashloader...
16:10:16:093 : halt ap 0
16:10:16:095 : w ap 0 reg 0 R0 0x00000000
16:10:16:104 : w ap 0 reg 1 R1 0x00000000
16:10:16:104 : w ap 0 reg 2 R2 0x00000000
16:10:16:105 : w ap 0 reg 3 R3 0x00000000
16:10:16:105 : w ap 0 reg 4 R4 0x00000000
16:10:16:111 : w ap 0 reg 5 R5 0x00000000
16:10:16:119 : w ap 0 reg 6 R6 0x00000000
16:10:16:119 : w ap 0 reg 7 R7 0x00000000
16:10:16:122 : w ap 0 reg 8 R8 0x00000000
16:10:16:123 : w ap 0 reg 9 R9 0x00000000
16:10:16:123 : w ap 0 reg 10 R10 0x00000000
16:10:16:123 : w ap 0 reg 11 R11 0x00000000
16:10:16:126 : w ap 0 reg 12 R12 0x00000000
16:10:16:126 : w ap 0 reg 13 SP 0x00000000
16:10:16:140 : w ap 0 reg 14 LR 0x20000001 <- Here
16:10:16:140 : w ap 0 reg 15 PC 0x200006D3 <- Init()
16:10:16:142 : w ap 0 reg 16 xPSR 0x01000000
16:10:16:143 : w ap 0 reg 17 MSP 0x20001D98 <- Stack beyond loader
16:10:16:143 : w ap 0 reg 18 PSP 0x00000000
16:10:16:143 : run ap 0
16:10:16:151 : halt ap 0
16:10:16:155 : r ap 0 reg 0 R0 0x00000300
2021-11-10 02:23 PM
You can also get the tools to read the RAM. Note on the H7 series 0x24000004 is used..
2021-11-11 12:21 AM
Thank you very much. Actually you are the best.