Developing TI RTOS Applications and BLE Profiles

Developing TI RTOS Applications
and BLEProfiles on TI CC2650
SensorTag
A Project performed under
The LNMIIT Undergraduate Summer Internship Programme 2016
Submitted by:
Abhishek Choudhary, 14UCC001
Sudhanshu Gupta, 14UEC107
Sumit Sapra, 14UEC108
Surya Prakash Venkat, 14UEC109
Under the guidance of
Dr. Santosh Shah, Assistant Professor
Department of Electronics and Communication Engineering
The LNM Institute of Information Technology
Jaipur

Abstract
The project aims to develop Bluetooth® Low Energy (BLE) profiles on the Texas
Instruments SimpleLink™CC2650 SensorTag (TI-SensorTag), a low powerIoTsensor
device by Texas Instruments (TI), to transmit data wirelessly according to any
specific application.
The TI-SensorTag uses the TI RealTime Operating System(TI-RTOS) which gives an
interface for the user to develop applications using the SensorTag.
Theprojectinvolved a thorough study of theTI-RTOS, followed by hands-on labs to
build simple applications using multiple concepts of real timeoperating systems. A
developmentenvironmentwas set up under theCode Composer Studio (CCS) by TI,
a GUI tool that was used extensively throughout the internship. At a later stage
while working with BLE, we connected the SensorTag to an android phone having
the BLE Scanner app.
An introduction to Bluetooth® Low Energy followed the successful completion of
learning and developing applications on the TI-RTOS. Elaborate theoretical and
practical tutorials provided by the TI SimpleLink Academy helped us learn and
achieve the target of creating custom BLE profiles on the SensorTag.
By completing this project we have gained a deep and intricate understanding of
the Texas Instruments Real Time Operating System (TI-RTOS) and the software
stack of the Bluetooth Low Energy (BLE), the GATT and GAP services and
characteristics.

Contents
1. Introduction 1
i. The TI SensorTag 1
ii. TI-RTOS 4
iii. Bluetooth® Low Energy 6
2. Setting up the development environment 7
3. Getting started with TI-RTOS 7
4. Hands-on with TI-RTOS 9
5. BLE Fundamentals 12
6. Working with Bluetooth® Low Energy 18
7. Conclusion 23

1
INTRODUCTION
The TI SensorTag
TheTexas Instruments SimpleLink™CC2650 SensorTag (TI-SensorTag) is an IoTlow
power MEMS sensors device that supports Bluetooth® Low energy, WiFi, ZigBee®
and 6LoWPAN. It is expandable with DevPacks to make it easy to add our own
sensors or actuators. The SensorTag is ready to use right out the box with an iOS
and Android app, with no programming experience required to get started.
The new SensorTag is based on the CC2650 wireless MCU, offering 75% lower
power consumption than previous Bluetooth low energy products. This allows the
SensorTag to be battery powered, and offer years of battery lifetime from a single
coin cell battery.
The Bluetooth Low Energy SensorTag includes iBeacon technology which allows
your phoneto launch applications and customizecontentbased on SensorTag data
and physical location. The product includes mainly the following features:
 10 sensors including support for light, digital microphone, magnetic sensor,
humidity, pressure, accelerometer, gyroscope, magnetometer, object
temperature, and ambient temperature.
 High performance ARM Cortex M3 (CC2650).

2
 Cloud connectivity. Onecan access and controla SensorTag fromanywhere,
with seamless integration with mobile apps.
 DevPacks allow us to expand the SensorTag to fit any design.
 Interchangeable between all SensorTag types
 Complete development system: Expandable with $15 debug DevPack, Code
Composer Studio compiler license included.
The CC2650 combines a 2.4-GHz RF transceiver, 128-KB in-systemprogrammable
memory, 20KB of SRAM, and a full range of peripherals. The device is centered on
an ARM® Cortex®-M3 series processor that handles the application layer and
Bluetooth low energy protocolstack and an autonomous radio corecentered on an
ARM Cortex®-M0 processor that handles all the low-level radio control and
processing associated with thephysicallayer and parts of thelink layer. Thesensor
controller block provides additional flexibility by allowing autonomous data
acquisition and controlindependentof theCortex-M3 processor, further extending
the low-power capabilities of the CC2650.
Block Diagram of the SimpleLink CC26xx

3
Software layers on the CC26xx:
The following image shows a brief outline of the software layers in a CC2650 (or
any MCU in the CC26xx family). We now discuss the TI-RTOS, the real time
operating system that manages the underlying control and interfacing inside a TI
SensorTag.
The SensorTag has a JTAG connector which we use to connect to a TI SimpleLink
SensorTag Debug Devpack that can connect to a computer’s USB port in order to
burn our code to the flash memory of a sensortag to work on the firmware in it.

4
TI-RTOS
TI-RTOS is an embedded tools ecosystemcreated and offered by TI for usein a wide
range of their embedded processors. It includes a real time operating system
component called "TI-RTOS Kernel" (formerly known as "SYS/BIOS”) along with
additionalcomponents thatsupportdevicedrivers, networking connectivity stacks,
power management, file systems, instrumentation, and inter-processor
communications like DSP/BIOS_Link.
TI-RTOS accelerates developmentschedules by eliminating theneed to createbasic
systemsoftwarefunctions fromscratch. Itscales froma minimalfootprintreal-time
multitasking kernel - TI-RTOS Kernel (SYS/BIOS) - to a complete RTOS solution
including protocol stacks, multicore communications, device drivers and power
management. By providing essentialsystem software components pre-tested and
pre-integrated, it enables developers to focus on differentiating their application.
TI-RTOS provides a widerangeof systemservices to an embedded application such
as preemptivemultitasking, memory managementand real-timeanalysis. Because
TI-RTOS can be used in such a wide variety of different microprocessors with very

5
different processing and memory constraints, it was designed to be highly
configurable.
Code snippets of LED tasks and button semaphore running in the RTOS kernel
We will explore further about TI RTOS at a later stage.

6
Bluetooth® Low Energy (BLE)
Bluetooth low energy (LE) (also called Bluetooth Smart™ or Bluetooth
4.0+) is the power and application friendly version of Bluetooth that
was built for the Internet of Things (IoT).
The BLE system was created for the purpose of transmitting very small packets of
data at a time, consuming significantly less power than classic Bluetooth devices.
Devices that can support both Bluetooth classic and BLE are referred to as dual-
mode devices and go under the branding Bluetooth® Smart Ready. Typically a
mobile smartphone or laptop computer will be a dual-mode device. Devices that
only supportBLEarereferred to as single-modedevices and go under thebranding
Bluetooth® Smart. Devices for which low power consumption is a primary concern,
such as those thatrun on coin cellbatteries, eg. CC2650 comeunder this category.
BLE Protocol Stack basics
TI's BLE-Stack™ 2.2.0 software development kit (SDK) for TI-SensorTag is a full-
featured Bluetooth 4.2 certified stack that includes all necessary software and
sample applications to quickly get started with the development of single-mode
Bluetooth low energy (BLE) applications.

7
SETTING UP THE DEVELOPMENT ENVIRONMENT
The Integrated Development Environment (IDE) used in the project was Code
Composer Studio (CCS). We adopted a systematic approach to acquaintourselves
with the environment.
To begin with, we imported executable files from the resources provided on TI’s
homepage. After successfully making a connection to the SensorTag over the CCS
environment we configured the libraries associated with the executable files and
gained an idea of the files structure.
Next, we added a .C file from TI’s resource page and gained an understanding of
building projects. Followed by this we analysed the code and learnt how to debug
the files using the development environment.
Now, after gaining a hands – on experience of the development environment we
proceeded to usetheconcepts of TI-RTOS. To understand TI-RTOS in much greater
detail we will explore and elaborate some key features associated with TI-RTOS.
Getting Started with TI-RTOS
The TI-RTOS Kernelis simply a library of services that users can add to their system
to perform common tasks such as memory management, real-time analysis,
scheduling (of threads) and synchronization (having one thread send a signal to
another).
TI-RTOS is a pre-emptivescheduler. For a real-timedevicesuch as theCC26xx, there
is a need for proper scheduling to run multiple threads at different times in least
time and memory footprint.
The following figure mentions the characteristics of the SYS-BIOS.

8
TI-RTOS Kernel provides support for several different types of threads in an
embedded system.
 Hardware Interrupt (Hwi): support threads initiated
by a hardwareinterrupt. HardwareeventtriggersHwi
to run. BIOS handles context save/restore, nesting.
Hwi triggers follow-up processing. Priorities set in
silicon
 Software Interrupt (Swi): structured to be similar to
Hwis, but allow processing to be deferred until after
a hardware interrupt has completed. Software posts
Swito run. Performs Hwi‘follow-up’ activity (process
data). Up to 32 priority levels (16 on C28x/MSP430)
 Task: a discrete thread that can execute or block
while waiting for an event to occur. Usually enabled
to run by posting a ‘semaphore’ (a task signaling
mechanism). Designed to run concurrently – pauses

9
when waiting for data (semaphore). Up to 32 priority levels (16 on
C28x/MSP430)
 Idle (Background): the lowest priority thread that only runs when no other
thread is ready to execute. Runs as an infinitewhile(1) loop. Users can assign
multiple functions to Idle. Single priority level.
Hands on with TI-RTOS
We worked so far on the CCS in building simple projects. After having understood
several key concepts of TI-RTOS through extensive study of theory and
observations of allcases and examples, weset outto test our understanding of the
coreconcepts: BIOS Mechanics (including BIOS Config files which setup parameters
for linking the libraries and compilation), Hwi, Swi, Clock, and tasks.
We toggled the two LEDs on the sensortag, as two separate threads of different
priority levels that wechanged in each program thatweran. Button presses would
act as semaphores for these threads – an LED (task 1) would keep running in the
background, when suddenly a button press (semaphore) would causetheotherLED
(task 2) to run. We tried this using both software interrupts and tasks in each trial
for thesameto understand thedifferencebetween theseconcepts for pre-emptive
scheduling.
Debugging: There are two different debug tools in the TI RTOS kernel :
UIA - Unified Instrumentation Architecture: A target-side API that allows users to
add visibility and debug features to their code. It provides visibility into what is
going on in the system:
• Logging – “printf()-lite”
• Execution Graph – software “logic analyzer”
• Load – CPU/Thread loading
• UIA replaces the older RTA tools – requires “Logging Setup”
ROV – RTOS Object Viewer – to see status of BIOS objects in the system (when
halted).

10
One of the mostcommon debug function calls is printf() which prints a messageto
the console screen. While this is helpful, it will typically be ripped out before
production. Also, a printf() on some processors takes 10K bytes and 10K cycles to
run because math engines (DSPs) are not made for processing strings.
The alternative is to use the Log functions within UIA to print a string to a custom
window in the System Analyzer (host-side tool). This function takes 40 bytes and
40 cycles to run – very small.
In addition to Logs, UIA supports loads (CPU, thread loading) as wellas an execution
graph showing theuser theequivalentdiagramof a logic analyzer –exceptitis built
into BIOS.
In thehands on, we wereableto setup UIA and usethe SystemAnalyzer to seethe
results when the processor is halted. The Execution Graph is an extremely useful
and versatile tool. It is based on time so that you can see, in time, when events
occur in the system.

11
The below two screenshots show execution graphs demonstrating time spent in
separate tasks run in our programs:
a. Pre-empting between two tasks running simultaneously
b. Time spent between idle thread, clock and task:
By the time we ended our labs with hands-on with TI-RTOS, we gained experience
in debugging with RTOS, semaphores, RTOS concepts such as Task (thread, task –
sleep), Semaphore, Interrupt handling and Execution graphing.

12
BLE Fundamentals
We now moved to work on the BLE stack to control the flow of data between the
SensorTag and a target device. Let us first address the key fundamentals that
constitutetheentireworking of BLEbetween two devices in order to gain an overall
understanding of what was to be done and how we did it.
The Bluetooth Protocol Stack is divided into two categories: the controller and the
host. Each category has sub-categories, which perform specific roles. The two
subcategories we are going to look at is the Generic Access Profile (GAP) and the
Generic Attribute Profile (GATT).
 GAP defines the general topology of the BLE network stack.
 GATT describes in detailhow attributes (data) aretransferred oncedevices
have a dedicated connection.
ATT and GATT Introduction
For Bluetooth Low Energy, communication occurs over the air according to the
Attribute Protocol (ATT). From a BLE application point of view however, data is
exchanged using the Generic Attribute Protocol (GATT) which can be viewed as a
meta-layer on top of ATT. GATT specifically focuses on how data is formatted,
packaged, and sent according to its described rules.
In theBLEnetwork stack, the ATT is closely aligned with GATT, whereGATT sits directly
on top of ATT. GATT actually uses ATT to describe how data is exchanged from two
connected devices.
Generic Access Profile (GAP)
Getting Connected
There are two mechanisms a BLE device can use to communicate to the outside
world: broadcasting or connecting. Thesemechanisms aresubjected to theGeneric
Access Profile (GAP) guidelines. GAP defines how BLE-enabled devices can make
themselves available and how two devices can communicate directly with each
other.
A device can join a BLE network by adopting these roles specified in GAP:

13
Broadcasting: These roles don't have to explicitly connect to one another to
transfer data.
 Broadcaster: A device that broadcasts public advertising data packets,
such as how long a button has been pressed.
 Observer: A devices that listens to the data in theadvertising packets sent
by thebroadcaster. No connection happens between thebroadcaster and
observer.
Connecting: These roles must explicitly connect and handshake to transfer data.
These roles are more commonly used than the broadcasting roles.
 Peripheral: A device that advertises its presence so central devices can
establish a connection. After connecting, peripherals no longer broadcast
data to other central devices and stay connected to the device that
accepted connection request.
o Peripherals arelow-power becausethey only have to send beacons
periodically. Central devices are responsible for starting
communication with peripherals.
o SensorTag is an example of a BLE peripheral.
 Central: A device that initiates a connection with a peripheral device by
first listening to the advertising packets. A central device can connect to
many other peripheral devices.
o When the central device wants to connect, it sends a request
connection data packet to the peripheral device. If the peripheral
device accepts the request from the central device, a connection is
established.
o Your computer is an example of a BLE Central device when it
connects to SensorTag.
Once You're Connected
Central Devices Can Update Connection Parameters: The central device typically
establishes the connecting parameters between the peripheral device and itself.
The central device can only modify the connecting parameters. However, the
peripheral device can ask the central device to change the connection parameters.

14
Peripheral or Central Devices Can Terminate Connections: Connections might end
for a variety of reasons: a device's battery mightdieor network interferencemight
cause the connection to fail. Devices can also intentionally disconnect from their
peers.
Generic Attribute Profile (GATT)
Roles
Similar to GAP, there are certain roles that interacting devices can adopt:
 Client: Typically sends a request to the GATT server. The client can read
and/or write attributes found in the server.
 Server: One of themain roles of the server is to store attributes. Oncethe
client makes a request, the server must make the attributes available.
Client-Server Relationships
One example of a client-server relationship is as follows: I push a button on
SensorTag and I want the computer to read that information. SensorTag acts as a
server and provides information. The computer acts as a client, reading that
information.
GAP and GATT roles areessentially independentof oneanother. Peripheralor central
devices can BOTH act as a server or client, depending on how data is flowing. In
contrast to the above example, if I wanted to send an update from from the
computer to SensorTag, the computer acts as a server and SensorTag acts as a
client.
Bluetooth SIG has defined several Profiles for the use of these protocols to ensure
interoperability. A Profile is a written document (or a cryptic voicemail) describing
how a number of GATT Services and GATT Characteristics (defined separately from
the Profile) should be used to achieve a certain application. These will be briefly
described below.
Attribute
An Attribute is the smallest addressable unit of data used by ATT and GATT. It is
addressed via a 16-bit handle, ithas a type, which is an UUID that can be 16, 32 or
128 bits long, and it has a data field which can be up to 512 bytes long.

15
Summarized, the Attribute Protocol defines an attribute to consist of
Handle – The 'address'of the Attribute when accessed via the AttributeProtocol
UUID – The 'type' of the Attribute
Value – Array of bytes interpreted differently depending on
the UUID (type).
Characteristic
Several of these attributes are needed to define a Characteristic. A Characteristic
always consists of atleasta Valueattribute, whereyou in your Profilehavedecided
what thevaluemeans, and a Declaration. TheDeclaration always comes beforethe
value attribute and describes whether the value attribute can be read or written,
contains theUUID of the Characteristic and the handle of theCharacteristic Value's
attribute.
Other attributes of a characteristic can give a description of the characteristic in
string format, or describe how the Value should be interpreted, or configure
whether the GATT Server may send Notifications about value changes. These are
called Descriptors.
Example Characteristic
A peer device can only address attributes via their handles and can in fact only
operate over theair on attributes. There is no conceptof services or characteristics
in the radio protocol, only attributes.
Thehierarchy of Service→Characteristic →Valueis simply meta-data derived from
the attributevalues and UUIDs. Hencethe names Attribute Protocol(ATT) which is
theover-the-air protocoland Generic AttributeProtocol(GATT) which is layered on
top.
Handle UUID Value
16 bits
16 or
128 bits
1 to 512
bytes.

16
An example of a characteristic as seen 'over the air' in theform of two attributes is
shown below:
Handle UUID Value What
.. ... .... ....
31 0x2803 02:20:00:AA:BB Characteristic
Declaration
32 0xBBAA 41:42:43 Characteristic
Value
33 0x2803 02:22:00:AA:CC Characteristic
Declaration
34 0xCCAA 15 Characteristic
Value
Handle: Wementioned itin whiletalking about attribute earlier. In theTI BLEStack,
handles areassigned starting from1 when theattributeis registered with theGATT
Server. If the firmware doesn't change, the handle is always the same.
UUID: It tells a peer device how the value of the Attribute should be interpreted.
For example, 0x2803 is defined in the specification to mean Characteristic
Declaration, while 0xBBAA is something made up for this example. Proprietary
(non-SIG-adopted) services mustuse 128-bitUUIDs to avoid collision, unless a 16-
or 32-bit UUID is acquired from the SIG.

17
Attribute Value: As described above, the value of an attribute can be up to 512
bytes long, and is given meaning by the UUID of the attribute.
Example Characteristic Declaration
The value of the Characteristic Declaration attribute with handle 31 above is
interpreted like this:
Byte(s) Definition Value Meaning
0 Char Value Permissions 02 Permit Read on Characteristic Value
1-2 Char Value's ATT handle 20:00 0x0020 = 32, as seen above
3-n Characteristic UUID AA:BB 0xBBAA
Example Characteristic Value
For the attribute value 41:42:43 of the Characteristic Value attribute it is up to us
to define how the value is interpreted, because it's not defined by the Bluetooth
SIG. As an ASCII-string it would be 'ABC'.
Characteristic Value: The attribute with handle 32 above gets the moniker
Characteristic Value because the Characteristic Declaration says the actual useful
valueof thecharacteristic can befound athandle32, and becauseits UUID matches
the UUID found in the Characteristic Declaration.
Client Characteristic Configuration Descriptor (CCCD)
It is an attribute with the UUID 0x2902 and is readable and writable. The value a
GATT Client writes to this attribute will determine whether the GATT Server is
allowed to send Notifications (if 0x0001 is written) or Indications (or 0x0002).
Service and Profile
A Service is a collection of characteristics. A Profile defines a collection of one or
more services and define how services can be used to enable an application or
use case.

18
Working with Bluetooth® Low Energy
We did our hands-on with the CC2650 SensorTag to work with BLE in two stages.
At first, we got ourselves acquainted to the debug environment (BLE SDK) and a
BLE enabled cell phone having the BLE Scanner android app to establish
connectivity between the GATT Server (CC2650) & Client (mobile) and read
characteristic data of the GATT profile.
We imported a ProjectZero project into CCS, and after connecting the SensorTag
and configuring the debugger connection, we built the project. We connected
TeraTerm, a terminal program to observe serial output from the SensorTag.
Output as seen in the terminal:
This shows theuser application initializing the threeservices LED, Button and Data,
and setting initial values for the characteristics in those services. Callbacks are
received from the stack that the device is ready and has started advertising its
presence. The device address is also mentioned.
We then proceeded to use the BLE Scanner app on an android phone in order to
let it interact with the Bluetooth low energy device as a Central device towards it,
so that we could navigate exposed services. We could navigate the attributetable,
and read the profile and discovery data.
We created custom characteristics, edited the characteristic values, changed the
read/write permissions and switched between enabling/disabling notifications.

19
We clearly observed that GATT imposes a meta-layer on top of ATT. Meaning that
an Attribute is an ATTthing, whereas a Serviceis a GATT thing that uses Attributes.
Now wetook up thetask of accessing data from a sensor of theSensorTag through
the Project zero BLE profile, and get notified about it. In this case, we played with
the ButtonService, i.e. stateof theButton on the device. We understood the access
properties as to be defined in the gattservapp.h and the Client Characteristic
Configuration for the Service.
Our next and final task of this step was to customise our application completely,
i.e. changing the Advertisement Data.

20
n the second stage, we went on to create a BLE Custom Profile. We studied the
GATT and ATT protocols that Bluetooth Low Energy data exchange is based on,
and implemented a customBluetooth service using the APIs provided in the TI BLE
SDK, and a basic code generator for custom services.
It involved modifying the source code in the ProjectZero project to include the
required services and modify the behavior according to our own specification.
We first generate the shell for our service from the example service generator
provided by TI and place it in a project imported from ProjectZero renamed as
SunlightPeripheralApp. Once we add a new service to the GATT server having the
empty shell, we build the project and dowload it to the device.
I

21
Now theGATTserver knows whereto read theattributetableof theservice, so any
change to the table is reflected in what a remote client sees when it performs a
service and characteristic discovery.
We add a characteristic called sunlightValue to theattribute table, having theUUID
0x2BAD, readable and ableto send notifications. Weimplemented the handling of
read requests, the API for the application to set a value, and the mechanism for
sending notifications, if enabled.

22
Next, we add API and Callback Handling. By doing so, we would start getting data
when we try to read a characteristic. We then proceed to attempt sending a
notification to the connected GATT Client every time we update the value of the
SunlightValue characteristic, which is whenever the button is pressed.
With a custom BLE profile now in place, we can add a TI-RTOS clock object,
configure it, start it, and create a Swi handler and a Task context handler. In a real
world application using the CC2650, this can be used for reading the sensor value
and update the attribute value.

23
Conclusion
In summary, we first learnt the concepts of TI-RTOS and applied them for
a hands-on experience on the Code Composer Studio. We learnt how to
build and debug projects using the CCS interface and the process of
scheduling tasks and interrupts based on the concepts of SYS/BIOS.
Following this, we used tools like execution graphs to analyse different
tasks and observe execution times and how to optimize tasks and ensure
better scheduling of processes. After this, we immersed ourselves with
understaning the fundamentals of Bluetooth Low Energy. We first
understood the role of devices in BLE, then understood GATT and GAP.
We used the application BLE Scanner on the smartphone with the phone
acting as a GATT client and the SensorTag as a GATT server. We were
able to modify charactersitics on the SensorTag and understood the
fundamental features behind services, characteristics and attributes.
After gaining a thorough understanding of the fundamentals we
proceeded to make our own custom profile using the BLE Software
Stack. Using the GATT and ATT protocols we were able to establish a
connection between our client and server and transfer data over the air.

24
References:
 TI SimpleLink Academy : http://software-
dl.ti.com/lprf/simplelink_academy/overview.html
 TI RTOS Workshop :
http://processors.wiki.ti.com/index.php/Introduction_to_the_TI-
RTOS_Kernel_Workshop
 CC2650 BLE Software Developer’s Guide :
http://www.ti.com/lit/ug/swru393c/swru393c.pdf

Developing TI RTOS Applications and BLE Profiles

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Developing TI RTOS Applications and BLE Profiles (20)

Recently uploaded (20)

Developing TI RTOS Applications and BLE Profiles