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.

Backup Image with AIS



I am using a C6748 booting out of SPIFLASH, which will have its code field-upgradable. As this creates the possibility of the code becoming corrupted in flash, I would like to store a backup image that can be loaded if the primary image fails CRC. This backup image would provide minimal comms sufficient to recover and re-program a working primary image.

 

I would like to know if it would be possible to do this using AIS, or if a secondary bootloader should be used instead. My idea for accomplishing this in AIS would be this:

- construct an AIS script that loads a large chunk of data, say ~1MB, into memory, CRCs it, boots it if successful, and loads/boots the backup image if not.

- write the above into flash in the factory

- when doing a field upgrade, overwrite only:

   * the 1MB data chunk, padded out with 0x00 or 0xFF

   * the expected CRC

   * the entry point

 

The only problem I have with attempting to prototype this so far is that I cannot reverse-engineer the 9 different SECTION LOAD commands in the .bin file that AISGen creates from my .out file; I have identified where in the .out file they came from, but not why some sections were used but others were ignored, etc.

So, my questions are:

- Does this proposed solution seem plausable?

- If so, is there more documentation about how I can construct a monolithic memory image to be loaded into my "data chunk", using the .out file.

- If not, can you recommend a secondary bootloader solution (to be loaded via AIS in the normal fashion) that would satisfy my needs, or do you think it would be simple enough to write a custom one?

  • James,

    Unfortunately, the CRC mechanism in the ROM bootloader is too limited to support your proposed use case.  When a CRC check fails, the bootloader will try to load the same data again and again until it reaches a certain number of failed attempts, and then it will abort.  There's no way to specify an alternative section to try if the first one fails.  You will probably need to resort to a secondary bootloader to make this work.

    Regarding your .out/.ais differences: the AISgen utility is probably excluding sections in the .out file that are unused or zero-size.  It may also be collapsing contiguous groups of sections into a single "section load" AIS opcode.  Do you see any "missing" sections in the .out file that don't fit this description?

    Finally, "collapsing" your application to a monolithic block is a little bit trickier; you'll need to go beyond CCS and use some additional codegen utilities to pull this off.  I described one method in a wiki article aimed at people preparing secondary bootloaders for NOR execute-in-place boot mode.  You could use a similar procedure to create a bin file containing your application in some other memory space.  Then, you can include that binary data in your AIS image by using the file.bin@0x80000000 notation (substituting your own bin file name and loading address).  The app note has more information about that last step.

    Hope this helps.

  • Thanks for your reply Joe; the hex utility sounds like just what I need. I'll look into that.

    As for the CRC mechanism of AIS, it sounds to me like I can twist it to my needs if I were to generate the script myself instead of relying on AISGen. According to the bootloader manual, the Validate CRC command takes a "Seek" argument, which is an arbitrary offset at which to resume execution of AIS commands. If I were to point this at my backup image instead of back at the primary again, wouldn't that accomplish what I need?

  • James,

    That should be possible.  As you say, the AISgen tool can't create a boot image that does this for you.  You will need to:

    • Generate your own AIS file:
      • Normal (default) boot image is first
      • Alternative (backup) boot image comes after the first "jump and close" opcode
    • Compute your own CRC (the app note should help with this)
    • Use positive seek values to jump forward to the alternative boot image if CRC fails

    Figuring this out probably won't be much easier than writing a secondary bootloader. :)