BLE stack from TI. Custom Application Development
- Tutorial
Hello, Habr!
After writing the previous material about the BLE socket, I met many
people who are interested in the topic of using BLE in their own designs, but there are certain
difficulties in using C programming with the BLE stack for CC2541. Using an
internal controller provides many advantages, in particular: flashing through the air, saving
on an external controller, reducing the number of solder points ...
I decided to split the material into two parts. The first is preparation for work, programming and
debugging. The second is to create your own BLE profile.
1. Preparation for work.
To develop applications for the CC2541, a must-have set is:
- CC-debugger- in-circuit debugger for 8051 TI chips;
- CC2450 USB dongle - in order to quickly and easily check the characteristics of BLE profiles on
a computer screen;
- Well, actually some kind of motherboard with a CC2541 chip.
Ideally these things are combined in a debug set from TI - CC2541 mini DK . I recommend to purchase.
From software we need:
- actually BLE stack ;
- Always be at hand: Smart RF Studio , Flash Programmer , Packet Sniffer ;
- for debugging: BLE device monitor ;
- IAR for 8051 controllersin version from 8.2 (can be taken with a free 30-day
license).
Without unnecessary descriptions, let’s go through the folders of the stack, which are somehow required for
work.
- accessorize - contains the BTool debugging utility, USB dongle drivers, and compiled
images of finished devices;
- components - libraries (OS, peripherals and BLE);
- documents - the folder creates the appearance of documentation for all components and modules;
- projects - examples of projects.
2. IAR IDE, debugging programs.
Let's open the SimpleBLEPerepherial project for example. We are trying to compile ... And I give 7 out of 10 that the
project will not be assembled. The error is due to the fact that the linker cannot fit in memory
specified number of virtual registers. There are two solutions to the problem:
- simply reduce the number of virtual registers from 16 to 8, and do this for each
project, hoping that it will be assembled;
- fix the linker configuration file (in the simple case, it is ti_51ew_cc2540b.xcl). In it
you need:
1) open this file (it lies in the \ Projects \ ble \ common \ cc2540 \ folder) in a text editor;
2) find the line -Z (DATA) VREG + _NR_OF_VIRTUAL_REGISTERS = 08-7F;
3) replace it with -Z (DATA) VREG = 08-7F;
4) enjoy the projects that will begin to assemble.
Having connected the debug board to CC-debugger, we will launch the application on it (Project- Download and
Debug, Debug - Go).
Now, when you press the right button, the key fob goes into Advertising mode, that is,
you can connect to it . We plug into the USB dongle based on CC2540. We have two monitors for working
with this dongle: a convenient BLE device monitor and a hardcore BTool (the installer of the latter is
bundled with the stack). We use the BLE Device monitor.
The most important fields in this window:
• Handle field - serial number of the record in the BLE device services table,
• Type field - indicates the type of record (defines the service record, service characteristic,
configuration of the characteristic or the characteristic itself (its UUID)),
well and The third important field is the Value field . In case of recording a definition
service, this field actually says the UUID of the service.
The documented services are listed here . For us, provided that we are not members of the Bluetooth SIG, 16-
bit service addresses cannot be used. You need to use 128-bit UUIDs. But more on that
later.
The Value field in the record of the characteristic declaration contains:
-UUID of the characteristic (for example,
0xFFF3 in the example),
-number of the record in the device table (in other words, handle - 0x002B in our
case)
-the order of access to the characteristic determined by the bit mask (in the simplest
case - 0x02 - read permission, 0x08 - write permission, 0x10 - alert resolution).
In addition, it is important to draw from this screen that the user variable for reading
or writing is determined by three entries in the device table (definition of the characteristic,
value of the characteristic, description of the characteristic - the first and second fields are required, the declaration of the third is the rule of good tone), and the
variable, which , changing, notifies the application; in addition, it must have
an additional configurator characteristic that enables or disables notification.
Packet Sniffer is also extremely useful for debugging. I won’t tell in detail,
I’ll just say that to work with the packet sniffer you will need to flash the USB dongle firmware
sniffer_fw_cc2540_usb.hex, lying somewhere in the bowels of the sniffer installation folder (by the way, I sincerely hope that you do not have to debug applications at such a low level).
This is how iBeacon packages look in the ether sniffer:
3. The mechanism of functioning of the peripheral BLE device
To begin with, we will examine how the peripheral device works in the SimpleBlePerepherial example.
The main logic of the program is concentrated in the file SimpleBLEPerepherial.c, while the
main function is located in the file SimpleBLEPerepherial_Main.c, but as a rule it
does not make sense to edit it , since it initializes the peripherals and OSAL (some kind of
operating system). Using the BLE stack, we get access to only part of the processor
time (with the lowest priority). This determines, in particular, the programming style: a
large number of callback functions, the absence of infinite loops in the
program body , the maximum use of interrupts ...
The first user-defined function called by OSAL is the SimpleBLEPeripheral_Init function. In it:
-the parameters of the future connection are determined; -the parameters and composition of the data for the advertising are determined;
-registered profiles supported by the device are registered callbacks of these
profiles;
- OSAL displays a message that the device is ready for use.
Further it is important to pay attention to the callback caused by the stack, which determines the parameters
connections, - peripheralStateNotificationCB. The function always allows you to understand whether a
connection is established with the central device or not.
Any actions (control of conclusions, reading of indicators of sensors, etc.) are strongly
recommended to be performed in a periodic task. To do this, you need a function from the
OSAL library - osal_start_timerEx (), which, in addition to the user task identifier, needs
to pass the time after which the system interrupt occurs, and the bit mask of the event,
which is processed in the SimpleBLEPeripheral_ProcessEvent () callback when it occurs.
4. OAD Support
Now we will consider the OAD function - updating the firmware over the air. I note right away that
such a function is available only in chips with 256 kB memory. The most detailed mechanism for
creating applications for OAD is described in the document , but a couple of points are worth clarifying. Firstly, the memory on the chip
is allocated for two images of the program: the current (executable) and the area for the program
received by air. Secondly, a bootloader should be installed on the chip - a bootloader
that, when the device starts, will choose which of the images to start.
Let's try to create an application with the ability to update firmware over the air. First of
all, we will flash the chip with the bootloader firmware. To do this, compile the BIM project located
in the \ Projects \ ble \ util \ BIM folder and load the resulting image into the controller using
Smart RF Flash Programmer (Erase, Programm and Verify action). Next, we will collect the image with
which our device will start: we will assemble the SimpleBLEPerepherial project in the configuration of
CC2541-OAD-ImgA (by the way, the memory markup file that we corrected at the very beginning is
changed in this assembly, so you will have to make similar changes to the file
cc254x_f256_imgA.xcl). We’ll get this image through the Smart RF Flash Programmer (Append and
Verify action ), at this step the most important thing is not to erase the pre-bootloader. Now, having rebooted the
chip and connected to it through the BLE device monitor, we will see OAD support.
Now compile the image for downloading by air and upload it to the chip. To start
compile the configuration of CC2541-OAD-ImgB. Next, in BLE Device Monitor, go to the
File-programm tab. Make sure that the chip works on image “A”, select the .bin file in the
output folder of the “ImgB” configuration files and update the firmware.
Restart the chip, reconnect and make sure that the chip works with image “B”.
Therefore, the firmware has been updated and a new version has been launched. Now you can allocate more memory for one of the sectors, but this is a completely different story ...
That's all about the stack. In the next part, create your custom BLE profile. I hope that this article will be useful for starting work with SS2541.
After writing the previous material about the BLE socket, I met many
people who are interested in the topic of using BLE in their own designs, but there are certain
difficulties in using C programming with the BLE stack for CC2541. Using an
internal controller provides many advantages, in particular: flashing through the air, saving
on an external controller, reducing the number of solder points ...
I decided to split the material into two parts. The first is preparation for work, programming and
debugging. The second is to create your own BLE profile.
1. Preparation for work.
To develop applications for the CC2541, a must-have set is:
- CC-debugger- in-circuit debugger for 8051 TI chips;
- CC2450 USB dongle - in order to quickly and easily check the characteristics of BLE profiles on
a computer screen;
- Well, actually some kind of motherboard with a CC2541 chip.
Ideally these things are combined in a debug set from TI - CC2541 mini DK . I recommend to purchase.
From software we need:
- actually BLE stack ;
- Always be at hand: Smart RF Studio , Flash Programmer , Packet Sniffer ;
- for debugging: BLE device monitor ;
- IAR for 8051 controllersin version from 8.2 (can be taken with a free 30-day
license).
Without unnecessary descriptions, let’s go through the folders of the stack, which are somehow required for
work.
- accessorize - contains the BTool debugging utility, USB dongle drivers, and compiled
images of finished devices;
- components - libraries (OS, peripherals and BLE);
- documents - the folder creates the appearance of documentation for all components and modules;
- projects - examples of projects.
2. IAR IDE, debugging programs.
Let's open the SimpleBLEPerepherial project for example. We are trying to compile ... And I give 7 out of 10 that the
project will not be assembled. The error is due to the fact that the linker cannot fit in memory
specified number of virtual registers. There are two solutions to the problem:
- simply reduce the number of virtual registers from 16 to 8, and do this for each
project, hoping that it will be assembled;
- fix the linker configuration file (in the simple case, it is ti_51ew_cc2540b.xcl). In it
you need:
1) open this file (it lies in the \ Projects \ ble \ common \ cc2540 \ folder) in a text editor;
2) find the line -Z (DATA) VREG + _NR_OF_VIRTUAL_REGISTERS = 08-7F;
3) replace it with -Z (DATA) VREG = 08-7F;
4) enjoy the projects that will begin to assemble.
Having connected the debug board to CC-debugger, we will launch the application on it (Project- Download and
Debug, Debug - Go).
Now, when you press the right button, the key fob goes into Advertising mode, that is,
you can connect to it . We plug into the USB dongle based on CC2540. We have two monitors for working
with this dongle: a convenient BLE device monitor and a hardcore BTool (the installer of the latter is
bundled with the stack). We use the BLE Device monitor.
The most important fields in this window:
• Handle field - serial number of the record in the BLE device services table,
• Type field - indicates the type of record (defines the service record, service characteristic,
configuration of the characteristic or the characteristic itself (its UUID)),
well and The third important field is the Value field . In case of recording a definition
service, this field actually says the UUID of the service.
The documented services are listed here . For us, provided that we are not members of the Bluetooth SIG, 16-
bit service addresses cannot be used. You need to use 128-bit UUIDs. But more on that
later.
The Value field in the record of the characteristic declaration contains:
-UUID of the characteristic (for example,
0xFFF3 in the example),
-number of the record in the device table (in other words, handle - 0x002B in our
case)
-the order of access to the characteristic determined by the bit mask (in the simplest
case - 0x02 - read permission, 0x08 - write permission, 0x10 - alert resolution).
In addition, it is important to draw from this screen that the user variable for reading
or writing is determined by three entries in the device table (definition of the characteristic,
value of the characteristic, description of the characteristic - the first and second fields are required, the declaration of the third is the rule of good tone), and the
variable, which , changing, notifies the application; in addition, it must have
an additional configurator characteristic that enables or disables notification.
Packet Sniffer is also extremely useful for debugging. I won’t tell in detail,
I’ll just say that to work with the packet sniffer you will need to flash the USB dongle firmware
sniffer_fw_cc2540_usb.hex, lying somewhere in the bowels of the sniffer installation folder (by the way, I sincerely hope that you do not have to debug applications at such a low level).
This is how iBeacon packages look in the ether sniffer:
3. The mechanism of functioning of the peripheral BLE device
To begin with, we will examine how the peripheral device works in the SimpleBlePerepherial example.
The main logic of the program is concentrated in the file SimpleBLEPerepherial.c, while the
main function is located in the file SimpleBLEPerepherial_Main.c, but as a rule it
does not make sense to edit it , since it initializes the peripherals and OSAL (some kind of
operating system). Using the BLE stack, we get access to only part of the processor
time (with the lowest priority). This determines, in particular, the programming style: a
large number of callback functions, the absence of infinite loops in the
program body , the maximum use of interrupts ...
The first user-defined function called by OSAL is the SimpleBLEPeripheral_Init function. In it:
-the parameters of the future connection are determined; -the parameters and composition of the data for the advertising are determined;
-registered profiles supported by the device are registered callbacks of these
profiles;
- OSAL displays a message that the device is ready for use.
Further it is important to pay attention to the callback caused by the stack, which determines the parameters
connections, - peripheralStateNotificationCB. The function always allows you to understand whether a
connection is established with the central device or not.
Any actions (control of conclusions, reading of indicators of sensors, etc.) are strongly
recommended to be performed in a periodic task. To do this, you need a function from the
OSAL library - osal_start_timerEx (), which, in addition to the user task identifier, needs
to pass the time after which the system interrupt occurs, and the bit mask of the event,
which is processed in the SimpleBLEPeripheral_ProcessEvent () callback when it occurs.
4. OAD Support
Now we will consider the OAD function - updating the firmware over the air. I note right away that
such a function is available only in chips with 256 kB memory. The most detailed mechanism for
creating applications for OAD is described in the document , but a couple of points are worth clarifying. Firstly, the memory on the chip
is allocated for two images of the program: the current (executable) and the area for the program
received by air. Secondly, a bootloader should be installed on the chip - a bootloader
that, when the device starts, will choose which of the images to start.
Let's try to create an application with the ability to update firmware over the air. First of
all, we will flash the chip with the bootloader firmware. To do this, compile the BIM project located
in the \ Projects \ ble \ util \ BIM folder and load the resulting image into the controller using
Smart RF Flash Programmer (Erase, Programm and Verify action). Next, we will collect the image with
which our device will start: we will assemble the SimpleBLEPerepherial project in the configuration of
CC2541-OAD-ImgA (by the way, the memory markup file that we corrected at the very beginning is
changed in this assembly, so you will have to make similar changes to the file
cc254x_f256_imgA.xcl). We’ll get this image through the Smart RF Flash Programmer (Append and
Verify action ), at this step the most important thing is not to erase the pre-bootloader. Now, having rebooted the
chip and connected to it through the BLE device monitor, we will see OAD support.
Now compile the image for downloading by air and upload it to the chip. To start
compile the configuration of CC2541-OAD-ImgB. Next, in BLE Device Monitor, go to the
File-programm tab. Make sure that the chip works on image “A”, select the .bin file in the
output folder of the “ImgB” configuration files and update the firmware.
Restart the chip, reconnect and make sure that the chip works with image “B”.
Therefore, the firmware has been updated and a new version has been launched. Now you can allocate more memory for one of the sectors, but this is a completely different story ...
That's all about the stack. In the next part, create your custom BLE profile. I hope that this article will be useful for starting work with SS2541.