CC2541 Dual Stack

From Texas Instruments Wiki
Jump to: navigation, search

Bluetooth Low Energy Main Page


Introduction

NB! This page is still under construction and will be finalized as soon as BLE-stack 1.3 is available on the web.

The CC2541 is a power-optimized true system-on-chip (SoC) solution for both Bluetooth low energy and proprietary 2.4-GHz applications. This dual mode capability provides the Low Power RF markets only chip set that can combine Bluetooth Low Energy applications with proprietary RF solutions on the same device. The CC2541 offers 2 MB data rates and is ideal for applications that need to combine BLE connections with higher data rates.

A typical use case would be an application which most of the time use BLE but for shorter periods requires higher throughput, for instance voice. An example would be a BLE-based remote control with voice command capabilities.

This document aims to explain the basic mechanisms for implementing dual-stack solutions and provide code snippets that explain the details. It is based on the assumption that one of the applications will use BLE 1.3 from Texas Instruments, and the secondary stack any application that requires higher throughput than that BLE can offer. The secondary stack is in this case a simple proprietary protocol (BasicRF), and the application on top of it is a PER test (TBD). The BLE 1.3 application in this example is SimpleBlePeripheral as included in the official release.

Preparations

The example provided with this document requires the following software and hardware components

  • SmartRF05EB 1.8.1
  • CC2541EM
  • USB cable (PC to SmartRF05EB)
  • PC with Windows XP/Windows 7
  • IAR Embedded Work Bench (compiler version 8.10.4)
  • Texas Instruments BLE Stack, version 1.3

Flash partitioning

The Dual Stack setup is implemented by sharing the flash space between two entirely independent images. Switching between them is achieved by resetting the CC2541 after first having set a flag in the IDATA segment that tells which image is to be run. Alternatively an IO-pin can be used to arbitrate between the two images. The images are located from flash address 0x0830 and 0x4030 respectively. These are hereafter referred to as IMAGE A and IMAGE B. Note that similarity with OAD (Over the Air Download) as described in application note ANxxx (part of BLE-stack 1.3). Dual Boot and OAD in fact use the same linker files and the IAR project files for BLE OAD applications may be used in Dual Stack configurations with only minor modifications.

Boot Image Manager

Arbitration between flash image A and B is done by the Boot Image Manager (BIM). This is a small piece of code that resides at flash location zero. It determines which image to run based on the contents of IDATA location 0x09. If this address contains a ‘0’ image A is executed, otherwise image ‘B’ will be invoked. The applications in image A and B must NOT initialise this location, otherwise image switching will be impossible! Avoiding initialisation is achieved with the IAR macro _no_init.

The Boot Image Manager has another important role; it provides interrupt relaying to whatever flash image is currently active. This is achieved by checking IDATA location 9 and jump to the Interrupt Service Routine (ISR) in flash image A or B accordingly.

Note that BIM for Dual Stack is different from OAD. The interrupt relaying is identical but the image arbitration is done differently. The OAD BIM runs the first image with a valid checksum, with image A having the highest priority. For Dual Boot systems other arbitrations mechanism may be desired, for instance the value of a data location (as in this example) or the state of an IO pin. This makes for a much simpler BIM as there is no CRC-calculation involved. It is assumed that both images are programmed via IAR or the SmartRF flash programmer.

BLE application

The Dual Stack BLE application uses the same linker file as an OAD-application, but does not need the OAD profile in order to work. Nor does it need the binary files used for OAD as Intel HEX-files or IAR download is sufficient for programming the image. To convert an IAR OAD-enabled project to a smaller footprint Dual Stack project, follow the steps below. The description refers to the sample application SimpleBLEPeripheral found in the BLE 1.3 stack release.

Creating an Image A configuration

  • Make a copy of the project configuration CC2541-OAD-ImgA and name it (for instance) CC2541-DS-ImgA
  • Remove the files oad.h, oad_target.c and oad_target.h from the project (these file are found in the group ‘PROFILES’
  • Removed the compiler switches FEATURE_OAD and FEATURE_OAD_BIM
  • In Build Actions, remove the post-build processing

Creating an Image B configuration

  • Make a copy of the project configuration CC2541-DS-ImgA and name it CC2541-DS-ImgB
  • Change the name of the linker file from ‘xxxxA’ to ‘xxxxB’
  • Change the compiler switch HAL_IMAGE_A to HAL_IMAGE_B

Proprietary Application

The proprietary application must use the same linker files the BLE, and similarly provide the compiler switches HAL_IMAGE_A and HAL_IMAGE_B respectively. It is also important that the setting for the debugger does NOT erase the flash when downloading with IAR. Otherwise project configurations are identical to those used with normal proprietary projects.

The example here is a PER-test application that is similar to those provided with CC2530, CC2430 and CC2520.

Arbitration

From within Application

Switching between images would typically be done by the application by setting the value at IDATA location 0x09 and doing a soft reset. The Boot Image Manager would then invoke the image according to the value of that location. This ‘on-the-fly’ image switching would typically be used in a BLE application that intermittently requires high throughput. The main body of BIM is implemented as shown in the example. Remember that the arbitration variable MUST be declared as follows by the application:

__no_init __data uint8 JumpToImageAorB @ 0x09;

The switch is then effectuated by setting this variable to the desired value (0 for image A, 1 for image B) and performing a soft reset. IN BLE this is done with the macro HAL_SYSTEM_RESET() which in effect is a forced watchdog reset.

Executing the image switch from the application

// Example: switch to image B
JumpToImageAorB  = 1;
HAL_SYSTEM_RESET();

BIM main body for image switching by the application

void main(void)
{
  if (JumpToImageAorB == 0)
  {
    // Execute image A
    asm("LJMP 0x0830");
  }
  else
  {
    // Execute image B
    JumpToImageAorB = 1;
    asm("LJMP 0x4030");
  }

  SLEEPCMD |= 0x03;    // PM3, All clock oscillators off, voltage regulator off.
  halSleepExec();
  HAL_SYSTEM_RESET();  // Should not get here.
}

From Boot Image Manager (BIM)

As an alternative the image could be selected at boot-time by polling the value of an IO, typically connected to a jumper or a button. In this type of setup the image to run is selected once, typically when it is convenient to store two totally independent applications on the same device. The main body of BIM would typically be implemented as shown below. In this example, button 1 of SmartRF05EB is used to determine which image is to be executed. If the button is pressed at boot-time, image A will be executed, otherwise image B.

void main(void)
{
  P0DIR = 0xFD;   // Input - BTN 1 - P0.1

  if (P0 & 2)
  {
    // Execute image A
    JumpToImageAorB = 0;
    asm("LJMP 0x0830");
  }
  else
  {
    // Execute image B
    JumpToImageAorB = 1;
    asm("LJMP 0x4030");
  }

  SLEEPCMD |= 0x03;    // PM3, All clock oscillators off, voltage regulator off.
  halSleepExec();
  HAL_SYSTEM_RESET();  // Should not get here.
}

Flash Programming

To program the flash with the various images, either IAR or the SmartRF Flash Programmer can be used. It is important that the BIM (Boot Image Manager) is programmed first. The project is located in the sub-folder projects/util/BIM. Modify the main body of bim_main.c (remember to back up the original) to suit the particular needs of your application. Downloading with IAR will also erase the flash.

Then Image A and Image B can be programmed in any order. The IAR projects are configured to retain flash pages that are not used (otherwise BIM and the alternate image will be destroyed.

When programming with SmartRF Flash Programmer, the same order must be observed. First program BIM using the standard Erase/Program/Verify) operation. To program Image A and Image B respectively it is important that you used the Append operation, otherwise BIM and the alternate image will be erased.