STM32 Application FW aware about custom bootloader

[dimax]

Posted on June 22, 2013 at 09:23

HI,

Should the Application FW aware about custom bootloader seating in first Flash section. In other words should I use modified linker script to build an Applicaiton FW if I'm going to have my custom bootloader in first Flash section.   I think to move application 16Khigher to skip first 16K sector with bootloader. Instead of    FLASH (rx)   : ORIGIN = 0x8000000,   LENGTH = 1M To have    FLASH (rx)   : ORIGIN = 0x8004000,   LENGTH = 1M-16K But if you say that STM32 code is position independent I should not care about Flash origin and just to let bootloader to do the job by putting code at the right place in Flash.

[Tesla DeLorean]

Posted on June 22, 2013 at 09:46

But if you say that STM32 code is position independent I should not care about Flash origin and just to let bootloader to do the job by putting code at the right place in Flash.

A vector table of absolute addresses isn't that independent. So, yes you'd need to link at the newer/higher address for it to work properly at that address.

[Tesla DeLorean]

Posted on June 22, 2013 at 15:27

Are you trying to post from a mobile device (phone, tablet, etc?), The forum doesn't work with them.

[dimax]

Posted on June 22, 2013 at 15:36

Sorry did not know that mobile devices are not supported. If you can delete my empty posts please do it.

Here is what I wanted to say: Yes you are right. I still want to be able to run same image under boot loader and without boot loader (programmed directly to flash) For this I'm going to declare additional section boot_skip that will reside in first 16k segment and will only have reset vector pointing to my startup procedure. Application will start at second flash segment. It will contain interrupt vectors table and will configure vectors table offset appropriately. If such image will be programmed directly it should run correctly. If image is programmed via boot loader it will ignore any content in first 16k segment of the image. Do you see any problems with such approach?

[Tesla DeLorean]

Posted on June 22, 2013 at 16:08

It depends on how address agnostic the binary image is. You could link at two different addresses, convert to binary, and do a file compare. Say offset by 0x1248. This would allow you to quantify just how much changes. It also represents a sanity check in case some library or object is not compiled as you had hoped.

When the linker fixates a HEX/BIN file it performs any required relocations and discards this information. The .AXF files in this situation are also a form of ELF object without relocations, where as the .O form have a lot more information in them. In terms of accommodating Cortex-Mx vector tables, the general method for relocation would be to place the table in an area of RAM (512 byte aligned), add/sub an offset to the stored vectors as you copy them to RAM, and then point SCB->VTOR at this new table you have built. For example a vector entry that originally pointed to 0x0800018D gets 0x4000 added and the copy is 0x0800418D to reflect where the function is now located. You'd need to remove this RAM region from general usage.

[dimax]

Posted on June 22, 2013 at 17:00

[Tesla DeLorean]

Posted on June 22, 2013 at 17:13

I did not fully get your point. Maybe because you did not gt mine.

I'm going to use below sections allocation: MEMORY {    SRAM (xrw)   : ORIGIN = 0x20000000,  LENGTH = 128K    BKPSRAM (rw) : ORIGIN = 0x40024000,  LENGTH = 4K

   BOOT_SKIP (rx)   : ORIGIN = 0x8000000,   LENGTH = 16K

   FLASH (rx)   : ORIGIN = 0x8004000,   LENGTH = 1M-16K } Why should I have any problems with it? To my understanding I should get a working image starting from 0x8004000 instead of 0x800000

This also not clear for me. Why should I use RAM for vector table relocation?

If I have alternative vector table in Flash why shouldn't I simply set SCB->VTOR to this location in Flash (0x0000_4000 in my case) instead of default (0x0000_0000)? I still want to be able to run same image under boot loader and without boot loader (programmed directly to flash) Ok, so decide which it is. The processor is always going to be looking to start at 0x08000000. If you change the base of the FLASH in the linker script, that should be sufficient to change the basis of the output code. One would use RAM in situations where you wanted to change the vectors, or adapt them. If you link for a hard coded address, and place the code there, of course nothing will need to change.

[Amel NASRI]

Posted on July 09, 2013 at 15:58

If you can delete my empty posts please do it.

It is done. -Mayla-