Bootloader

[atomic]

Hi there! Is there a way to specify the location of my program as a compiler directive?

Rather than have my program compile to start at 0x08000000, can I specify it to start at 0x080057F0 instead?

[ket]

Hi,

You can change the linker script to control the way the code is placed into memory. Look into the build output of your project. The pre-last line building the elf file includes the linker script that specifies the starting address. Edit that lds file to start from a different address.
Please note that if you simply relocate the start of the flash memory to the new address, the ISR vector will also be placed there that is probably not a valid configuration.

[atomic]

Great, thanks for the answer.

To clarify what you’re saying… Changing the start address of the compiled code will break any interrupt handlers?

If that is the case, is there a way to specify the location of a function? For example, if I was able to specify the location of the Reset_Handler(), would that become the start of the program and continue with valid interrupt handlers?

I’m attempting to port the bootloader from our Pic to the STM32F2. I recently noticed there is support in the chip for a bootloader that appears built in? There doesn’t seem to be much information in the datasheet about it. So I assume porting my old bootloader from the Pic would be easier.

[atomic]

I guess what i’m lookin for is the equilevant of …

#org 0x0008, 0xfff0 {}

#org 0x10000, 0x11000 auto=0
#inline
main() {
...
...
...
}

[support]

Hi,

On STM32 and other GCC-based systems the order in which the code/data is placed in memory is controlled by the linker script. You can find the script by looking at the link command line – the script is specified with the -T option. E.g. for the STM32F100VB device the linker script will be in %LOCALAPPDATA%VisualGDBEmbeddedBSPsarm-eabicom.sysprogs.arm.stm32STM32F1xxxxLinkerScriptsSTM32F100xB_flash.lds

If you want to put a certain function to a given address you need 2 actions:
1. Put the function into a separate section
2. Modify the linker script to put that section at a given address

E.g.to put Reset_Handler at 0x080057f0 you need to modify the linker script in the following way:

.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector))
. = 0x57F0;
*(.myentry)
. = ALIGN(4);
} > FLASH

and then put the Reset_Handler into the “.myentry” section:

void __attribute__((naked, noreturn)) __attribute__((section(".myentry"))) Reset_Handler()

You can view the output by adding -Wl,-Map=project.map to LDFLAGS and rebuilding your project. The linker will create a project.map file describing the placement of all code and data in the memory. Here’s a snippet for the new Reset_Handler:

0x20002000                _estack = 0x20002000

.isr_vector     0x08000000     0x5840
0x08000000                . = ALIGN (0x4)
*(.isr_vector)
.isr_vector    0x08000000      0x1d0 Debug/mystartup.o
0x08000000                g_pfnVectors
0x000057f0                . = 0x57f0
*fill*         0x080001d0     0x5620
*(.myentry)
.myentry       0x080057f0       0x50 Debug/mystartup.o
0x080057f0                Reset_Handler
0x08005840                . = ALIGN (0x4)

If you look at the generated .bin file you will see that it consists of a vector table in the beginning followed by zero bytes and the code starts at 0x57f0 address. Note that the second entry in the vector file points to 0x080057f1 (that means 0x080057f0 in THUMB mode). Please also note that the vector table needs to be located in the beginning of the file as the CPU expects it there.

[atomic]

That’s a fantastic and professional response! Thank you 😀

[CanonFodder]

Howdy,

I am trying to avoid using IAR and am attempting to setup a VisualGDB embedded project to accomplish the STM32 OTA application.

This requires 3 images:

• ResetManager 0x08000000
• OTA Service Manager 0x08003000
• Primary image 0x08006000

Where I am stuck is how to alter the linker files correctly for each image, bounding each to a particular space and testing for this during build. In IAR this was rather straight forward.

I would also like to know if there are any straight forward methods of packaging up all 3 parts into one programmable package

 

Cheers

[support]

Hi,

You can use the objcopy tool to add arbitrary sections to an ELF file at given addresses. A sample use of objcopy to replace a section in the file is shown in our Keil tutorial: http://visualgdb.com/tutorials/arm/keil/

Simply take the ELF file you want to debug and use objcopy to attach the contents of other files (.bin files produced from .elf files) at the addresses where you want them to be. Ensure you set the sections flags correctly (see the flags on the main code section) so that GDB can program your file.

Let us know if that works for you.

[CanonFodder]

As a summation, what I think is the correct process is to just alter the MEMORY declaration of the .lds file for each of my three separate images. I want the intvet/isrvector to be located separately for each image, thus:

ResetManager
Memory
{
FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 2K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 96K
}

OTAServiceManager
Memory
{
FLASH (RX) : ORIGIN = 0x08000800, LENGTH = 12K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 96K
}

Application
Memory
{
FLASH (RX) : ORIGIN = 0x08003800, LENGTH = 488K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 96K
}

 

Does this seem accurate?

 

Thank you

• This reply was modified 9 years, 6 months ago by CanonFodder.

[CanonFodder]

Is there a straight forward method of overriding the default .lds file used by the project?

• This reply was modified 9 years, 6 months ago by CanonFodder.

[devrope]

Is there a straight forward method of overriding the default .lds file used by the project?

+1

[support]

Hi,

Yes, in the latest VisualGDB 5.0 Beta 4 you can change it via VisualGDB Project Properties.

We even added a button that automatically copies the default linker script to the project directory, opens it in VS and updates the project to use it.

[Author]

Posts