BIM for On-Chip OAD (Stack Library)

This section describes the behavior of the BIM for on-chip OAD where the combined 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 OAD system there are only two image types that can be executed safely:

  • Persistent application (0x00): Permanently resident application that implements OAD profile

  • User 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 roles and responsibilities of each application in an on-chip system is defined in the TI 15.4-Stack OAD section.

In summary, the applications are 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 90. Functional Overview of On-chip BIM (stack library)

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 and image type of user application.

  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). If user application, change image type so that the BIM boots into to persistent application before searching again.

  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, AUTHENTICATE_PERSISTENT_IMG is defined in the BIM application. This means the BIM will also check the validity of the persistent 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 image type to persistent application and set flash page number to 0.

    • 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 persistent 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 user application. When user application wants to upload a new image, it has to switch the execution to the persistent 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 persistent application image (which is initiated by the user application). The persistent application will start downloading and the new user image will be authenticated. 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.

If the authentication or the ‘Image Identify’ command (see OAD Messages for details) fails, user application that is already in flash should be re- validated. In the persistent 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 user 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 user and persistent image without turning all bits to ‘0’s(16 unsuccessful downloads). When all the bits are set to ‘0’s, BIM will always jump to persistent image forcing the user to upgrade the user application.