This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Are dual application images possible?



Hello,

I have been using the F2808 for several years now, but have a new requirement for self-programming.  I can successfully self-program using the Flash APIs, but need to ensure power failure tolerance during the flash process.  The usual way to accomplish this is with a boot loader that never gets replaced. I am having difficulty supporting two separate application images on the MCU, e.g. boot loader in FLASHA and other code in FLASHB thru FLASHD as needed. 

Are there any app notes or examples of a similar configuration?

Any assistance or guidance would be greatly appreciated.

-Jess

  • Jess Murphy said:

    Hello,

    I have been using the F2808 for several years now, but have a new requirement for self-programming.  I can successfully self-program using the Flash APIs, but need to ensure power failure tolerance during the flash process.  The usual way to accomplish this is with a boot loader that never gets replaced. I am having difficulty supporting two separate application images on the MCU, e.g. boot loader in FLASHA and other code in FLASHB thru FLASHD as needed. 

    Are there any app notes or examples of a similar configuration?

    Any assistance or guidance would be greatly appreciated.

    -Jess

    Jess,

    We don't have an application note, but I can think of an example.  The boot code that we have in the boot ROM of the device can be thought of as one application.  When it exits it passes off control to the user's application.     In the boot ROM case the boot.asm that occurs before "main" is simplified and main() has been renamed.  This was done to save space in the ROM - this is not a requirement.

    Can you describe some of the difficulties you have faced?

    Regards,

    Lori

     

     

  • The issue is that I would like to use C to write both my permanent boot loader / verifier and my primary application image.  Ideally, they could share some common code, but that isn't mandatory.  I haven't been able to figure out how to get the C environment initialization worked out for both application images, let alone be able to verify the primary application image.  We have a SPI flash device, but I can't use that mode of booting due to existing board designs.

     

  • Jess,

    I'll let someone else answer the software side, but the hardware issue is more complex than you describe. The F2808 device uses a balanced sector flash architecture. This means that if the flash bits in sector D are left in a depleted state because power was lost during erase the image in sector A could be compromised. If you have to rely on booting from sector A, and there is a chance that power can be lost during erase, you shouldn't erase sector D. Likewise sectors B and C are balanced with each other.

    Regards,
    Dave Foley

     

  • David,

    Thanks for the advice.  I hadn't thought about the depletion.  Although this could occur, it is far more likely that power would fail while transferring the new image over a Bluetooth connection in my particular case.

    I had received a response from Tim King outlining how he had resolved a similar problem but that post has now gone missing. 

    Tim,

    How did you handle the C runtime initialization after branching from your boot loader to the validated image?

    Regards,

    -Jess

  • Sorry about the delete Jess, I have sent a personal message with some answers.

    Tim

  • Is this also true for the 2803x and 2802x devices?

    This would make the datasheet claim "The user can individually erase, program, and validate a flash sector while leaving other sectors untouched" a false one.

    In our application we also install a secondary bootloader in Sector A and this is used to validate the existing image in B- F and update an image from external serial flash or an ad-hoc in system serial protocol. If a power failure that occurs during programming can render Sector A "touched" then our system may fail under such conditions.

    I don't see in any data-sheet or app note the reference to "balanced" sectors. If there is a sector "balanced" with sector A, we may be able to avoid it. There may also be a mitigation by running the depletion check on every power up cycle. It would also be helpful to know whether this impacts the factory programmed bootloader or OTP.

    As to the OP's question, both a secondary bootloader and application can be easily programmed in C. Each must call the c startup code. Generally, however, it's a good idea to modify this code to initialize memory to zero in accordance with the C standard so a very small amount of assembly code is usually required. 

     

  • Wally,

    It does apply to the F2803x and F2802x devices as well. However, I'm not so sure saying the statement above is a false one is totally accurate. From a functionality standpoint the statement is entirely true. When talking about a power loss at the exact moment of erasing we are talking about a fault mitigation issue that different applications will treat differently. However, I understand there is not much documentation out there on this subject. It is something that TI is beginning to recognize and is working on ideas to better customer understanding on this topic.

    For the F2803x devices the following sectors are balanced (for 4 sector devices there is no balancing):

    Sector A is balanced with Sector H
    Sector B is balanced with Sector G
    Sector C is balanced with Sector F
    Sector D is balanced with Sector E

    For the F2802x devices the following sectors are balanced (for 2 sector devices there is no balancing):

    Sector A is balanced with Sector D
    Sector B is balanced with Sector C

    The OTP does not have a balanced sector on any of the 28x devices.

    The Boot ROM does not have a balanced sector on any of the 28x devices.

    Regards,
    Dave Foley

     

  • Thanks for your prompt reply.

    So as I now understand it, in order to rely on the content of Sector A surviving power failure during in-system programming, it is necessary to avoid erasing it's balanced sector H. In other words, a practical boot-loader would occupy both sectors A and H and use B-G for re-programmable system code. 

    If we avoid reprogramming sectors pairs A/H (or A/D on the 2802X devices), are there any other conditions during flash erase/programming that can be expected to routinely lead to failures if power is lost?

    Thanks

     

     

  • Wally,

    You understand it correctly. No other conditions.

    Regards,
    Dave Foley

     

  • Thanks

    It would probably be a good idea to highlight this characteristic in the flash api documentation. Also the appnote on using Flash to emulate EEPROM sprab69 probably should point this out as well since using that approach without pairing sectors could clobber the program.

    Cheers

  • Hi TI,

    I do agree with Wally that TI should share a little more information about flash sector balancing. I stumbled over this topic whilst looking for information why my flash might be destroyed during SW download. Somehow I have a bad stomach feeling by knowing this little something about sector balancing.

    Best regards

    Andreas