Loading multiple executables on the STM32 flash memory

[wfarid]

Posted on January 21, 2011 at 23:41

Loading multiple executables on the STM32 flash memory

[Tesla DeLorean]

Posted on May 17, 2011 at 14:22

The processor runs the code located at 0x08000000, actually the vector at +4. There is no boot loader involved, unless you use the BOOTx pins to boot from system memory. You'd need to put your controlling application first, at 0x08000000.

You would need to set Keil to compile your independent applications to link at addresses like 0x08001000, 0x08002000, 0x08003000. Your controlling application could then set SP to the vector at +0, and PC to the vector at +4. The application(s) would need to set the NVIC to use their respective boot/vector address.

[wfarid]

Posted on May 17, 2011 at 14:22

Hi clive1,

 So, I've 3 developed projects where each project interfaces with specific peripherals on the development board. And, I want to load all 3 hex files ( or any other form of executable ) corresponding to each project to the flash memory and execute one of these codes at a time from the flash. I'm not sure why did you mention executing the code from the RAM, if I can execute it directly from the flash.

I thought, if I'm able to load the 3 hex files to the flash memory, I can load a 4th hex file, which given a specific input will run one of the 3 hex files at a time directly from the flash.

I'm using KEIL-MDK evaluation version and looking at the hex file, I can see that the starting/entry point of the code is 0x8000_00ED. So, I'm sure that all hex files will have the same entry point. 

In KEIL-MDK, If I changed the code memory area to start at a different location than 0x8000_0000 ( say 0x8000_0100 ), will this change the starting/entry point ? Will the bootloader start executing the code at 0x8000_0100 which maps to the RESET routine? Or does the bootloader, regardless of the entry point in the hex file, places the code starting at 0x8000_0000 ?

I hope I clarified what I want to do ... so, regardless of or with regard to using hex files, how can I  solve this problem ?

Thank you,

 Walid

[Tesla DeLorean]

Posted on May 17, 2011 at 14:22

The S19/HEX files are ASCII text files, so you can pretty much merge them with a text editor. With BIN files you'll have to make you own application/linker/loader to represent the entire flash footprint, and load the respective BIN files into their assorted position within that space, and then write that consolidated BIN file back out to another file.

The last record(s) in Motorola and Intel usually impart an entry point into the code just presented.

Provided each hex file uses a unique flash/ram address they should be able to operate independently.

You could write a hex loader that will load and execute code into RAM, you could also write them to FLASH but it gets trickier because of the way it blocks the processor if you execute from and write to FLASH at the same time. (USART latency issues)

Calling functions/code in different sections of memory is also relatively straight forward in either ARM/Thumb or C code. You might not want to call the main() functions directly for separately compiled C programs, as that could circumvent the C startup code that might be necessary to initialize your RAM based variables/statics, etc.

What type of help are you looking for? ST maintains a list of vendors who will write code for you.

[Andrew Neil]

Posted on May 17, 2011 at 14:22

Now cross-posted on the Keil forum: 

http://www.keil.com/forum/18281/

[Tesla DeLorean]

Posted on May 17, 2011 at 14:22

I hope I clarified what I want to do ... so, regardless of or with regard to using hex files, how can I  solve this problem ?

I wasn't really looking for a restatement of the problem, rather, what is precluding you from doing this?

At the moment it seems to be a problem with understanding the ARM and Cortex-M3 architecture and the STM32 specifically, and embedded development generally. Understanding how to load and call things in memory, and how to use the tools, or the documentation for them. Understanding how C startup code initializes memory, and the arena in which your main() functions subsequently run in.

The IRQ vectors can be remapped on a Cortex-M3.

The STM32 has specific booting addresses based on the BOOT0/1 pins.

The hex formats are well documented, and fairly simple to implement being based on late 1970's technology. Keil probably won't want to deal with your hybrid HEX files, so you'll probably need to use something like J-Flash or ST-LINK utilities (BIN), or write your own flash loader. In Keil, the way to handle the building of a combined hex file might be to implement a ''Post Link'' script/application.

You compile and link your code to run at the specific addresses you want.

You can direct Keil to use specific areas of RAM/ROM within the address space of your chosen device. I have suggested base addresses for your primary and satellite applications.

[itayk]

Posted on July 14, 2014 at 09:27

Hello,

I know this post is from a long time ago, but I have a follow-up on this subject.

I am currently working on STM32LVC on IAR.

What I am trying to do is to load 2 versions of software to different locations at the flash memory ( 0x08000000 and 0x08002000 ).

 

Now, can I just decide to start my program from a specific location? if I can, will I have to compile each program to its location?

Thanks,

waiting for replay..

[ivani]

Posted on July 14, 2014 at 13:44

The chip always starts from the address written on 0x08000004, so the part located at 0x08000000 will always start first.

But then it could of course jump on the second application at 0x08002000 (also relocating in parallel the ISR vector table to new location).

Each of the applications should be compiled for its address range and they could be ''glued'' together either by the linker, or by some external tool.

Generally, it is possible to compile them as position-independent code and also the vector table could be constructed in the RAM on the fly but there is no real need to do so.

[Tesla DeLorean]

Posted on July 14, 2014 at 13:56

You'd want to modify the project setting in each to reflect the base address you want the linker to use. I don't use IAR, but there is likely a page/setting, or .ICF file describing the memory map you want to use. These can then be confirmed by reviewing the .MAP file.

You can't control the boot address, so the first code to start would need to transfer control to other code locations. Review the assorted IAP examples for more ideas.

[jdcowpland]

Posted on March 13, 2015 at 12:20

Clive, in your post you mention: 

'

With BIN files you'll have to make you own application/linker/loader to represent the entire flash footprint, and load the respective BIN files into their assorted position within that space, and then write that consolidated BIN file back out to another file.'

This is exactly what I want to do with some binary files I've got. Rather than go and write my own application, I was just wondering if you (or anyone else) knew of an application that's already out there that might do the job?

Cheers!

[waclawek.jan]

Posted on March 13, 2015 at 12:35

>> 'With BIN files you'll have to make you own application/linker/loader to represent the entire flash footprint,

>> and load the respective BIN files into their assorted position within that space, and then write that consolidated BIN file back out to another file.'

> This is exactly what I want to do with some binary files I've got. Rather than go and write my own application,

> I was just wondering if you (or anyone else) knew of an application that's already out there that might do the job?

Clive told you that already above: ''application/linker/loader''

For a simpler (but still powerful and specialized in certain ways) tool, check out srecord.

JW