BIM for On-Chip OAD (Dual Image)

This section describes the behavior of the BIM for on-chip OAD where the dual image approach is used. This approach requires two full application and stack library pairs on the target device. As with off-chip OAD, it is BIM’s responsibility to locate which image should be run. In an on-chip dual image OAD system there are only two image areas stored at any moment:

  • Download application (0x00): Where the over-the-air image will be stored

  • Active application (0x01): OAD upgradeable application that implements OAD reset service and user functionality

For more information about OAD image types, refer to the OAD Image Header section of this chapter. The memory areas of each application in an on-chip system is defined in the Internal Flash Memory Layout section.

Both applications can be responsible for storing a candidate image in internal flash, performing all OAD procedures and protocols, updating the Image Validation flash field in the OAD image header, and resetting the device when appropriate. The Image Validation field is a shared RAM variable that allows the application to indicate which image should be selected by the BIM before resetting. This is described in Application Execution switching using Validation Bytes in Flash.

Based on the Image Validation field in the image header, the BIM will decide which image is most fit to run. The following will describe the process by which the BIM selects an image.

../_images/bim_sequence_diagram_onchip_stacklib.png

Figure 96. Functional Overview of On-chip BIM (dual image)

The image above is described in words below. In order to determine which image is best to run, BIM takes the following measures:

  1. At startup, the BIM checks the Image Validation field in the OAD Image Header and sets active flash page or image type based on Application Execution switching using Validation Bytes in Flash. If the Image Validation field is unset it will default to flash page of 0.

  2. BIM checks BIM_ONCHIP_MAX_NUM_SEARCHES to make sure the max search iterations have not been exceeded.

  3. BIM will now go through every flash page in the internal flash in search for a valid Image Identification value. This is done in the following way:

    • Read the first 8 bytes and compare to any valid image Identification value

    • If a valid image header is found, BIM will read the entire image header

    • If a header is not found, increment the flash page and search again (jump to step #2)

    This process is repeated until a valid image is found, or the max number of search iterations is reached.

  4. Checks that the header and BIM version are compatible with the current BIM.

    • If this check fails, increase the flash page number and search again (jump to step #2).

  5. If a CRC has not been calculated on the image, calculate one and update CRC status field.

    • If pending copy (stack image), do not update the CRC field yet, this will be done after copy

  6. Check for security.

    • Ensure image is from a trusted peer by running ECDSA sign/verify algorithm on the image.

    • If security check fails, increment the flash page and search again (jump to step #2)

    Note

    By default, BIM_DUAL_ONCHIP_IMAGE is defined in the BIM application. This means the BIM will also check the validity of the downloaded application before booting into it.

  7. Check for a valid CRC and image copy status in image header (0xFE).

    • Copy new user image, calculate CRC to ensure copy succeeded. Update copy status and CRC status fields accordingly.

    • If succeeded, set active application and flash page.

    • If failed, continue searching.

  8. Continue this process until an image is found or the max iterations (16 unsuccessful download attempts) is performed.

    • If a valid image is found, jump to it

    • If no valid image is found and the max iterations have been performed, go to low power mode.

Note

The execution flow described by the text and diagrams above is assuming security is on. If using an unsecured BIM configuration, the process is the same with the exception that there is no check for security.

Application Execution switching using Validation Bytes in Flash

In this scheme, BIM passes the execution based on the number of ‘0’ bits in the Image Validation field. If the number of ‘0’s bits are odd, it will execute download application and if the count is even it executes the user application.

By default, the Image Validation field in the image header will be set 0xFFFFFFFF. On power up, BIM will pass execution to the active application. When active application has finished uploading a new image, it has to switch the execution to the download application. To do this, the application flips the first available non-zero bit to ‘0’, starting from LSB in the ‘Image Validation’ field. Doing so will make the number of ‘0’ bits an odd number. The application should then perform a reset command.

After reset, the BIM will resume execution and check whether the count of ‘0’ bit is odd or even. Once it finds the odd count in the Image Validation field, the BIM will run the download application image (which is now the new active application). If new image downloaded and stored successfully, the ‘Image Validation’ field will be overwritten again to 0xFFFFFFFF and BIM will be able to execute the newly downloaded image. The old active application area will become the download application and the new active image will be authenticated.

If the authentication fails, active application that is already in flash should be re-validated. In the download app, this is handled by flipping the first available non-zero bit in the Image Validation field of the existing User Application OAD Image Header to ‘0’. This makes the number of nonzero bits even. The board then resets itself again. On startup, the BIM will check again whether the count of ‘0’ bit is odd or even. This time it will find that the number of nonzero bits is even, and the BIM executes the prior active application. This saves the user application from an unauthorized OAD attempt. The four bytes will allow the BIM to retry the execution switching process 16 times between active and download images without turning all bits to ‘0’s(16 unsuccessful downloads). When all the bits are set to ‘0’s, BIM will force low power mode.