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

Code Loader - Jumping to Compiler Startup Code

Hello,

AN112 provides three different methods for code loader designs.

However, we are considering having our Code Loader jump to the compiler's C_C51Startup function of our Main Application instead of its Main function. This would allow us to leverage the functionality that the compiler's startup code provides (clearing data; initialization of globals, statics; setting stack pointer; etc.).

Also, our Code Loader (and many others) never needs to run after it passes control to the Main Application. So we believe that we would not need to ensure that the data areas for the two applications do not overlap.

These two ideas seem to work well together. The C_C51Startup should ensure that the data area is initialized before the Main function of the Application runs even if it overlaps the data area of the Code Loader.

Are there any problems or drawbacks in the Code Loader jumping to the Application's C_C51Startup function and having the data areas of the Code Loader and Application overlap? It seems simpler and safer to us.

Parents
  • So, my question is with regards to the best/safest way to jump from the Boot Loader to our Main Application
    NOT TO JUMP, BUT TO LET THE WARCHDOG TIME OUT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Can I safely ignore his posts or am I missing something?
    You, as anyone else can choose to "ignore his posts" but what is your resistance to doing the right thing? letting the watchdog time out is dead simple.

    If you absolutotally have to 'jump' then do as follows:
    get a hold of the lkist of SFRs in your chip, run a routine that reset them all to the reset value and then jump to startup. in that routine you may find some 'surprises' if the initializatrion is not done in the right order, but with a couple of weeks of work you can probably ghet it to where only one miss will be discovered after you have released the product.

    Silicon Labs suggests the Main function
    try it and WEEP. all SILabs code is 'tested' as is and when you use it in any other way you WILL find the bugs.

    Erik

Reply
  • So, my question is with regards to the best/safest way to jump from the Boot Loader to our Main Application
    NOT TO JUMP, BUT TO LET THE WARCHDOG TIME OUT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Can I safely ignore his posts or am I missing something?
    You, as anyone else can choose to "ignore his posts" but what is your resistance to doing the right thing? letting the watchdog time out is dead simple.

    If you absolutotally have to 'jump' then do as follows:
    get a hold of the lkist of SFRs in your chip, run a routine that reset them all to the reset value and then jump to startup. in that routine you may find some 'surprises' if the initializatrion is not done in the right order, but with a couple of weeks of work you can probably ghet it to where only one miss will be discovered after you have released the product.

    Silicon Labs suggests the Main function
    try it and WEEP. all SILabs code is 'tested' as is and when you use it in any other way you WILL find the bugs.

    Erik

Children
  • I think you may not understand my question (or I am not understanding your responses). We have two different applications in flash. On reset, our Boot Loader will run and normally (if an Application update is not required) jump to our Main Application.

    NOW I get it, I would never expect anyone to default to running the bootloader.

    you are, in my opinion, doing it backwards.

    think about doing this: On reset, our Application will run and if an Application update is required set the required flag or whatever that will invoke the bootloader and do a FULL reset. When the bootloader is done it will reset the required flag or whatever that will invoke the bootloader and do a FULL reset.

    This way there will be no 'interaction'

    the "flag or whatever" must, of course, be non-volatile.

    Erik