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
Hard to read with posts in the middle. This is a threaded forum without the tree. Not sure why they introduced just one half of the minimum requirements for a threaded forum.
Anyway - some processors have a great VIC that allows a vector (address of ISR handler) to be programmed directly into the interrupt controller. Some does not.
But it is possible to create stub interrupt handlers that calls a function pointer to the real implementation. A bit slower but in many situations, the requirements does not need 100% maximum performance out of the processor. In some situations, the interrupt routing can be done in the assembler startup file to minimize the amount of double-saves from first saving a large state before entering an ISR and then saving even more registers before entering a standard C function.
The ARM compiler supports C++. This means that the functions and variables can be hidden in namespaces to avoid colliding names. This concept obviously only works if the target has enough RAM for all global variables for all sub-applications. If it doesn't, then some poor soul may have to move the global variables for each application into a struct, and then place the multiple structs into a single union (or maybe allocate dynamically on startup), so the code in main supplies a pointer to a struct of the correct type.
Life is definitely easier if the globals fits at the same time - maybe just manually create optimized declarations for larger buffers to let them overlay each other depending on what target sub-application that gets started. In real life, a few variables tends to consume the majority of the RAM while all other variables are tiny char, short and int variables.
If the applciations aren't huge, and you are skilled in the use of one of the better programming editors, you could convert even non-trivial applications into becomming sub-applications with reasonable amount of work.
One interesting thing with multiple applets run from a common main - if one produces output data that needs to be further processed, it could even be possible to run the applets in sequence as a form of pipelined filter.