Hi,
I have a couple of executables [ while(1) {...} loop programs within a main() function ] generated ( hex or bin or s19 ; for simplicity lets say hex ) and I want to allocate each hex file at a specific starting address in the flash memory, so that in a main program I can jump to a specific starting address depending on the input to execute the present code.
1. Any help to solve this problem ? 2. Is there any way to merge these hex files together and then I can can jump to their specific location ?
Thank you, Walid Farid
-------------------------------------- More about the problem ------------------------------
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 ?
----------------------------------------------------------------------------------------------
P.S. : This question has already been posted on the STM32 forums
You shouldn't just mention the STM32 board but should post a link to the relevant thread.
Sorry, but it sounds meaningless to store multiple small applications like that.
Just have a small main() that looks at some GPIO signals to decide what to do:
function my_app1() { init1(); for (;;) { do_something1(); } } function my_app2() { init2(); for (;;) { do_something2(); } } function my_app3() { init3(); for (;;) { do_something3(); } } void main(void) { unsigned pins; pins = check_gpio_stimuli(); switch (pins & 0x03) { case 0: my_app1(); break; case 1: my_app2(); break; case 2: my_app3(); break; default: init_serial(); printf("Sorry - no such application\n"); } for (;;) ; }
The compilation time to build everything is no much longer than to compile one tiny app. The download time time is not much longer. The time saved from not having to jump between applications is well worth it. The ability to switch and run without reprogramming is well worth it. Too simple solution? Well, why make it more complicated than needed?
Well, the projects are not that simple to be all merged in one big project. We came across this idea, but loading multiple executables seemed to be more valid for what we wanted to do.
As I mentioned in my post, each project interfaces with specific peripherals on the development board and more often projects use the same sensors and same peripheral interrupt service routines. I think the one problem is due to the interrupt service routines and exception handlers which use the same address locations for each project. Can I change the vector addresses for each project ?
Is what I'm trying to do in general valid ?
The link for the post on STM32 forum is :
my.st.com/.../Flat.aspx
Thank you, Walid
The link is :
ttps://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/Multiple%20Executables%20on%20the%20STM32%20flash%20memory&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000626BE2B829C32145B9EB5739142DC17E¤tviews=50
Take a deep breath. You are trying to solve multiple problems with the wrong approach. You still did not make clear why you need separate binaries. If you do, you must probably use a bootloader of some kind. My project(s) use up to 4 components, but it has a good reason! Check out the ST material (application notes/user manuals) about remapping interrupt service routines. It sounds like you people have a number of parts that are foreign to one another, and you hope to glue them together by placing them on flash. That not how solid software is written and you skipped several stages anyway - how will these software components interact? You do realize that the last components to load will run in "user mode", while the previous ones will have to be executed by an interrupt service routine, unless you intend to explicitly jump around? Much better to have one application instead!
Probably not!
The whole point of a small embedded system is that it is dedicated to a single, specific, task.
If you have multiple, diverse tasks, it's probably better to just reprogram the target for each one.
Maybe you could adapt Per's suggestion, so that each of your projects is a Library - that way, each Library could have its own Project, and it would only be a very simple project to build them all into a single application...
ST are aware of the stupid links that their forum generates, but seem unwilling/unable to do anything about it.
:-(
In the meantime, here is a usable link: http://bit.ly/fRTi2u
If you would take the time to provide feedback to ST it might help to spur them into action: http://bit.ly/hho59Q
Most other web services specifically introduces friendly links, just because working links represents a very important investment in introduction of product/service to new customers.
"working links represents a very important investment"
I know that, you know that - but it appears to have escaped ST!
Hi Tamir,
The main reason I'm looking into this issue is because we have a development board with sensors A,B,C,D,E,F,G,H. We've 3 components; component (1) utilizes sensors A and B in some way and apply a specific algorithm, component (2) utilizes sensors C and D and apply a different algorithm while component (3) utilizes sensors E,F,G and H.
Now, each component is around 30 KB AND we've them already developed.
I don't want these components to interact. However, I want to use a 4th component, which according to a specific input will execute either component(1),(2) or (3). So, only one component will be running at a specific time. And when I reset the STM32, I can give a different input to jump to a different component depending on the sensors I want to use.
Yes, if I'm not able to work around having different components, I plan to have only one application. But, I'm still waiting for some suggestions for the multi-firmware option (if it is an option) .
It will take me some time to make a design that can merge the 3 components together. Isn't having 3 different components working in the described way much better than having a one big merged component, in the sense that you're sure that each component is working fine and if there is a buggy component, then you can work on fixing it.
So you're going to waste a huge amount of Flash space for the components that are not currently in use!
If that's really not a problem to you, then use a "bootloader" style of arrangement, where the bootloader decides which application to run.
See ST's application note AN2557 for a bootloader example Also http://www.keil.com/forum/16355/ and many posts on the ST forum...
Alternatively, why not store all the components on an SD Card (or similar), and have a more conventional bootloader that loads the required one into Flash, and executes it? To save re-Flashing when the required app is already loaded, you could provide some way for the bootloader to check what application is currently loaded - and its version...
Walid,
Save yourself a headache (even though you can learn a lot by doing what you were thinking of). Why not make one application with 4 functions or, alternatively - libraries, that represent the components you need to program. Then, in your program's startup you decide which function to execute based on the position of a jumper, an incoming serial message etc...done! Why make life harder when not necessary...?
Hi Andrew,
Wasting the flash space for the unused components is not a problem.
I have no problem with either having the components on the flash memory or an SD card. However, I think using the flash will give me the option to protect the code by applying the read-out protection from the flash. What are the other options beside the SD-Card ?
Regarding loading a specific component directly from the SD-card into the flash memory, as you mentioned, it seems that the SD-card gives us only one better option because no need for re-flashing after making changes to a specific component. However, it looks like the same process of trying to jump to a specific code in the flash still exists. Is there any other advantages for using the SD-card ?
Thanks for the link.
Thank you for the suggestion. I guess that the merging way is what I'll do at the end after having no other option. However, as I mentioned, these different components use sometimes the same interrupt service routines and so on, so they overlap. That said, merging them will take more time, as they are not just simple functions. So, I'll give it some time to investigate the other option and then will decide.
That is inherent in the nature of making a system that can support multiple applications!
IF you really want to proceed down this track then, to do it properly, you would have to do like "real" operating systems do and provide a "driver" layer that does all the direct hardware access.
You can totally avoid the issue by having just 1 application loaded at any one time!
Yes, of course it does!