Over the Air Download (OAD)

This section serves as a guide to the Texas Instruments Over the Air Download (OAD) ecosystem including the profile, application architecture, drivers, and middleware. OAD allows the firmware image running on a BLE device to be updated in the field without the need for wires or debuggers.

The guide will cover the princles of the OAD process, the out of the box demos included in the SimpleLink CC13x0 SDK, and the process for adding OAD to an existing project.

Note

The BLE-Stack OAD Profile does not implement or perform any security or authentication mechanisms as part of the firmware update process. System developers should take measures to adequately authenticate peer devices and only accept and/or apply firmware images transferred from trusted sources via the OAD Profile. TI recommends applications use Bluetooth LE Secure Connections (LESC) with Man-in-the-Middle (MITM) protection with peer devices when performing wireless firmware updates, although the use of the LESC feature does not itself guarantee image authenticity.

Scope

The OAD guide section will cover:

• OAD theory of operation
• How to run the OAD demos included in the SimpleLink CC13x0 SDK
• How to add OAD to an existing sample application

The supported development kit for OAD is the CC13x0 LaunchPad.

Warning

This guide assumes that both the OAD Target and the OAD Downloader are running on the CC13x0 LaunchPad. Two CC13x0 LaunchPad devices are required to follow this guide.

Read this Section First

OAD Concept Overview

This section aims to explain the major concepts involved in the OAD process from a high level. The concepts here will be expanded on further in the following sections. Some concepts, such as the Boot Image Manager (BIM) may vary in their implementation details. Wherever possible, the concepts will be covered in this chapter with their implementation details covered in the following chapters.

OAD Types

There are two methods of performing an over the air download: On-chip and Off-chip. The key difference between the two methods is where the downloaded image is to be stored during the OAD. In On-chip OAD, the downloaded image is written to internal flash, allowing for a single chip OAD solution. Off-Chip OAD stores the downloaded image in an external flash part, requiring a two chip OAD solution. Figure 70. shows a comparison of different OAD methods. Each type of OAD has associated tradeoffs and benefits which will be discussed in their respective sections. Despite their differences, both OAD methods share the same over the air profile and metadata vector described in this section

Figure 70. OAD Types Overview

OAD Topology Overview

Two BLE capable devices are required for performing an OAD. The terms for the devices involved in an OAD exchange are listed below:

• OAD Target
• OAD Downloader

OAD roles are independent of the GAP role; they are dependent on which device exposes the OAD service. The OAD Target is always the device that runs the OAD service (GATT server), and the OAD Downloader is always the device that consumes the OAD service (GATT client Figure 71. shows a graphical relationship of the devices required for an OAD transfer.

Figure 71. OAD Downloader and Target

All provided TI example applications (BLE Device Monitor, mobile applications, etc.) are implemented such that the OAD Target is a peripheral device, and the OAD Downloader is a central device. For this reason, other configurations are outside of the scope of this document.

OAD Image Metadata

There are many points in the OAD process where information must be gathered about images. This information can be used by the OAD service to determine whether or not an image is acceptable for download or by the bootloader to determine which image should be run. In order to prevent this information from being calculated multiple times and to assist in the linking process, all TI OAD images use a standard 16-byte metadata vector. This metadata vector is embedded at the beginning of the image, occupying the first 16 bytes before the application code. This section aims to explain the various fields within the metadata vector and what they mean. The following sections will describe how each field is used specifically for On-chip and Off-chip OAD.

Most metadata checking is done in OADTarget_validateNewImage().

Table 17. below shows a description of the metadata vector.

Table 17. Description of the metadata vector.

Field	Size (in bytes)	Description
CRC	2	Cyclic Redundancy Check
CRC Shadow	2	Place holder for CRC
Version	2	Version
Length	2	Length of the image in words*
UID	4	User Identification
Start Address	2	The destination address of the image in words*
Image Type	1	The type of image to be downloaded
State	1	The status of this image

Note

The above fields that are marked with an asterisk * are measured in 32-bit words. For example, an image length of 0x100 describes an image that is 1024 bytes in size. This OAD word size is defined by EFL_OAD_ADDR_RESOLUTION for off-chip OAD and by HAL_FLASH_WORD_SIZE for on-chip OAD.

CRC and CRC Shadow

The cyclic redundancy check (CRC) is a means to check the integrity of an image. This must be done in two steps. First the CRC must be calculated when the image is generated from the toolchain, this will be stored in the CRC field within the metadata vector.

This initial CRC will be sent over the air via the OAD service (see OAD Service section). Later, the target will need to ensure that the image has not been corrupted during transfer. The target will then re-calculate the CRC of the downloaded image; this will be stored in the CRC shadow field of the metadata vector.

If the CRC and CRC shadow are equivalent, the target can assume that the image was not corrupted while sending over the air.

The algorithm selected for CRC calculations is the CRC-16-CCITT, it is a 16 bit CRC calculation that boasts a 99.9984% error detection rate in the worst case.

Version

The image version field is used to track revisions of images and ensure upgrade compatibility. Customers may implement their own versioning scheme; however, there are additional checks imposed by the TI OAD profile. See the function OADTarget_validateNewImage() within oad_target_external_flash.c or oad_target_internal_flash.c how these version checks are done in Off-chip and On-chip OAD, respectively.

Length

The length field is the length of the image in words, where the word size is defined by EFL_OAD_ADDR_RESOLUTION and HAL_FLASH_WORD_SIZE for On-chip and Off-chip OAD respectively. Off-chip OAD customers who are using different external flash parts may need to modify EFL_OAD_ADDR_RESOLUTION to match the word size of their part. For On-chip OAD, the word size of the CC13x0 is fixed.

User Identification (UID)

This field is un-used by the TI OAD profile, but the hooks are in place for a customer to add their own implementation of verifying images based on UID.

For on-chip OAD, the convention is that Image A will embed ‘A’, ‘A’, ‘A’, ‘A’ and Image B will embed ‘B’, ‘B’, ‘B’, ‘B’. off-chip images use ‘E’, ‘E’, ‘E’, ‘E’ by default.

Start Address

The start address is the first address where the proposed image is to be stored in internal flash. Similar to the length field, this is calculated in words. Off-chip OAD solutions put restrictions on the start address based on image type (more on this in the next section).

Note

For On-chip OAD solutions, this field is reserved in the metadata as they use a fixed start address that is based on the internal flash memory map.

Image Type

In Off-chip OAD systems with external flash, there are multiple types of images that can be uploaded. These image types include:

• App + Stack
• App only
• Network Processor
• Stack only

Warning

While stack only upgrades are possible, the user must be sure that the App/Stack boundary has not changed between the resident OAD image and the proposed OAD image. Since there are no runtime checks on the App/Stack boundary, a Stack only OAD will overwrite the resident application if the boundary has grown. Users should exercise care when using this option.

If a boundary change is required (i.e. stack is growing or shrinking), it is required that a user perform a merged update (App+Stack) to ensure that the OAD image is ready to run.

Note

On-chip OAD solutions determine this image type based on the LSB of the image version field. The image type field is not used (reserved for future use).

The supported image types are listed below:

Table 18. Off-chip OAD Image Types.

Image Type	Value	Description
EFL_OAD_IMG_TYPE_APP	1	An application or application + stack merged update
EFL_OAD_IMG_TYPE_STACK	2	A stack only update
EFL_OAD_IMG_TYPE_NP	3	A network processor update. This only applies to the SimpleAP + SimpleNP demo
EFL_OAD_IMG_TYPE_FACTORY	4	Describes the permanently resident production image that runs on the device before any OTA updates.

Image State

The image state is a one byte metadata field that is used only by Off-chip OAD solutions. The state informs the bootloader whether or not the image is ready to run or currently running. This prevents the bootloader from copying the same image from external to internal flash on every boot.

Note

For On-chip OAD solutions this field is reserved in the metadata as the OAD reset service handles switching between images in the bootloader.

OAD Service

The OAD service has been designed to provide a simple and customizable implementation for the customer. In its most rudimentary form, this service is responsible for accepting/rejecting an OAD interaction based on image header criteria, storing the image in its appropriate location, and causing a device reset if the download is successful so that the downloaded application image is run by the BIM.

A screenshot of BLE Device Monitor displaying the OAD service is shown below:

Figure 72. OAD Service Overview

The OAD service is a primary service with four characteristics. The characteristics of the OAD service, their UUIDs, and descriptions are listed in Figure 72.

Note

The characteristics use the 128-bit TI base UUID of the format F000XXXX-0451-4000-B000-000000000000 where XXXX is their shortened 16bit UUID. For brevity, this document will refer to the characteristics by their 16-bit short UUID.

Table 19. OAD Service Description.

UUID	Name	Description
0xFFC0	OAD Service	OAD service declaration
0xFFC1	Image Identify	Used to send image metadata over the air so that the OAD Target device can determine if it should accept or reject the proposed image
0xFFC2	Image Block	Actual block of image data along with offset into the image.
0xFFC3	Image Count	Number of complete images to be downloaded in the OAD session
0xFFC4	Image Status	Status of current OAD download

The primary method for sending data from the OAD Downloader to the OAD target is the GATT writes with no response message. GATT notifications are the primary method used to send data from the target to the downloader. This communication scheme was selected to prevent the target device from having to include the GATT client code required in order to receive notifications from the downloader. The OAD Downloader shall register for notifications from any characteristic with a CCCD (by writing 01:00 to the CCCD).

Note

Both GATT notifications and GATT write with no response are non-acknowledged message types. There is an inherent tradeoff between the speed of the OAD process and its reliability. Implementing a reliable OAD communication protocol (with retries, acknowledgments, etc.) is outside the scope of this document.

For a message sequence chart describing the OAD process in terms OAD service messages exchanged between the target and OAD Downloader please see Figure 76..

OAD Image Identify (0xFFC1)

The Image Identify characteristic is used to exchange image metadata between OAD Downloader and target. The OAD process begins when the OAD Downloader sends the 16 byte metadata of the proposed OAD image to the target. Upon receiving the candidate metadata, the target will do some calculations to determine whether or not the proposed image should be downloaded. “01:00” shall be written to the CCCD of this characteristic so that notification for metadata rejection is enabled.

Note

The conditions under which an OAD is accepted vary slightly between the on and off-chip methods. Please see OADTarget_validateNewImage() in oad_target_external_flash.c for off-chip OAD and oad_target_internal_flash.c for on-chip OAD. These functions implement the image reject conditions.

If the target accepts the image it will continue the OAD process by sending a notification on the Image Block characteristic requesting the first block. Otherwise the target will reject the image by sending back a portion the currently resident image’s metadata. The reject metadata contains the Image Version, Image version, and User ID fields. For more information about these fields, please refer to the metadata section.

A sniffer capture of the image identify characteristic being used to reject a candidate OAD image is shown below. Note that only image version, length, and user ID are contained in the reject notification.

Figure 73. Reject Notification in Sniffer Capture

Alternatively, a successful OAD initiation is shown in below:

Figure 74. Successful OAD Initiation Sniffer Capture

OAD Image Block Characteristic (0xFFC2)

The OAD Image Block characteristic is used to request and transfer a block of the OAD image. “01:00” shall be written to the CCCD of this characteristic so that notification for block request is enabled. The target requests the next block of the image by sending a GATT notification to the OAD Downloader with the requested block number. The OAD Downloader will respond (GATT write no response) with the block number and a 16 byte OAD image block. The image block contains the actual binary data from OAD image offset by the block number. Figure 75. shows a block request/response sniffer capture.

Figure 75. Block Request/Response Sniffer Capture

In Figure 75. above, the block number field is 2 bytes (little endian) and highlighted in red. The OAD image block is 16 bytes and highlighted in purple.

OAD Image Count Characteristic (0xFFC3)

The OAD Image Count characteristic is used to set the number of OAD images to be downloaded. This is used for only Off-chip OAD and the default value of the characteristic is 1. Note On-chip OAD only supports one image download per session.

OAD Image Status (0xFFC4)

The OAD image status characteristic is used to report various failures that may occur during the OAD process. The OAD Downloader may use this information to determine why an OAD failed, so that it may correct for the errors and try again. “01:00” shall be written to the CCCD of this characteristic so that notification for status update is enabled. There are four OAD status messages that are defined by default. The OAD status codes are listed in the table below:

Table 20. OAD Status Codes

OAD Status Code	Value	Description
OAD_SUCCESS	0	OAD succeeded
OAD_CRC_ERR	1	The downloaded image’s CRC doesn’t match the one expected from the metadata
OAD_FLASH_ERR	2	The external flash cannot be opened
OAD_BUFFER_OFL	3	The block number of the received packet doesn’t match the one requested. An overflow has occurred.

The customer may extend these values as needed, and use the OAD_sendStatus() function to send updates to the downloader.

OAD Reset (0xFFD1)

The OAD reset is accomplished by invalidating Image B, which forces the bootloader to revert to Image A until another successful OAD of Image B has occurred. Image B is invalidated by corrupting its CRC. After the corruption, the reset service immediately invokes a HAL reset to jump to the bootloader. Note that a GATT write of any value to the reset service will trigger a reset of the device/invalidation of Image B.

OAD Process

This Profile has been designed to provide a simple and customizable OAD Profile for the customer. In its most rudimentary form, for both On-chip and Off-chip OAD, this profile is responsible for accepting an OAD interaction based on image header criteria, storing the image onto the flash and causing a device reset if the download is successful so that the downloaded application image is run by the BIM. OAD Downloader and OAD Target perform Client role and Server role respectively.

Initiation of the On-chip OAD Process

After establishing a new connection, updating the connection interval for a faster OAD and enabling notifications of OAD Image Identify and OAD Image Block characteristics on the OAD Target, the OAD Downloader shall write to the Image Identify characteristic of the OAD Target. The message data will be the header retrieved from the OAD Image available for OAD.

Figure 76. Sequence diagram for OAD process

Upon receiving the write request to the Image Identify characteristic, the OAD Target will compare the image available for OAD to its own running image. By default, only the image size and version number, which implies whether the image is of type A or B, are checked to determine if the new image is acceptable to download.

If the OAD Target determines that the image available for OAD is acceptable, the OAD Target will initiate the OAD process by notifying the Image Block Transfer characteristic to the OAD Downloader requesting the first block of the new image. Otherwise, if the OAD Target finds that the new image does not meet its criteria to begin the OAD process, it shall respond by notifying the Image Identify characteristic with its own Image Header data as sign of rejection. In that case, the OAD procedure will end at the moment where dotted ‘X’s are placed as depicted in Figure 76..

Image Block Transfers

The Image Block Transfer characteristic allows the two devices to request and respond with the OAD image, one block at a time. The image block size is defined to be 16 bytes – see OAD_BLOCK_SIZE in oad.h. The OAD Target will request an image block from the OAD Downloader by notifying the OAD Image Block characteristic with the correct block index. The OAD Downloader shall then respond by writing to the OAD Image Block characteristic. The message’s data will be the requested block’s index followed by the corresponding 16-byte block of the image. Whenever the OAD Target is ready to digest another block of the OAD image, it will notify the Image Block Transfer characteristic with the index of the desired image block. The OAD Downloader will then respond.

Completion of the On-chip OAD Process

After the OAD Target has received the final image block, it will verify that the image is correctly received and stored by calculating the CRC over the stored OAD image. The OAD Target will then invalidate its own image and reset so that the BIM can run the new image in-place. The burden is then on the Downloader, which will suffer a lost BLE connection to the OAD Target during this verification and instantiation process, to restart scanning and the to reestablish a connection and verify that the new image is indeed running.

Bootloader

Since a running image cannot update itself, both On-chip and Off-chip OAD methods must employ a bootloader. A bootloader is a lightweight section of code that is designed to run every time the device resets, check the validity of newly downloaded images, and if necessary, load the new image into internal flash. TI’s bootloader implementation is called the Boot Image Manager (BIM). BIM’s implementation varies slightly for On-chip and Off-chip OAD solutions, thus there is a separate BIM project for each.

• bim_cc1350lp For On Chip OAD. Not fully supported in this release.
• bim_extflash_cc1350lp For Off Chip OAD. See BIM for Off-chip OAD

Note

As of BLE-Stack 2.03.08 BIM is always linked to page 31 of internal flash, and will always link the CCFG section with it. Thus the OAD application will not need it’s own CCFG.

Off-Chip OAD

This section describes the offchip OAD process. Off-chip OAD utilizes an external memory component (Flash) to store the new image during download and bootloading. This section aims to address the following procedures that are unique to off-chip OAD:

• Constraints and Requirements for Off-chip OAD
• Off-chip OAD Memory layout
• BIM for Off-chip OAD
• Out of the Box Demo (Off-Chip OAD)
• Add Off-chip OAD to an existing project

For information about the OAD profile and metadata, please see OAD Concept Overview

Constraints and Requirements for Off-chip OAD

In order to perform off-chip OAD the target system must contain have:

• An external storage device such as Flash memory with at least 128kB of space
• Free GPIO pins to interface to the external memory (i.e. 4 wires for SPI)
• Enough free code space to reserve the entire contents of pg 31 (4kB) for BIM
• Ability to use the split image ICall architecture. See ICall for more information.

Off-chip OAD Memory layout

The memory maps for both internal and external flash are detailed below.

Figure 77. Off-Chip OAD Memory Layout

Off-chip OAD applications use both on-chip flash memory and off-chip flash memory device. The on-chip flash memory contains the Interrupt Vectors, the BLE Stack, the Application where OAD Profile is embedded, the BLE stack image, the NV Storage Area, the BIM and the CCFG.

The off-chip flash memory on the CC13x0 LaunchPad contains up to 3 OAD Images and up to 3 Metadatas corresponding to the OAD Images. The memory map layout of the external flash part is defined in ext_flash_layout.h. The size of each OAD Image placeholder is 128kB. The memory partition of the application for Off-chip OAD is depicted in Figure 77.. Each OAD image, either App only or App+Stack, must support OAD Profile so that further OAD is enabled after it is downloaded to the off-chip memory, copied to the on-chip memory and executed.

The sectors in Figure 77. in red are designed to be permanently resident on the device. The BIM and CCFG are not intended to be upgraded via OAD. The OAD design was selected this way so that a failure during the OAD process does not yield a bricked device.

BIM for Off-chip OAD

Warning

The BIM will link the resident CCFG sector. Furthermore, this is a custom CCFG, with the IMAGE_VALID_CONF field set to 0x1F000. This means that the boot ROM of the device will automatically exectue BIM code instead of application code at startup. BIM will handle starting the application. OAD applications will not need to include a CCFG. This is a feature of CC13x0, and not compatible with R1 devices.

The OAD solution requires that permanently resident boot code, the BIM, exists in order to provide a fail-safe mechanism for determining whether to run the existing application image or to copy a new image or images from off-chip flash to on-chip flash. It is assumed that a valid image exists either in off-chip flash ready to be copied or already placed in on-chip flash at any given time. Given this assumption, the initial image placed in internal flash which does not exist in external flash will have invalid external image metadata, and so the bootloader will choose to jump to the existing image’s entry point.

At startup, BIM checks if the application image metadata in off-chip flash has a status indicating that the image is to be copied to the on-chip flash. If the status is 0xFF, copies the image if a valid CRC and CRC Shadow are found. If the status is anything other than 0xFF, assumes the application in the on-chip flash is valid to run. If a 2 byte value is found that is neither 0x0000 nor 0xFFFF, but a 0xFFFF shadow checksum is found, the BIM computes the CRC over the image. Image length is determined by the metadata that is also stored contiguous with the CRC in on-chip flash that was copied over during the original write of the image from the off-chip flash.

If off-chip flash contains an image to be downloaded, but this image is undesirable, BIM can be programmed with symbol NO_COPY to skip image checking and jump directly into the image already placed in on-chip flash; at which point the on-chip flash image could invalidate the bad image’s metadata or OAD a new image in its place. BIM will not be able to load any new images while NO_COPY is defined in the build.

BIM is only responsible for making an application image failsafe upon entry. BIM has exactly one entrance to the application image.

The BIM occupies the last flash page with CCFG and uses the interrupt vectors at the start of flash where the Reset Interrupt Vector calls the BIM startup routine to ensure its control of the system upon a device reset.

Figure 78. Functional Overview of Off-chip BIM

Out of the Box Demo (Off-Chip OAD)

The SimpleLink CC13x0 SDK includes demo projects that are set up to use OAD in advance. These build configurations may be flashed onto the device out of the box. This out of the box demos use Device Monitor as the OAD Downloader. Please see OAD Topology Overview for more information. Ensure that BLE Device Monitor is setup correctly first. See BLE Device Monitor Setup for steps on how to do so. The steps listed below assume that a CC13x0 LaunchPad is being used. Additional steps may be required for custom hardware.

Furthermore, the steps in this section are referring to the OAD Target device, the images referenced below should be flashed onto that device.

Using CCS

The steps below will describe how to run the out of the box demo for OAD on CCS.

1. Import the bim_extflash_cc1350lp, stack, and app projects into the workspace.

   

   Figure 79. Offchip OAD CCS Workspace

2. Build and load the BIM project onto the CC13x0 LaunchPad

3. Build and load the simple_peripheral_cc1350lp_stack_FlashROM project onto the CC13x0 LaunchPad

4. Build the and load the simple_peripheral_cc1350lp_app_FlashOnly_OAD_ExtFlash project

   • Note that a special post build step is needed to generate a new app image file called simple_peripheral_cc1350lp_app_FlashOnly_OAD_ExtFlash.bin when you want to send an image over the air. This is the file to be provided to BLE Device Monitor. Please see Generating a Production Image for OAD.

5. You should now be able to observe that the device is advertising using BLE Device Monitor.

   • See BLE Device Monitor OAD Verify Advertising for steps.
   • Note that per default, the application does not use any display.

6. Make your application level changes that are intended for OAD update. Follow steps in Changing Application Data to Verify an OAD for a trivial way to change app to verify the OAD. Build the application with changes.

7. Use BLE Device Monitor to OAD your modified application file following the steps detailed in BLE Device Monitor OAD Procedure

   • Make sure you are using the *_oad.bin file as this file contains the meta data (OAD image header).

Attention

After a successful OAD, you may need to re-start your CC13x0 in order for it to advertise again. This is because the XDS110 driver may be still attached from previous debug sessions.

Using IAR

The steps below will describe how to run the out of the box demo for OAD on IAR.

1. Open the bim_extflash project, build and load it onto the CC13x0 LaunchPad using the debugger.

2. Open the simple_peripheral workspace.

   • Build and load the stack project.
   • Be sure to use the FlashROM build configuration for the stack. This configuration corresponds to the ICall split image architecture required by OAD.

3. Build and load the simple_peripheral application project using the FlashOnly_OAD_ExtFlash build config.

4. You should now be able to observe that the device is advertising via BLE Device Monitor.

   • See BLE Device Monitor OAD Verify Advertising for steps.

5. Make your application level changes that are intended for OAD update. Follow steps in Changing Application Data to Verify an OAD for a trivial way to change app to verify the OAD. Build the application with changes.

6. Use BLE Device Monitor to OAD your modified application file following the steps detailed in BLE Device Monitor OAD Procedure

   • Make sure you are using the *_oad.bin file with BLE Device Monitor as this file contains the metadata. By default these images can be found at: \examples\rtos\CC1350_LAUNCHXL\blestack\simple_peripheral\tirtos\iar\app\FlashOnly_OAD_ExtFlash\Exe

Attention

After a successful OAD, you may need to re-start your CC13x0 in order for it to advertise again. This is because the XDS110 driver may be still attached from previous debug sessions.

Add Off-chip OAD to an existing project

1. Use bim_extflash project, as is. No change is required.

2. No changes are required to the stack project. As mentioned earlier, a FlashROM build configuration must be used.

3. Add OAD profile code to the application project:

   • The required files can be found in source\ti\blestack\profiles\oad\cc26xx
     • oad.c
     • oad.h
     • oad_target.h
     • oad_target_external_flash.c

4. Add External Flash middleware to application project

   • oad_target_external_flash.c relies on the ExtFlash module from the middleware folder \source\ti\mw\extflash. Add these files to the application project.
     • ExtFlash.c
     • ExtFlash.h

5. Add the necessary include paths to the project:

   • The OAD profile code can be found at source\ti\blestack\profiles\oad\cc26xx

6. Use the proper off-chip OAD linker file and configure it properly.

   • IAR projects should use cc26xx_app_oad.icf
   • CCS projects should use cc26xx_app_oad.cmd

7. Add the following defines to your application:

   • FEATURE_OAD
   • HAL_IMAGE_E

8. Add necessary code to your high level application file to include OAD.

   • Add the following defines to your application file (i.e. simple_peripheral)

     #include "oad_target.h"
     #include "oad.h"
     ...
     #define OAD_PACKET_SIZE                       ((OAD_BLOCK_SIZE) + 2)
     ...
     #define SBP_QUEUE_PING_EVT                    Event_Id_02
     
     #define SBP_ALL_EVENTS                        (SBP_ICALL_EVT        | \
                                                    SBP_QUEUE_EVT        | \
                                                    SBP_PERIODIC_EVT     | \
                                                    SBP_CONN_EVT_END_EVT | \
                                                    SBP_QUEUE_PING_EVT)
     

   • Add the following TI-RTOS Queue structures in your application:

     // Event data from OAD profile.
     static Queue_Struct oadQ;
     static Queue_Handle hOadQ;
     

   • Add a callback to your application

     void SimpleBLEPeripheral_processOadWriteCB(uint8_t event, uint16_t connHandle,
                                                uint8_t *pData);\
     ...
     static oadTargetCBs_t simpleBLEPeripheral_oadCBs =
     {
       SimpleBLEPeripheral_processOadWriteCB // Write Callback.
     };
     

   • Register the OAD service, initialize Queues.

     VOID OAD_addService();                 // OAD Profile
     OAD_register((oadTargetCBs_t *)&simpleBLEPeripheral_oadCBs);
     hOadQ = Util_constructQueue(&oadQ);
     

   • Add the OAD Queue processing code to your application

     if (events & SBP_QUEUE_PING_EVT)
     {
       while (!Queue_empty(hOadQ))
       {
         oadTargetWrite_t *oadWriteEvt = Queue_get(hOadQ);
     
         // Identify new image.
         if (oadWriteEvt->event == OAD_WRITE_IDENTIFY_REQ)
         {
           OAD_imgIdentifyWrite(oadWriteEvt->connHandle, oadWriteEvt->pData);
         }
         // Write a next block request.
         else if (oadWriteEvt->event == OAD_WRITE_BLOCK_REQ)
         {
           OAD_imgBlockWrite(oadWriteEvt->connHandle, oadWriteEvt->pData);
         }
     
         // Free buffer.
         ICall_free(oadWriteEvt);
       }
     }
     

   • Add an application layer OAD callback

     void SimpleBLEPeripheral_processOadWriteCB(uint8_t event, uint16_t connHandle,
                                                uint8_t *pData)
     {
       oadTargetWrite_t *oadWriteEvt = ICall_malloc( sizeof(oadTargetWrite_t) + \
                                                  sizeof(uint8_t) * OAD_PACKET_SIZE);
     
       if ( oadWriteEvt != NULL )
       {
         oadWriteEvt->event = event;
         oadWriteEvt->connHandle = connHandle;
     
         oadWriteEvt->pData = (uint8_t *)(&oadWriteEvt->pData + 1);
         memcpy(oadWriteEvt->pData, pData, OAD_PACKET_SIZE);
     
         Queue_put(hOadQ, (Queue_Elem *)oadWriteEvt);
     
         // Post the application's event.  For OAD, no event flag is used.
         Event_post(syncEvent, SBP_QUEUE_PING_EVT);
       }
     }
     

9. Add the necessary arguments to your configuro script to relocate your app’s reset vector address.

   • Add OAD_IMG_E=1 to your –cfgArgs. See Using a Custom Reset Vector Address for your Application for more information.

10. [Optional] On custom hardware, you may need to change the pinout of the external flash part. This can be done in two steps:

    • First, change the application layer code.

      • The application interfaces to the external SPI flash via ExtFlash.c

      • By default, the ExtFlash module uses Board_SPI0, this can be changed to Board_SPI0

        Listing 67. ExtFlash.c interface to SPI

        /* Attempt to open SPI. */
        spiHandle = SPI_open(Board_SPI0, &spiParams);
        

      • The pins used by the Board_SPIX group can be set in the board file, i.e. CC1350_LAUNCHXL.c

        Listing 68. CC1350_LAUNCHXL.c SPI1 Pins

        .mosiPin            = CC1350_LAUNCHXL_SPI1_MOSI,
        .misoPin            = CC1350_LAUNCHXL_SPI1_MISO,
        .clkPin             = CC1350_LAUNCHXL_SPI1_CLK,
        .csnPin             = CC1350_LAUNCHXL_SPI1_CSN
        

      • The defines above can be set in CC1350_LAUNCHXL.h

    • Second, change the pins that the BIM uses to acces the SPI flash. This can be done in the bim_extflash project. Since BIM is a bare metal program (no-RTOS). It doesn’t use the TI-RTOS SPI driver like the application does. BIM SPI pins are set in \examples\rtos\CC1350_LAUNCHXL\blestack\util\bim_extflash\src\cc1350\board\cc1350lp\bsp.h

      Listing 69. Offchip OAD BIM interface to SPI

      // Board external flash defines
      #define BSP_IOID_FLASH_CS       IOID_20
      #define BSP_SPI_MOSI            IOID_9
      #define BSP_SPI_MISO            IOID_8
      #define BSP_SPI_CLK_FLASH       IOID_10
      

Troubleshooting Guide

This guide seeks to address many of the common issues encountered during OAD.

General Troubleshooting Guide Prior to BIM

There are various places where OAD can fail; use the following steps to determine where the issue is occurring during the interaction:

• Use a BLE Packet Sniffer and Record the OAD Transaction

  This will verify that the profile is implemented correctly and a valid image was transferred over the air.

  • Look for a OAD Initiation

    Notifications from OAD Image Notify should be requested – and the appropriate response from the OAD Target after a GATT Write of the Candidate metadata.

  • Look for OAD Image Status Characteristic

    This will contain the status of the image prior to BIM launching the image.

• Read external/internal flash to ensure CRC Shadow is valid and matches CRC field

  • This will verify that the image was received fully without errors by the OAD Target

    • For Internal, various tools can be used. SmartRF Programmer 2 or using a jtag debugger and connecting to running target and utilizing a memory viewer are possible options.
    • For External, interface another MCU or another serial device to dump out the Flash.

Downloaded OAD Image Isn’t Starting

If the application doesn’t start running the downloaded firmware after a successful download, it’s a BIM issue.

Refer to section BIM for Off-chip OAD Utilize how BIM operates and a debugger to find where the issue is occurring.

Should External Flash be Used During OAD?

No, External flash should not be utilized while OAD Profile is active; the Profile is designed to have uninterrupted exclusive access to Flash, in Off-Chip configurations.

Building Super Hex Files

To build merged hexfiles, there are various methods to do this. One option is to utilize the TI OAD Image Tool (Python). See Generating a Production Image for OAD for more information. Hex files can be converted to binary using any tool that supports the Intel extended hex format.

Mobile Application Can’t Perform OAD

Ensure the latest version of the Application is downloaded from your Phone’s Application Store and try again.

If problem persists, please post your Phone’s Model and OS Version number along with details to reproduce your setup on our Support Forums. Utilize BLE Device Monitor and verify that the OAD works correctly.

OAD Target device doesn’t reset after successful OAD

This usually occurs when the JTAG debugger (e.g., XDS110) is connected. Disconnect and remove the debugger prior to performing OAD.

This only affects devices connected to an emulator, such as the XDS110 on LaunchPads. This issue should not appear in field devices or devices that are not connected to JTAG in general.

If the bug occurs, a temporary workaround is to simply unplug/replug or hard reset the device, and the device will boot as normal.

However, a permanent fix is available. As of version 8.0.27.9 of the emulation software package, the XDS110 emulator now drives the TCK pin high instead of leaving it in tri-state. This removes any unwanted toggling on the TCK pin after a system reset, which is triggering the Halt In Boot in the first place.

To update the emulation software packages, start by downloading the latest XDS Emulation Software Package. Then, depending on which tool you are using, follow the corresponding step-by-step guide below.

• For Flash Programmer 2:
  1. Run the above installer
  2. Copy the contents of the emulation software package to <Flash Programmer 2>/config/xds/*
• For Code Composer Studio:
  1. Run the above installer
  2. Follow the steps described in Section Manual CCS Installation from the XDS Emulation Software Package page
• For IAR:
  1. Run the above installer
  2. Change the debugger options of the project to point to the newly installed package

Figure 80. Update XDS emulation software package in IAR

Can’t connect via BLE Device Monitor After successful OAD

• Try resetting the host_test device attached to BLE Device Monitor.
• Close and re-open BLE Device Monitor.
• Verify target is advertising using a mobile app.

OAD Target App Doesn’t Advertise out of the Box

Likely the image metadata is not embedded in the image, or there is a corrupted image that is causing problems.

• Perform a forced mass erase using Smart RF Flash Programmer 2
• Follow the steps at Out of the Box Demo (Off-Chip OAD), particularly Generating a Production Image for OAD

Appendix

This section will cover various tutorials that are helpful throughout the OAD process. It is not intended to be read sequentially, but instead referenced from other sections.

Generating Linker Command File for OAD Off-chip

This section describes how to convert a standard SDK linker command file to be compatible with the TI OAD Ecosystem for both CCS and IAR linkers. You need and understanding of OAD Concept Overview.

Modifications for CCS (cc26xx_app.cmd)

1. Allocation of Flash for Metadata Vector and App Start

   FLASH_APP_BASE defines where the linker begin to place read and execute application code and data because of the following section:

   /* System memory map */
   MEMORY
   {
       /* EDITOR'S NOTE:
        * the FLASH and SRAM lengths can be changed by defining
        * ICALL_STACK0_START or ICALL_RAM0_START in
        * Properties->ARM Linker->Advanced Options->Command File Preprocessing.
        */
   
       /* Application stored in and executes from internal flash */
       /* Flash Size 128 KB */
       #ifdef ICALL_STACK0_START
           FLASH (RX) : origin = FLASH_APP_BASE, length = ADJ_ICALL_STACK0_START - FLASH_APP_BASE
       #else // default
           FLASH (RX) : origin = FLASH_APP_BASE, length = FLASH_LEN - FLASH_PAGE_LEN
       #endif
   

   Instead of origin being assigned to FLASH_APP_BASE, assign to a new undefined symbol FLASH_OAD_IMG_START.

   /* System memory map */
   MEMORY
   {
       /* EDITOR'S NOTE:
        * the FLASH and SRAM lengths can be changed by defining
        * ICALL_STACK0_START or ICALL_RAM0_START in
        * Properties->ARM Linker->Advanced Options->Command File Preprocessing.
        */
   
       /* Application stored in and executes from internal flash */
       /* Flash Size 128 KB */
       #ifdef ICALL_STACK0_START
           FLASH (RX) : origin = FLASH_OAD_IMG_START, length = ADJ_ICALL_STACK0_START - FLASH_APP_BASE
       #else // default
           FLASH (RX) : origin = FLASH_OAD_IMG_START, length = FLASH_LEN - FLASH_PAGE_LEN
       #endif
   

   Now to define the symbol, we need to shift the starting point over 16 bytes. The original linker file code is:

   /* The starting address of the application.  Normally the interrupt vectors  */
   /* must be located at the beginning of the application. Flash is 128KB, with */
   /* sector length of 4KB                                                      */
   #define FLASH_APP_BASE          0x00000000
   #define FLASH_LEN               0x20000
   #define FLASH_PAGE_LEN          0x1000
   #define FLASH_PAGE_MASK         0xFFFFF000
   
   /* Last page of Flash is allocated to App: 0x1F000 - 0x1FFFF */
   #define FLASH_LAST_PAGE_START   (FLASH_LEN - FLASH_PAGE_LEN)
   
   #ifdef ICALL_STACK0_START
   #ifdef PAGE_ALIGN
   #define ADJ_ICALL_STACK0_START (ICALL_STACK0_START & FLASH_PAGE_MASK)
   #else /* !PAGE_ALIGN */
   #define ADJ_ICALL_STACK0_START ICALL_STACK0_START
   #endif /* PAGE_ALIGN */
   #endif /* ICALL_STACK0_START */
   

   Replace with the following which defines FLASH_OAD_IMG_START relative to the symbol FLASH_OAD_IMG_HDR_SIZE, or 16 bytes.

   /* The starting address of the application.  Normally the interrupt vectors  */
   /* must be located at the beginning of the application.                      */
   #ifndef FLASH_APP_BASE
   #define FLASH_APP_BASE          0x00000000
   #endif /* FLASH_APP_BASE */
   
   #define FLASH_OAD_IMG_HDR_SIZE  0x10  /* header size (hex) in bytes */
   #define FLASH_OAD_IMG_START     (FLASH_APP_BASE + FLASH_OAD_IMG_HDR_SIZE)
   
   #define FLASH_LEN               0x20000
   #define FLASH_PAGE_LEN          0x1000
   #define FLASH_PAGE_MASK         0xFFFFF000
   
   #ifdef ICALL_STACK0_START
   #define ADJ_ICALL_STACK0_START (ICALL_STACK0_START & FLASH_PAGE_MASK)
   #endif /* ICALL_STACK0_START */
   

2. Preservation of Page 31 (BIM + CCFGs)

   Due to the previous step, we can violate this rule. Look at the following:

   /* Application stored in and executes from internal flash */
   /* Flash Size 128 KB */
   #ifdef ICALL_STACK0_START
       FLASH (RX) : origin = FLASH_OAD_IMG_START, length = ADJ_ICALL_STACK0_START - FLASH_APP_BASE
   #else // default
       FLASH (RX) : origin = FLASH_OAD_IMG_START, length = FLASH_LEN - FLASH_PAGE_LEN
   #endif
   

   For example, if ICALL_STACK0_START isn’t defined (for a Library build) then the starting address FLASH_OAD_IMG_START but the length is FLASH_LEN - FLASH_PAGE_LEN which is 128 kB - 4 kB. The problem is there is actually less space available and we are over allocating. Rewritten, the starting address for FLASH is 0x010, the ending address is 0x1F010, cutting into the last page, violating this rule.

   To fix this, simply subtract off the size of the meta data vector by using the previously defined FLASH_OAD_IMG_HDR_SIZE.

   The fix will look like:

   /* Application stored in and executes from internal flash */
   /* Flash Size 128 KB */
   #ifdef ICALL_STACK0_START
       FLASH (RX) : origin = FLASH_OAD_IMG_START, length = ADJ_ICALL_STACK0_START - FLASH_OAD_IMG_HDR_SIZE
   #else // default
       FLASH (RX) : origin = FLASH_OAD_IMG_START, length = FLASH_LEN - FLASH_PAGE_LEN - FLASH_OAD_IMG_HDR_SIZE
   #endif
   

   The final range for FLASH if ICALL_STACK0_START isn’t defined (like in a Library build), will be 0x010 to 0x1F000. In other words, all the way until the last page.

   Warning

   For App only OAD or App + Stack non-library OAD, you will have to build the stack image first or manually define ICALL_STACK0_START so the stack image’s entry point doesn’t get corrupted.

   Note

   SNV flash range is automatically accounted for if ICALL_STACK0_START is defined.

   SNV flash range does not need to accounted for in library builds, as long FLASH range extends to right up to the last page, the SNV sectors will get linked in.

3. Alignment of Interrupt Vector Table see Using a Custom Reset Vector Address for your Application

   This is already handled by the existing linker file with:

   /* Retain interrupt vector table variable                                    */
   --retain=g_pfnVectors
   /* Override default entry point.                                             */
   --entry_point ResetISR
   /* Suppress warnings and errors:                                             */
   /* - 10063: Warning about entry point not being _c_int00                     */
   /* - 16011, 16012: 8-byte alignment errors. Observed when linking in object  */
   /*   files compiled using Keil (ARM compiler)                                */
   --diag_suppress=10063,16011,16012
   

4. Page Alignment of OAD Image

   The OAD image for a library OAD build with SNV will always be 31 pages. No page alignment is necessary. OAD Image Tool also will pad with 0xFF to the next page when producing an output binary.

Modifications for IAR (cc26xx_app_and_stack.icf)

1. Allocation of Flash for Metadata Vector and App Start

   We want the FLASH region to defines where the linker should place application and stack code and data.

   Replace:

   // Code and RO Data
   place in FLASH_ALL { readonly };
   

   With:

   // Code and RO Data
   place in FLASH { readonly };
   

   Next redefine FLASH such that it goes from a undefined symbol OAD_FLASH_START to FLASH_END which is defined to the end of page 30. OAD_FLASH_START will represent where application/stack code may begin, after the header

   define region FLASH = mem:[from OAD_FLASH_START to FLASH_END];
   

   Then define the symbols that accounts for the OAD metadata:

   // OAD specific
   define symbol OAD_HDR_SIZE  = 16; // Size of metadata vector
   define symbol OAD_HDR_START   = FLASH_START;
   define symbol OAD_HDR_END     = OAD_HDR_START + OAD_HDR_SIZE - 1;
   

   Lastly define OAD_FLASH_START, accounting for the metadata vector as well as the interrupt table:

   define symbol OAD_FLASH_START = INT_VEC_START + INT_VEC_SIZE;
   

   Note

   To fully define OAD_FLASH_START, the interrupt vector table needs to be accounted for. See the next step.

2. Alignment of Interrupt Vector Table see Using a Custom Reset Vector Address for your Application

   The Interrupt Vector Table needs to be placed in order for the application to function correctly. Normally, the table would start at the beginning of flash; however, due to the metadata vector, the table needs to be moved.

   First define symbols to account for the table:

   define symbol INT_VEC_SIZE    = 64;
   define symbol INT_VEC_START   = OAD_HDR_START + OAD_HDR_SIZE;
   define symbol INT_VEC_END     = INT_VEC_START + INT_VEC_SIZE - 1;
   

   Note

   Symbols OAD_HDR_START and OAD_HDR_SIZE are defined in the previous step.

   Next define the region based off the symbols defined:

   define region INT_VEC   = mem:[from INT_VEC_START to INT_VEC_END];
   

   Lastly, for memory placement, the following needs to be added so the .intvec section gets placed correctly:

   // Interrupt Vector Table
   place at start of INT_VEC       { readonly section .intvec };
   keep                            { readonly section .intvec };
   

3. Preservation of Page 31 (BIM + CCFGs)

   Although the project shouldn’t be building the ccfg_app_ble.c file, thus there shouldn’t be anything to link, removal of the following lines is recommended:

   // CCFG
   place at end of FLASH_LAST_PAGE { readonly section .ccfg };
   keep { section .ccfg };
   

   BIM should be building and linking the CCFGs.

   The previous steps ensure that page 31 isn’t used by linker.

4. Page Alignment of OAD Image

   The OAD image for a library OAD build with SNV will always be 31 pages. No page alignment is necessary. OAD Image Tool also will pad with 0xFF to the next page when producing an output binary.

Stack Side Changes for OAD Project

Generally, no stack side changes to enable OAD are required. However, if desired, depending on the OAD configuration type, stack side changes may be done in the project.

The configurations that may a stack side change are configurations where the stack image is separate from the application image. In other words, App only and Stack only for Off-chip, and (Img_B) App only for On-chip. No changes on stack project in Library OAD configurations should be done.

One possible change is to page align the stack, such that the entry point is always the same address at the beginning of a page. To force the linker to be page aligned, simply add PAGE_ALIGN=1 to the linker defines on the stack project.

In the case of a Stack only OAD configuration, the stack OAD project can be page aligned to allow for the additional features (up to the boundary). As long as the entry point is the same, the application will function normally.

Note

Modifying the Stack project to meet your applications needs is highly encouraged. For example, adding/removing SNV Using Simple NV for Flash Storage or changing Stack Configurations, should be done to meet application needs.

This topic of this section is stack side changes in order to work with the TI OAD ecosystem.

Generating Metadata Vector for OAD Image

The OAD_Image_Tool is designed to generate a metadata vector and insert it into a given image, to produce an OAD ready image. An OAD ready image can be a hex file or a binary that contains metadata for the target to interpret.

The OAD_Image_Tool can be found as a Python script or as a binary inside SimpleLink CC13x0 SDK installation. It is located in BLE Examples Support Files in the Tools folder.

To view usage instructions for the tool, run the Python script or the binary with the -h argument passed in.

For example, to generate an OAD ready application image, invoke the tool with:

./oad_image_tool.exe -t offchip -o out.hex -m 0x0000 -i app in.hex

The out.hex file will be an OAD ready image with the metadata to tell the OAD Target that it’s an Application image for Off-chip OAD.

Generating a Production Image for OAD

A production image is one that contains the app, stack, and BIM images combined into a single file. Production images are generally used when an OAD enabled device is initially programmed at the manufacturing facility. Production images can also be useful for debugging as all of the information is contained in a single file.

TI has included a Python based OAD_Image_Tool that can perform a variety of operations on OAD ready hex files in the SimpleLink CC13x0 SDK. It will be used to generate a production OAD image.

Currently, the oad_image_tool is already being invoked as a post build step on oad_target_app, and simple_peripheral builds for on and off-chip OAD.

Run OAD Image Tool with Python

You can run the oad image tool from the oad_image_tool.exe file as described below, or you can follow these steps to run the python script (oad_image_tool.py) directly.

1. Make sure you have Python 2.7 installed with the following modules: intelhex and crcmod.

2. Open a terminal window and navigate to <SDK Install>toolscommonoad

3. Call oad image tool with the help flag (-h) for instructions on how to use it:

   python oad_image_tool.py -h
   

4. In order to generate a production image, call oad image tool with the following parameters:

   python oad_image_tool.py <path to BIM hex image> <path to app hex image> <path to stack hex image> -o <production image name>.hex -i production -t <offchip or onchip>
   

5. To generate an image to be sent over the air (app + stack image), call oad image tool with the following parameters:

   python oad_image_tool.py -v 0x0100 -i stack <path to app hex image> <path to stack hex image> -ob <oad image name>.bin -m 0x1000
   

CCS Update OAD Image Tool Build Step

The image below shows how to edit the CCS post build step for the OAD image tool. This menu can be accessed by right clicking the project –> properties.

Figure 81. Update OAD Image Tool Post Build Step CCS

IAR Update OAD Image Tool Build Step

The image below shows how to edit the IAR post build step for the OAD image tool. This menu can be accessed by right clicking the project –> options.

Figure 82. Update OAD Image Tool Post Build Step IAR

Generate production Off-Chip using CCS

The following steps detail how to generate an off-chip OAD production image which contains Image A and the off-chip BIM.

Warning

The following steps assume you have already followed the steps 1-2 of the Out of the Box Demo (Off-Chip OAD) for CCS.

• Add the following code to the oad_target_cc1350lp_app project’s post build steps.

  "${TI_BLE_SDK_BASE}/tools/blestack/oad/oad_image_tool.exe" "${ProjName}.hex" "${PROJECT_LOC}/../simple_peripheral_cc1350_stack_oad_offchip/FlashROM/      simple_peripheral_cc1350lp_stack_oad_offchip.hex" "${PROJECT_LOC}/../bim_oad_offchip_cc1350lp_app/FlashOnly/bim_oad_offchip_cc1350lp_app.hex" -t onchip -i production -v 0 -m 0x0000 --r 0x0000 -ob "${ProjName}_oad.bin"
  

Generate production Off-Chip Image using IAR

The following steps detail how to generate an off-chip OAD production image which contains Image A and the off-chip BIM.

Warning

The following steps assume you have already followed the steps 1-2 of the Out of the Box Demo (Off-Chip OAD) for IAR.

• Add the following code to the oad_target_cc1350lp_app project’s post build steps.

  "$TOOLS_BLE$\oad\oad_image_tool.exe" "$PROJ_DIR$\..\..\..\..\bim_oad_offchip\tirtos\iar\app\FlashOnly\Exe\bim_oad_offchip.hex" "$PROJ_DIR$\..\stack\FlashROM\Exe\simple_peripheral_cc1350lp_stack.hex" "$PROJ_DIR$\FlashROM_OAD_Offchip\Exe\simple_peripheral_cc1350lp_app.hex" -t onchip -i production -v 0 -m 0x0000 -ob "$PROJ_DIR$\FlashROM_OAD_Offchip\Exe\simple_peripheral_cc1350lp_app_oad.bin"
  

Using a Custom Reset Vector Address for your Application

The projects within the SimpleLink CC13x0 SDK will build the TI-RTOS kernel as a pre-build step within the application. This prebuild step is called configuro. During the configuro stage it is possible to relocate your reset vectors. This is required for OAD applications to make room for the metadata vector at the beginning of the image space. For more information about configuro, please see RTSC Configuro Page.

Note

You may need to change OAD_IMG_E=1 in the images below to OAD_IMG_A=1 or OAD_IMG_B=1 depending on your use case.

Change Reset Vector Address in IAR

IAR treats configuro as a prebuild action. These actions can be found by right clicking the project –> Build Actions –> Pre-build command line. See the image below for more information.

Change Reset Vector Address in CCS

CCS has native RTSC/Configuro support built into the project. These actions can be found by right clicking the project –> Build –> XDCtools –> Advanced Options. See the image below for more information.

Changing Application Data to Verify an OAD

It can be difficult to verify OAD without making application changes. A quick and easy way to change your application image before sending over the air is to change it’s scan response data.

This way, a successful OAD can be observed via the change in scan response data. See below for steps on how to change this.

• A good test is to change the scan response data as below in simple_peripheral.c

Listing 70. Changing SBP advertisement data

// GAP - SCAN RSP data (max size = 31 bytes)
static uint8_t scanRspData[] =
{
  // complete name
  0x14,   // length of this data
  GAP_ADTYPE_LOCAL_NAME_COMPLETE,
  'S',
  'i',
  'm',
  'p',
  'l',
  'e',
  'B',
  'L',
  'E',
  'P',
  'e',
  'r',
  'i',
  'p',
  'h',
  'e',
  'r',
  'a',
  '2',
  //...
}

Warning

If you change of scan response data you must also change it’s length. See line 5 of the code snippet above.

Using BLE Device Monitor and CC13x0 LaunchPad as OAD Downloader

This section will describe how to use setup and use BLE Device Monitor to perform an OAD. These steps are independent of OAD type and can be used to perform on-chip or off-chip OAD.

Tip

BLE Device Monitor is a feature-rich application. This guide only seeks to document the OAD functionality of BLE Device Monitor.

BLE Device Monitor Setup

You can download BLE Device Monitor here.

BLE Device Monitor requires a CC13x0 LaunchPad running the host_test application with POWER_SAVING disabled connected to the PC. Steps on how to setup a CC13x0 LaunchPad to work with BLE Device Monitor are listed below. See OAD Topology Overview for more information.

1. Navigate to the install location of the SimpleLink CC13x0 SDK.

2. Within the SimpleLink CC13x0 SDK open the \examples\rtos\CC1350_LAUNCHXL\ti154stack\hexfiles\oad\cc13x0 folder.

3. Open Flash Programmer 2.

4. Load the OAD Downloader CC13x0 LaunchPad with the host_test_cc1350lp_all.hex image.

5. Open BLE Device Monitor

6. Configure the correct COM port for you Host test device by opening Options -> Serial Port

   

   Figure 85. devmon-options.png

BLE Device Monitor OAD Verify Advertising

BLE Device Monitor can be used to scan and discover BLE devices. You can verify that your OAD Target device is advertising by following one of the options below.

• Advertisement can be verified in one of two ways:
  • If you know your device’s address (can be checked via Smart RF Flash Programmer 2) you can click the scan button and verify it appears in the “Slave BDA” combo box.
  • If you don’t know your device’s address, you can change it’s advertisement data (described in Changing Application Data to Verify an OAD). The BLE Device Monitor will display the device name if this is found in the advertisement or scan response data.

BLE Device Monitor OAD Procedure

1. Open BLE Device Monitor, and connect to your device. Press the Scan button to scan for devices. Double-click on your device to connect to it.

   

   Figure 86. Connecting to a device using BLE Device Monitor

   

   Figure 87. Connecting to a device using BLE Device Monitor

2. When you have made a connection you can discover the services that the Client (OAD target) offers. Select the Discover button in the Services panel. After a few moments you will see a list of Services/characteristics of the device. If you have done everything right thus far you should see that there is a OAD Service available for the SimpleBLEPeripheral device. If there is no such service for the Client device then you have flashed the Client with a non OAD image.

   

   Figure 88. Discover services

   

   Figure 89. Discover OAD service

3. Select File→Program (OAD). Select the proper OAD type that fits your use case. You will now see the OAD Programming panel appear.

   

   Figure 90. Initiating an OAD transfer

4. Select Off-chip OAD in the pop-up. Make sure that the image type is set to 2 (stack).

   

   Figure 91. OAD panel

5. Browse to the .bin image you have created with Generating a Production Image for OAD. Click Start to start the OAD transfer.

6. When the OAD has completed, reset the OAD target. You should now see it advertise with the changes you applied in Changing Application Data to Verify an OAD.