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.

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 CC1350 Launchpad.

Warning

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

Read this Section First

Document Updates/Errata

This document is constantly being improved. For the best user experience, please ensure that you are using the latest version. Newer revisions will be posted online on the OAD User’s Guide wiki page.

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 61. 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 61. 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 62. shows a graphical relationship of the devices required for an OAD transfer.

Figure 62. OAD Downloader and Target

All provided TI example applications (BTool, 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 BTool displaying the OAD service is shown below:

Figure 63. 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 63.

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 68..

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 64. Reject Notification in Sniffer Capture

Alternatively, a successful OAD initiation is shown in below:

Figure 65. 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 66. shows a block request/response sniffer capture.

Figure 66. Block Request/Response Sniffer Capture

In Figure 66. 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 Service

The OAD reset service is only used by on-chip OAD solutions. It implements a method for invalidating the currently running image and resetting the device. This must occur because in on-chip solutions the currently running image cannot update itself. More information about the on-chip OAD process will be covered in the on-chip OAD chapter. Figure 67. shows an overview of the OAD reset service and it’s characteristic. Like the OAD service, the reset service uses the 128 bit TI base UUID with a 16 bit short UUID of 0xFFD0.

Figure 67. OAD Reset Service

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 68. 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 68..

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.03 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 69. 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 CC1350 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 69.. 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 69. 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 70. Functional Overview of Off-chip BIM

Out of the Box Demo (Off-Chip OAD)

The SimpleLink CC13x0 SDK includes demo projects that are setup to use OAD in advance. These build configurations may be flashed onto the device out of the box. All out of the box demos use BTool as the OAD Downloader. Please see OAD Topology Overview for more information. Ensure that BTool is setup correctly first. See BTool Setup for steps on how to do so. The steps listed below assume that a CC1350 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 refrenced below should be flashed onto that device.

Using CCS

Warning

If both the OAD Target and the OAD Downloader are connected at the same time, CCS may load the image to the wrong device. This is because CCS will select the first XDS110 it finds. This behavior can be avoided by unplugging the OAD Target device, or by setting a multi emulator debug session using CCS. See the wiki Debug with Multiple Emulators for more information.

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

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

   

   Figure 71. Offchip OAD CCS Workspace

2. Build and load the BIM project onto the CC1350 Launchpad

3. Build and load the simple_peripheral_cc1350lp_stack_FlashROM project onto the CC1350 Launchpad

4. Build the and load the simple_peripheral_cc1350lp_app_FlashOnly_OAD_ExtFlash project

   • Note that a special post build step will run and generate a new app image file called simple_peripheral_cc1350lp_app_FlashOnly_OAD_ExtFlash.bin. This is the file to be provided to BTool and sent over the air.

5. You should now be able to observe that the device is advertising using BTool.

   • See BTool OAD Verify Advertising for steps.

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 BTool to OAD your modified application file following the steps detailed in BTool OAD Procedure

   • Make sure you are using the *_oad.bin file with BTool as this file contains the metadata.

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 CC1350 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 BTool.

   • See BTool 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 BTool to OAD your modified application file following the steps detailed in BTool OAD Procedure

   • Make sure you are using the *_oad.bin file with BTool 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 BTool and verify that the OAD works correctly.

OAD Target device doesn’t reset after successful OAD

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

This issue should not be appearing in field devices, or devices that are powered through a battery or other means.

Can’t connect via BTool After successful OAD

• Try resetting the host_test device attached to BTool.
• Close and re-open BTool.
• 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.

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 72. 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 73. 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 BTool and CC1350 Launchpad as an OAD Downloader

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

Tip

BTool is a very feature-rich application. This guide only seeks to document the OAD functionality of BTool.

Warning

Use the BTool included with SimpleLink CC13x0 SDK, older versions may not have support for OAD.

BTool Setup

BTool requires a CC1350 Launchpad running the host_test application with POWER_SAVING disabled connected to the PC. Steps on how to setup a CC1350 Launchpad to work with BTool 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\blestack\hexfiles folder.
3. Open Smart RF Flash Programmer 2.
4. Load the OAD Downloader CC1350 Launchpad with the cc1350lp_host_test.hex image.

BTool OAD Verify Advertising

BTool can be used to scan and discover OAD device. You can verify your 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). From there, scan the scan button and look in the BTool log window during scanning to verify the device with the custom advertising data appears.

BTool OAD Procedure

1. Open BTool, and connect to your device. See the image below for steps.

   

   Figure 76. Connecting to a device using BTool

2. Select to the OAD tab in BTool and initiate the OAD process. See the image below for instructions

   Attention

   Be sure to point BTool to the *_oad.bin file generated by the oad image tool post build step. This file contains the metadata.

   

   Figure 77. Initiating an OAD transfer via BTool

   Note

   If BTool from another Software Development Kit is used then the OAD Transfer Tab may not exist. Use the BTool that is included with SimpleLink CC13x0 SDK

3. OAD process will continue as below

   

   Figure 78. OAD transfer via BTool

4. BTool will report success

   

   Figure 79. Successful OAD transfer using BTool