Skip to main content
ARost.9
Associate II
November 10, 2021
Question

External Flash Loader linker script file

  • November 10, 2021
  • 4 replies
  • 3716 views

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.

This topic has been closed for replies.

4 replies

Tesla DeLorean
Guru
November 10, 2021

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.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
ARost.9
ARost.9Author
Associate II
November 10, 2021

@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?

Tesla DeLorean
Guru
November 10, 2021

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.

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
ARost.9
ARost.9Author
Associate II
November 10, 2021

@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

Tesla DeLorean
Guru
November 10, 2021

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
..

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
ARost.9
ARost.9Author
Associate II
November 11, 2021

Thank you very much. Actually you are the best.