Boot Image Manager (BIM)

The Boot Image Manager resides on the OAD target, and is responsible for loading new images after a download has completed. The BIM executes on a device reset and determines if a firmware update needs to be applied. If no update is being applied, then the BIM will transfer program execution to the main application image.

Overview & Software Architecture

BIM is a fully executable application that is independent of any high level protocol stack or user application. It is guaranteed to run on boot. BIM enables power loss fault tolerance during OAD. If the device power is lost during OAD, the BIM will still be able to run from reset and revert to a working image if one is available. The BIM is intended to reside permanently on the chip and cannot be updated via the OAD process.

BIM executes before kernel initialization takes place so the design is single threaded and bare metal. Hardware access is accomplished through driverlib.

As a separate application, BIM requires its own interrupt vector table and linker file. It will produce a fully executable image that must be merged with the user application image in order to create a functional OAD enabled firmware system.

In general, BIM is responsible for finding and analyzing OAD image header. From a high level BIM does the following:

  1. Check for newly downloaded images from a recent OAD.
  2. If available, copy the newly downloaded images to their target location in internal flash
  3. Dynamically locate the entry point of the valid image and jump to it

The following section will cover the BIM boot procedure and image checking routine in detail.

Boot procedure

On reset, the software in the ROM of the CC26x2 will execute basic startup routines, and then jump to the location pointed to by the CCFG’s IMAGE_VALID_CONF field. More information about the fields of the CCFG and the generic device boot procedure is detailed in the CC26x2 Technical Reference Manual. The BIM is setup to link the CCFG as part of its image. This is another failsafe mechanism to ensure that a CCFG is always present on the device. To enable this feature, BIM uses a custom CCFG where the value of the IMAGE_VALID_CONF field points to BIM’s reset vector table. More information about the CCFG and the IMAGE_VALID_CONF is available in the CC26x2 Technical Reference Manual.

In summary, the boot ROM code will jump to the ResetISR() in BIM’s vector table. Being a bare metal application, BIM uses the toolchain specific boot code provided in driverlib.

The reset ISR code can be found in driverlib under the startup folder. In summary, it performs the following:

  1. Device specific trim functionality
  2. C/C++ runtime initialization
  3. Jump to BIM’s main()

See the figure below for a graphical representation of the boot procedure. Red boxes indicate driverlib/ROM code, blue boxes represent BIM code.

../_images/ditaa-8ff04d5504ffde0e0ea788397cdac6fc29615772.png

Device trim

The device trim function is responsible for tuning hardware settings of the device to ensure stable and optimal operation. It must run at least once every time the device boots, but may be ran more than once. Parts of the trim function are dependent on the CCFG which is another reason why it is linked with BIM.

By default, both BIM and the user application will trim the device.

This offers the benefit that the user application may link to a newer version of the trim function. This comes at the cost of a small amount of additional flash in the user application.

Warning

It is recommend to leave device trim enabled in both the BIM and the user application to enable development via a debugger without a BIM present.

Removing the device trim for the user application is only suggested for final production code. Additional validation should be performed on images with additional trimming disabled. App level trimming can be disabled by modifying the Boot module within the kernel’s *.cfg file.

Locating and Preparing a user application

Besides booting and trimming the device, BIM’s primary functionality is to find and prepare a user application to run on the CC26x2.

BIM for Off-Chip OAD

At steady state, the normal case is that a valid image exists in internal flash and no image in the external flash has been marked as needing to be copied. In this case, BIM will validate that the image on internal flash and execute it by loading the stack pointer and jumping to the image’s reset vector location. BIM determines the location of the reset vector and stack pointer of the image through the OAD image header attached to it.

Note

As a convention, the vector table comes immediately after the image header in OAD enabled images. The BIM and the image header are tightly coupled, refer to the OAD Image Header chapter for more detail on the image header vector and its fields.

@startuml (*) --> "Device Boot" If "Unchecked images on external flash?" then --> [Yes] "Read header from external flash" If "Header valid?" then --> [Yes] "Copy image to internal flash" If "Copy and CRC succeeded?" then --> [Yes] "Jump to image" -->(*) else --> [No] "Check image on internal flash" Endif else --> [No] "Check image on internal flash" Endif else --> [No] "Check image on internal flash" If "Image valid?" then -left-> [Yes] "Jump to image" else --> [No] "Revert to factory image" If "Revert succeeded?" then --> [Yes] "Jump to image" else --> [No] "Spin lock" --> "Spin lock" Endif Endif Endif @enduml Functional Overview of Off-chip BIM

Figure 85. Sequence diagram for BIM image selection process

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

  1. At startup, BIM looks for a valid image header in external flash by reading the first 8 bytes to find the valid External Flash Image Identification value.

  2. After a valid header is found, it reads the entire header from ext flash and verifies the compatibility of BIM and image header versions. Then it checks if the ‘Image copy status’ is set to be copied to the on-chip flash(0xFE) and has a valid CRC (CRC status=0xFE).

    • If it finds status ‘CRC not calculated’(CRC Status = 0xFF), it calculates the CRC of the external flash contents and updates the CRC status byte in the external flash.
    • On finding the invalid CRC it moves on to read the next image’s header.

  3. If a valid image is found, BIM copies the image to on-chip flash, as per the image copy procedure.

    • After the copy, the CRC is re-checked on internal flash to ensure the copy succeeded.
    • If the copy failed the status byte is updated and the bim will continue searching external flash.
    • If the copy succeeded, then the BIM will jump directly to the application image, and the search process ends.
  1. If BIM reaches the end of the image header region in external flash without finding a valid image, then it will try to find an on-chip image and execute it.
  2. If BIM fails to find a valid image internal flash, it will attempt to revert the factory image if there is one present.
  3. BIM will put the device to low power mode if it fails to find a valid application image.

Note

An image is considered bad/invalid if it’s calculated CRC32 does not match the image’s CRC bytes embedded in the image header.