SerialBLEbridgeV 1 4 1

Bluetooth Low Energy Wiki Main Page

Sample App Overview

This page details a Serial-to-BLE bridge sample application which can be used as a basis for adding serial communication to an existing project, creating a simple serial packet parser, and achieving maximum over-the-air throughput.  The BLEbridge is a modified version of the simpleBLEperipheral project and has both a UART and SPI configuration.  It will act as a BLE slave during a connection and a UART / SPI slave for serial communication.  Note that version 1.4.0 or later of the BLE stack is needed in order to take advantage of the more robust serial drivers, and the patch below works specifically for version 1.4.1.  Also note that there is no UART / SPI master sample code provided: it is up to the user to create code for their own MCU.  This guide assumes you have some familiarity with the UART / SPI drivers and does not cover the specific mechanics of each.  Here is a general overview of the system:

Note that there are three driver configurations considered here:

• SPI (with or without power management): using MRDY/SRDY handshaking. The handshaking will be the same regardless of whether or not power management is enabled.
• UART (without power management): there is no handshaking needed as the device is not going to sleep. Therefore, only the Tx and Rx lines are needed.
• UART (with power management): using CTS/RTS handshaking to control sleep.

Requirements

• v1.4.1 (or later) of the TI BLE stack
  
• 1 SmartRF05 EB + CC2541 EM
  
• 1 CC2540 USB Dongle
• Serial cable to connect from computer to SmartRF (possibly USB-to-Serial)
  
• IAR 9.20 or later

Project Files

All of the necessary project files are contained in this patch: File:BLE Bridge v 1 4 1.zip

To apply the patch, open the .zip file and copy the Project folder to C:\Texas Instruments\BLE-CC254x-1.4.1 choosing to replace all conflicting files.

Once the project is opened with IAR, you can select the appropriate serial protocol to use by selecting the CC254-SPI, CC2541-UART, or CC2541-UART-PM configurations.

Software Architecture Overview

This section will briefly describe the software architecture of the BLEbridge app.  Most of the relevant code will be found in the main application file (BLE_Bridge.c) and the serial interface application file (serialInterface.c).  The flow of data from host MCU serial transmission to over-the-air BLE transmission is shown below.  First, data is received via DMA into the serial driver buffer: the 256byte spiRxBuf for SPI and the 128 byte uartDMAcfg.rxbuf for UART.  Once the respective driver polls and discovers there is Rx data, it will notify the serial parser call back function (cSerialPacketParser).  The serial packet format that we are using for tx data in this project is one "length" byte followed by "length" amount of data bytes to be sent over-the-air.  The parser will first read the length byte then, if the driver has received "length" amount of bytes, read these bytes into a 500-byte application layer circular buffer (serialBuffer).  If the driver hasn't received "length" amount of bytes, the parser will exit and wait for all of the bytes to be received before moving the data to SerialBuffer.

The application polls for serial data to send over the air via an event which is triggered by an OSAL timer every 7 ms: SBP_SEND_EVT.  During this event, the application checks to see if there is any unsent data in the circular buffer - data that has not yet been sent over the air.  If there is, the sendData() function will divide this unsent data into (at maximum) 20 byte packets which will be sent to the controller for BLE transmission using a GATT_Notification with an arbitrary handle.  If you want this code to co-exist with existing profiles you should make sure to choose a suitable handle.  Because the controller only has 4 tx buffers available to store data to be sent during a connection event, it is only possible to send 4 notificatoins per connection event.

Ble bridge sw architecture.png

Once a notification is sent down to the controller this data is considered to be sent since the controller will deal with any retries and eventually send the data over-the-air.  Therefore, at this point a confirmation is sent back over the serial layer to the host MCU indicating how many bytes were sent over the air.  This packet will be of the format "AB" "A5" "LEN" where LEN is the amount of bytes sent over-the-air.  The host MCU should use these packets for flow control by using a credit system starting with 500 credits (the size of the circular serialBuffer).  However many bytes are sent serially to the CC2541 must be subtracted from the credit count.  These credits should then be added back once the confirmation packet is received from the CC2541 indicating how many bytes were sent over the air.  This will prevent the host MCU from overwriting unsent data in the circular buffer.  Another option is to increase the size of the circular buffer.  On the topic of flow control, the central device that the BLEbridge is connecting to via BLE should ensure that it will allow connection updates.  This will allow the BLEbridge to update the connection interval to 10 ms, thus taking full advantage of the 7 ms application polling task to empty the circular buffer and send data over-the-air.

Bidirectional Communication

This project also includes the capability to forward received GATT data to the host MCU via UART / SPI. This was accomplished in the simpleGATTprofile_bridge profile which is a modification of the simpleGATTprofile used in the simpleBLEperipheral project: simple Profile Characteristic 3 is now a 20-byte writeable characteristic. simpleProfileChangeCB() in the application code is called when this characteristic is written to which in turn will call sendDataToHost() to send the received data serially to the host. Data written over-the-air to this characteristic must be of the following format: one "length" followed by "length" data bytes. The serial data transmitted to the host MCU will then be of the format "AB" "AD" "data[0]" "data[1]" ... "data[LEN]"

Note that this is a a very basic sample. The packet format, for both over-the-air and serial data, should be modified as desired.

Configurable Parameters

Described in this section are some parameters that you may want to configure based on your desired throughput and power consumption needs.

• SBP_SEND_EVT_PERIOD: how often the application tasks polls the circular buffer to send data.  The device must wake up each period to service this event so increasing this will decrease throughput and power consumption.
  
• desired_min_interval and desired_max_interval: connection interval used for connection parameter udpate.  Increasing this will cause the device to wake up less frequently for radio transmission, thus lowering the power consumption and throughput.
  
• RX_BUFF_SIZE: size of the circular serial  buffer
  
• NPI_UART_BR: baud rate for serial communication
  
• NPI_UART_FC: whether or not to use hardware flow control for serial communication. This should be set to FALSE for the standard UART (no PM) configuration.
  

Other Considerations

This section will present some other points of caution or things to consider when stressing the UART / SPI drivers as the BLEbridge does.

• Prevent the CPU from halting during RF activity.  This is absolutely necessary so and is accomplished via HCI_EXT_HaltDuringRfCmd(HCI_EXT_HALT_DURING_RF_DISABLE);
• Check the return value when using HalUARTWrite() as it possible there is no room in the UART tx buffer and the call will fail.  This is extremely unlikely for the BLEbridge project as we are not transmitting much serial data but in some cases it will occur and you will be forced to retry the write at a later time.
  
• Unless needed, set HAL_LCD=FALSE, HAL_LED=FALSE, and HAL_KEY=FALSE in the preprocessor definitions.  Besides providing more processing time for the serial driver, HAL_KEY must be set to false when using UART with power management because the RTS ISR uses the same port as HAL_KEY.  HAL_LCD must be set to false when using SPI because some LCD pins conflict with the SPI pins.
• Again note that CTS / RTS handshaking will be necessary to use the UART-PM configuration.

Example Captures

coming soon: sample logic captures and over-the-air packet sniffer captures