CC2640 to CC2640R2F

Introduction

This section describes main differences an Application Developer must be aware of between the CC2640 and the CC2640R2F along with a example porting guide to demonstrate the migration effort.

The CC2640R2F was designed to increase flash availability for the application, without changing underlying proven hardware of the CC2640.

Due to the underlaying hardware and platform based on the CC2640, the migration effort from a CC2640 to CC2640R2F is very minor. For more information on specific steps, see Porting Guide from CC2640 to CC2640R2F for specific instructions.

Features and Benefits

To enable maximum possible flash availability, the CC2640R2F features:
Additional benefits of the CC2640R2F:

These features and benefits enable rapid development, future-ready, and innovative robust products.

Additional ROM Support on CC2640R2F

A majority of the increase in application flash availability is due to portions of the BLE-Stack 3.00.XX being placed into ROM. When enabled, the stack flash usage dramatically decreases. Up to an ~50% decrease of BLE-Stack 3.00.XX flash usage can be realized with this feature alone; this results in up to an additional 30kB for the application when migrating from an existing CC2640 project.

In addition, the BLE-Stack 3.00.XX has the following Bluetooth Core Specification Version 4.2 features always enabled:

  • Ping
  • Slave feature exchange
  • Connection Parameter Update Request
  • Multirole Connections
  • Privacy
  • LE Data Length Extension

See Stack Configurations for more information on selecting features.

See Porting Guide from CC2640 to CC2640R2F for specific instructions.

Warning

Flashing a CC2640 with binaries made for CC2640R2F will result in a spin-lock prior to main.

../_images/running-r2-on-r1-trap.png

Figure 133. A screen shot highlighting the spin-lock in IAR when running CC2640R2F code on a CC2640.

../_images/running-r2-on-r1-trap-ccs.png

Figure 134. A screen shot highlighting the spin-lock in CCS when running CC2640R2F code on a CC2640.

Improved ICall and App/Stack library builds

ICall has been optimized for reduced flash usage and increased stack operational efficiency. Given these improvements to ICall, stack library builds are possible.

Library builds will not have an application/stack Boundary. Global linking is enabled instead. This allows the linker to only link the stack components that are utilized. Global linking also allows objects used by both the application and stack to be shared.

No ICall/Stack API changes are required to realize these benefits.

For details regarding improved ICall and it’s benefits, see Improved ICall Architecture (ICall Lite).

For additional information on ICall see ICall.

Word alignment boundary support in CCS for split image build configurations

In previous versions of Code Composer Studio, the flash-loader driver was limited to writing/reading/erasing a page at a time. This meant that in the dual-image configuration of the CC2640 on CCS, the boundary was forced to be page aligned. Worst case, up to a page (4kB) of flash could potentially wasted to maintain this boundary.

Utilizing the upgraded word aligned CCS flash-loader driver in CCS 7.0.0, along with enhancements in the Frontier tool, limits the worst case to the size of a word (32 bits). Word alignment allows for additional Application or Stack Flash usage.

Note

IAR Embedded Workbench for ARM supported this feature with CC2640.

Note

OAD currently only supports page aligned boundaries to allow for application or stack updates. For word alignment with OAD, please see Supported Stack Image Types

CC2640R2F LaunchPad Support

All example applications are compatible with the CC2640R2F LaunchPad development kit. These features allow for a unified development experience and empowers developers to rapidly release to market.

CC2640R2 LaunchPad Development Kit Product Page

Improved OAD Support

OAD Support on the CC2640R2F has been improved with new features to boost flash availability to both the application and the stack and reduce costs to future proof.

The CC2640R2F has been improved to allow the linkages to TI-RTOS ROM functions for OAD application images. The nature of OAD and BIM on CC2640 forced TI-RTOS to be linked into flash for OAD application images.

In addition, BIM for CC2640R2F is redesigned to reside in Page 31 of flash. CC2640’s BIM resided in both Page 0 and Page 31, limiting Application and Stack flash. This feature allows for an additional Page for the developer to use.

BTool now supports the OAD profile, replacing BLE Device Monitor. This change allows us to give a consistent OAD Downloader experience across all devices supporting TI BLE-Stack 3.00.XX.

For more information regarding OAD, see Over the Air Download (OAD)

Note

On-Chip OAD was supported by IAR Embedded Workbench for ARM for CC2640.

Micro BLE Stack for broadcaster applications

The Micro BLE Stack is included with the BLE-Stack 3.00.XX. It features the ability to send non-connectable advertisements, and is planned to support scannable advertisements and scanning in the future.

For more information on the Micro BLE Stack see Micro BLE Stack.

Additional Vendor Specific HCI Functionality

Two additional vendor specific commands were created in BLE-Stack 3.00.XX:

  • HCI_EXT_ScanEventNoticeCmd()

    Scan Request Detection allows for a BLE Application operating as a Peripheral or Broadcaster GAPRole to receive a notification when a Scan Request is received from a peer device.

  • HCI_EXT_ScanReqRptCmd()

    Scan Event Notifications allows for a BLE Application operating as a Central or Observer GAPRole to receive a notification when a Scan Event is completed.

Porting Guide from CC2640 to CC2640R2F

These sections describe porting between different versions of the BLE-Stack. To port from versions of the BLE-Stack prior to BLE-Stack 2.2.1, see the Porting Guide Wiki

Porting Instructions from BLE-Stack 2.2.1 to BLE-Stack 3.00.00

This section will describe a way to port a project from BLE-Stack 2.2.1 to a BLE-Stack 3.00.00 project.

For this porting guide, simple_peripheral from BLE-Stack 2.2.1 will be ported over to BLE-Stack 3.00.00. Due to the a number of changes in the directory structure and drivers, we will utilize the simple_peripheral project in BLE-Stack 3.00.00 as the project base. In other words, no modifications will be made to the BLE-Stack 2.2.1 project. All application specific code will be inserted into the BLE-Stack 3.00.00 project.

  1. Choose a BLE-Stack 3.00.00 example project

    For reference, see available sample projects that start with simple_

    In this example, we’re going to use simple_peripheral as the starting BLE-Stack 3.00.00 sample project.

    Tip

    All BLE-Stack 3.00.00 sample projects by default contain all the necessary includes and preprocessor defines to utilize improved ICall in FlashROM_Library configurations.

  2. Transfer all modified application files into the example project

    Place modified profile and application files the existing files in the SimpleLink CC2640R2 SDK to match those in BLE-Stack 2.2.1 project.

    Modify main.c in the BLE-Stack 3.00.00 example if additional tasks were added in the BLE-Stack 2.2.1 project.

    In this example, the following files from BLE-Stack 2.2.1 were moved into simple_peripheral BLE-Stack 3.00.00 example:

    • simple_peripheral.c
    • simple_peripheral.h
    • simple_gatt_profile.c
    • simple_gatt_profile.h

    Note

    The folder structure has changed, see SDK root folders.

    Attention

    For applications using Directed Advertisements comment out #define GBM_GATT_NO_CLIENT in gapbondmgr.c of BLE v3.0.0 project to remain compliant with the Bluetooth Core Specification Version 4.2.

    1
2
3
4
5
    #ifdef GATT_NO_CLIENT
#ifndef GBM_GATT_NO_CLIENT
//#define GBM_GATT_NO_CLIENT // <-- Comment this out
#endif // !GBM_GATT_NO_CLIENT
#endif // GATT_NO_CLIENT

    See Directed Advertisements as GATT Server for more information.

  3. Include icall_api.h if Stack/ICall APIs are used. Add the following #include AFTER all other includes for source files using Stack/ICall APIs.

    In this example, add:

    #include "icall_api.h"

    into the following files AFTER all other includes. In for the simple_peripheral port, add this into these files:

    • simple_peripheral.c
    • simple_gatt_profile.c

    For more information regarding icall_api.h see Improved ICall Architecture (ICall Lite).

    Danger

    All Stack/ICall APIs are listed in icall_api.h. If any APIs are used without icall_api.h, build and or link errors may occur with erratic runtime behaviors!

  4. Convert the application to use the TI-RTOS Event module.

    ICall/Stack now synchronize with threads with the TI-RTOS Event Module instead of the TI-RTOS Semaphore module.

    In this example, simple_peripheral needs to modified as shown in ICall Utilizes the TI-RTOS Event Module Instead of Semaphores.

  5. Apply changes from TI-RTOS drivers used in BLE-Stack 2.2.1 to the TI-RTOS drivers included with the SimpleLink CC2640R2 SDK.

    TI-RTOS Kernel is now packaged with the SimpleLink CC2640R2 SDK. When migrating from the BLE-Stack 2.2.1, the following drivers have changed. Please see the changes to these files between TI-RTOS for SimpleLink CC13xx/CC26xx 2.14.01.20 with the supplied headers in the SimpleLink CC2640R2 SDK.

    • PDMCC26XX.h
    • PDMCC26XX_util.h
    • PINCC26XX.h
    • PWMTimerCC26XX.h
    • UARTCC26XX.h
    • WatchdogCC26XX.h

    Also, refer to the Upgrade and Compatibility Information for additional information and the TI-RTOS examples included with SimpleLink CC2640R2 SDK.

    For additional information on how BLE-Stack 3.00.00 uses TI-RTOS see TI-RTOS Overview

    For any utilized TI Drivers, review TI-RTOS Kernel Users Guide and Driver APIs

    In this example, simple_periphral includes paths need to modified. The TI-RTOS DisplayDriver driver has been relocated to the following location:

    1
2
    #include <ti/mw/display/Display.h> // NOT CORRECT
#include <ti/display/Display.h>    // CORRECT

  6. Build stack project

    • Select FlashROM_Library build configuration for the Stack project in IDE.
    • Build the Stack project. In the Output Folder of the IDE, a library file will be generated.

    The BLE-Stack 3.00.00 simple_peripheral example Project has the following configurations related to Library builds.

    App Build Configs Stack Build Configs
    FlashROM FlashROM
    FlashROM_StackLibrary FlashROM_Library

    If a linked stack and application image is desired, a the library project must be built in the FlashROM_Library configuration and the application project must be builts in the FlashROM_StackLibrary configuration. FlashROM_Library only generates a library for the application project to link with. As a result, flashing the stack project is impossible with this build configuration.

    FlashROM build configurations implement a boundary that is generated by the frontier boundary tool.

  7. Build application project

    • Select FlashROM_StackLibrary build configuration for the Application Project in IDE.
    • Build and flash the project onto the CC2640R2F.

    At this point, you should have a functional BLE-Stack 3.00.00 project running on the CC2640R2F.

ICall Utilizes the TI-RTOS Event Module Instead of Semaphores

Applications for BLE-Stack 3.00.XX projects now use the TI-RTOS Event module instead of the TI-RTOS Semaphore module to implement stack-application ICall messaging and synchronization. The following items need to be changed when porting applications from BLE-Stack 2.2.1 to BLE-Stack 3.00.00. Existing applications that utilize Semaphores for non-ICall aware tasks do not need to adapt to the Event module.

For more information on how to use the Event module, see Event and the Event Synchronization Module section the TI-RTOS Kernel Users Guide

Tip

To compare the changes required to use the TI-RTOS Event module instead of its Semaphore module in your application, see changes between simple_peripheral.c in BLE-Stack 2.2.1 and BLE-Stack 3.00.XX

  1. Change include paths from Semaphore to Event module and add icall_api.h into your application.

    1
2
3
    #include <ti/sysbios/knl/Semaphore.h> //Remove
#include <ti/sysbios/knl/Event.h>     //Add
#include "icall_api.h                 //Add

  2. Change the type ICall_Semaphore to ICall_SyncHandle

    1
2
    static ICall_Semaphore sem;           //Remove
static ICall_SyncHandle syncEvent;    //Add

    Replace any references to sem with syncEvent.

  3. Change existing application semaphores to Event types. Previously, semaphores relied on user-defined preprocessor defines. The Event module uses TI-RTOS Event IDs.

    Remove

    1
2
3
4
    #define SBP_STATE_CHANGE_EVT                  0x0001  //Remove
#define SBP_CHAR_CHANGE_EVT                   0x0002  //Remove
#define SBP_PERIODIC_EVT                      0x0004  //Remove
#define SBP_CONN_EVT_END_EVT                  0x0008  //Remove

    Add

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
    // Internal events for RTOS application
#define SBP_ICALL_EVT                         ICALL_MSG_EVENT_ID  // Event_Id_31
#define SBP_QUEUE_EVT                         UTIL_QUEUE_EVENT_ID // Event_Id_30
#define SBP_STATE_CHANGE_EVT                  Event_Id_00         // Add
#define SBP_CHAR_CHANGE_EVT                   Event_Id_01         // Add
#define SBP_PERIODIC_EVT                      Event_Id_02         // Add
#define SBP_CONN_EVT_END_EVT                  Event_Id_30         // Add

#define SBP_ALL_EVENTS                       (SBP_ICALL_EVT        |
                                              SBP_QUEUE_EVT        |
                                              SBP_STATE_CHANGE_EVT |
                                              SBP_CHAR_CHANGE_EVT  |
                                              SBP_PERIODIC_EVT     |
                                              SBP_CONN_EVT_END_EVT)

  4. Relocate the global events flag. Remove the global uint16_t events variable and place uint32_t events into SimpleBLEPeripheral_taskFxn() as a local variable.

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
    #if defined(FEATURE_OAD)
// Event data from OAD profile.
static Queue_Struct oadQ;
static Queue_Handle hOadQ;
#endif //FEATURE_OAD

// events flag for internal application events.
static uint16_t events; // Remove

// Task configuration
Task_Struct sbpTask;
Char sbpTaskStack[SBP_TASK_STACK_SIZE];

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
    static void SimpleBLEPeripheral_taskFxn(UArg a0, UArg a1)
{
    uint32_t events; // Add

    // Initialize application
    SimpleBLEPeripheral_init();

    // Application main loop
    for (;;)
    {

        // Waits for an event to be posted associated with the calling thread.
        // Note that an event associated with a thread is posted when a
        // message is queued to the message receive queue of the thread
        events = Event_pend(syncEvent, Event_Id_NONE, SBP_ALL_EVENTS,
                            ICALL_TIMEOUT_FOREVER);

        if (events)
        {
            ICall_EntityID dest;
            ICall_ServiceEnum src;

  5. Replace ICall_wait() in Application Task with Event_pend()

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
    static void SimpleBLEPeripheral_taskFxn(UArg a0, UArg a1)
{
   // Initialize application
   SimpleBLEPeripheral_init();

   // Application main loop
   for (;;)
   {
       // Waits for a signal to the semaphore associated with the calling thread.
       // Note that the semaphore associated with a thread is signaled when a
       // message is queued to the message receive queue of the thread or when
       // ICall_signal() function is called onto the semaphore.
       ICall_Errno errno = ICall_wait(ICALL_TIMEOUT_FOREVER);  // Remove

       if (errno == ICALL_ERRNO_SUCCESS) // Remove
       {
            ICall_EntityID dest;
            ICall_ServiceEnum src;

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
    static void SimpleBLEPeripheral_taskFxn(UArg a0, UArg a1)
{
    uint32_t events;

    // Initialize application
    SimpleBLEPeripheral_init();

    // Application main loop
    for (;;)
    {
        // Waits for an event to be posted associated with the calling thread.
        // Note that an event associated with a thread is posted when a
        // message is queued to the message receive queue of the thread
        events = Event_pend(syncEvent, Event_Id_NONE, SBP_ALL_EVENTS,
                            ICALL_TIMEOUT_FOREVER); // Add

    if (events) // Add
    {
        ICall_EntityID dest;
        ICall_ServiceEnum src;

  6. Replace Semaphore_post() with Event_post() and remove any references to the previously used events flag.

    1
2
3
4
5
6
7
8
    static void SimpleBLEPeripheral_clockHandler(UArg arg)
{
    // Store the event.
    events |= arg; // Remove

    // Wake up the application.
    Semaphore_post(sem); // Remove
}

    1
2
3
4
5
6
7
8
9
    if (events & SBP_PERIODIC_EVT)
{
    events &= ~SBP_PERIODIC_EVT; // Remove

    Util_startClock(&periodicClock);

    // Perform periodic application task
    SimpleBLEPeripheral_performPeriodicTask();
}

    1
2
3
4
5
    static void SimpleBLEPeripheral_clockHandler(UArg arg)
{
    // Wake up the application.
    Event_post(syncEvent, arg); // Add
}