We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have created a image relocation scheme where my boot loader can load an image into one of several positions in the flash and execute them individually. This involves remapping the IVT from that created by the compiler/linker so that the processor jumps into the correct relocated isr positions. Now, here is the problem I have come up against. I need the boot loader to jump into the new located code. I initially thought it would be okay to just take the reset vector (with the location offset added) out the IVT and jump to that. The only problem I found is that this jumps to a load of scatter file initialisation code that does not appear to use relative addressing and jumps back to the boot loader code. I have managed to get the boot loader to jump directly to main (using hard coding) and this works beautifully, all the routines appear to be using the correct relative branches and jumps. But the main address moves around depending on the image content and needs to be obtained and passed in to the boot loader for it to work, which could be done by getting it placed into an image header but is a little clumbsy, requiring use of FROMELF and some other post linker scripting as well as the header decoding at the other end. So my question is.. how can I get the Keil compiler to set the main address into the reset part of the vector table? Or how can I program the reset isr to jump direct to main with out it calling all this initilisation stuff? Or can I just take out the initialisation, if so how? Hope there is enough but not too much detail there for me to make sense.
why is it fundamentally wrong? what is supervisor mode? Not sure what you mean by getting the bootloader execute the SWI. Sorry you have lost me here totally. Perhaps you misunderstand what I am doing, my bootloader will remap during the image load process, it does not relocate anything in its IVT, that would be very difficult. On reset the bootloader would do all the ordinary reset stuff and end up in its main routine which would decide which image to jump to, it knows the image positions but not their main start address. It can obtain their reset vectors but not their main address.
..each image, including the boot loader has their own IVTs.
I did understand you and as I said, you are violating one of the foundations on which an ARM processor (not an M3 - don't know that one yet) is based. you cannot setup the different modes stacks when in user mode - in user mode, only the condition flags of the CPSR (CPSR_f) can be changed. In other modes, the entire CPSR can be changed. I suggest you read a little bit about an ARM processor and then apply what I have written above. You don't have to, but it is advisable to do the remapping from within the target application itself.
I'm using an M3. Don't know about other ARMs but this allows the resetting of the stack and the IVT pointer before jumping into a new image. The IAP_AN example supplied by ARM does the stack stuff i.e. /* Initialize user application's Stack Pointer */ __MSR_MSP(*(vu32*) ApplicationAddress); does this mean I'm still violating one of the foundations? The jump actually works, so I can't be that wrong.
sorry should have said it is resetting the IVT pointer in the new images main.
Is there any one out there who knows about the M3 that can answer my questions? It is a STM32F103xx.
Hello Master MARK.
i know the m3 and i understand the problem. the m3 is diferrent to the old arms. you wait and see if i can find the answer. plz wait.
always yo're freind.
Zeusti.
Hello Master MARK
does that make you a slave?
Sorry, you have lost me there???
Mark, I was teasing the renowned professor Zuesti or whatever his nickname is. Why all know him around here...
Ah, good I understand. Does he normally give good advice?
Tapeer.
have you read the abi yet? understand now?
Always yo're freind.
I believe his reply of a minute ago (more or less) as well as his posting style speak for themselves. I hope he does surprise us, though.
I have never tried this, but here is an idea:
Create a scatter file shared by all images, which will ensure common entry point and vector table addresses.
Build the images with --apcs=/ropi. Position independent data is not necessary, since I take it you will be running only one image at a time.
Install image at known address initialize stack pointer from new vector table as well as the vector table itself and branch to image entry point.
Regards Marcus http://www.doulos.com/arm/
marcus beet me to the response. but he has a good sugestion.
(success rateing now fallen to 100%-1)
Thanks I think the scatter file is just the default for the processor type and will be common. Where exactly do I put --apcs=/ropi, you are right about the images running OAAT. "..branch to image entry point" There's where it goes wrong because the only address I can currently get my hands on is the "reset vector" which in turn calls misbehaving scatter file routines (call absolute addresses). Are you perhaps saying that inclusion of the --apcs=/ropi will make these scatter routines behave? All I want to do is just jump straight to main, therefore missing out the scatterfile stuff. So I want to be able to assign the image IVT with the main address instead of the reset routines.