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 CC2640R2 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 CC26xx 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 CC26xx 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-237b15ca35f8f8e08d20a016aa273d25ac485fb2.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 function is to find and prepare a user application to run on the CC2640R2. The method by which this is performed depends on the type of OAD that is being done (i.e. on-chip or offchip). Please the following sections for each platform.

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.