This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How can I get the reset vector to jump straight to main

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.

Parents
  • > I think the scatter file is just the default for the processor type
    > and will be common.

    You may have to come up with your own.

    > Where exactly do I put --apcs=/ropi, you are right about the images
    > running OAAT.

    Add this to the compiler options. And, BTW, according to the docs
    there are supposedly some limitations with Microlib. Just a heads up.

    > Are you perhaps saying that inclusion of the --apcs=/ropi will make
    > these scatter routines behave?

    It should, indeed.

    > All I want to do is just jump straight to main, therefore missing
    > out the scatterfile stuff.

    I don't think you want that.

    > So I want to be able to assign the image IVT with the main address
    > instead of the reset routines.

    But nobody cares what the address of your reset slot in the new
    vector table is. It'll never be used anyway. If a reset occurs, it
    takes down the vector table offset register and the boot loader vector
    table will be used again.

    Regards
    Marcus

Reply
  • > I think the scatter file is just the default for the processor type
    > and will be common.

    You may have to come up with your own.

    > Where exactly do I put --apcs=/ropi, you are right about the images
    > running OAAT.

    Add this to the compiler options. And, BTW, according to the docs
    there are supposedly some limitations with Microlib. Just a heads up.

    > Are you perhaps saying that inclusion of the --apcs=/ropi will make
    > these scatter routines behave?

    It should, indeed.

    > All I want to do is just jump straight to main, therefore missing
    > out the scatterfile stuff.

    I don't think you want that.

    > So I want to be able to assign the image IVT with the main address
    > instead of the reset routines.

    But nobody cares what the address of your reset slot in the new
    vector table is. It'll never be used anyway. If a reset occurs, it
    takes down the vector table offset register and the boot loader vector
    table will be used again.

    Regards
    Marcus

Children
  • >But nobody cares what the address of your reset slot in >the new
    >vector table is. It'll never be used anyway. If a reset >occurs, it
    >takes down the vector table offset register and the boot >loader vector
    >table will be used again.
    No I care because the reset vector is what the boot loader reads from ( from the new image ) before jumping to that entry point. It does not have to be the reset vector it could be any of the vectors that is not used, i just use it as a entry point holder for the boot loader ( or infact the other images ) to use for their jump into it. Um, other vectors, now theres an idea!!!

  • > No I care because the reset vector is what the boot loader reads from
    > ( from the new image ) before jumping to that entry point.

    That's what I meant. It is not used as actual Reset address, so you
    can use it for anything you like.

    Regards
    Marcus
    http://www.doulos.com/arm/