BLE stack from TI. Custom Application Development

Hi, Habr!

After writing the previous material about the BLE outlet, I met many
people who are interested in the topic of using BLE in their own development, but there are certain
difficulties in using C programming with the BLE stack for CC2541. Using
The internal controller offers many advantages, in particular: firmware over the air, saving
on an external controller, reducing the number of soldering points ...
I decided to split the material into two parts. The first is preparation for work, programming and
debugging The second is creating your own BLE profile.


1. Preparation for work.
')
To develop applications for the CC2541, the MUST HAV dial-up 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
computer screen;
- well, actually any board with a SS2541 chip.
Ideally, these things are combined in the debugging kit from TI - CC2541 mini DK . I recommend to purchase.


From the software we need:

- actually BLE stack ;
- always have to be on hand: Smart RF Studio , Flash Programmer , Packet Sniffer ;
- for debugging: BLE device monitor ;
- IAR for 8051 controllers in version from 8.2 (can be taken with a free 30-day
license).

Without unnecessary descriptions, go through the stack folders, which one way or another will be 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 for example the project SimpleBLEPerepherial. We try to compile ... And I give 7 of 10 that
The project will not meet. The error occurs due to the fact that the linker cannot fit in memory
specified number of virtual registers. There are two options for solving the problem:

- just reduce the number of virtual registers from 16 to 8, and do it for each
project, hoping that he will meet;
- fix the linker configuration file (in the simple case, this is ti_51ew_cc2540b.xcl). In him
need to:
1) open this file (it lies in the \ Projects \ ble \ common \ cc2540 \ \ folder) in a text editor;
2) find the string -Z (DATA) VREG + _NR_OF_VIRTUAL_REGISTERS = 08-7F;
3) replace it with -Z (DATA) VREG = 08-7F;
4) enjoy projects that will begin to gather.

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 keyfob goes into Advertising mode, that is, to it
can connect. Stick in the USB dongle based on the CC2540. We have two monitors for work.
with this dongle: convenient BLE device monitor and hardcore BTool (the latter’s installer is
complete with stack). We use the BLE Device monitor.



The most important fields in this window are:
• Handle field - the ordinal number of the entry in the BLE device service table,
• Type field - indicates the type of record (determines the service record, the characteristic of the service,
the configuration of the characteristic or the characteristic itself (its UUID)),
• well, the third important field is the Value field. In the case of a definition record
service this field actually says service UUID.
Documented services are listed here . We, provided we are not members of the Bluetooth SIG, 16
bit addresses of services cannot be used. Need to use 128-bit UUIDs. But about that
later.
The Value field in the characteristic declaration record contains:
-UUID characteristics (for example,
0xFFF3 in the example),
-number of entries in the device table (in other words, the handle is 0x002B in our
case)
-the order of access to the characteristic, determined by the bit mask (in the simplest
case - 0x02 - read resolution, 0x08 - write resolution, 0x10 - alert resolution).

In addition, it is important to learn from this screen that a user variable to read
or entries are determined by three entries in the device table (definition of a characteristic,
the value of the characteristic, the description of the characteristic - the first and second fields are required, the declaration of the third is the rule of good tone), and
a variable that, when changing, notifies the application, in addition to this must have
additional configuration feature that enables or disables notification.

Packet Sniffer is also extremely useful for debugging. I will not tell in detail
I’ll just say that to work with a packet sniffer, you will need to flash USB dongle firmware
sniffer_fw_cc2540_usb.hex, lying somewhere in the depths of the sniffer installation folder (by the way, I sincerely hope that you will not have to debug applications at such a low level).

This is how the iBeacon packages appear in the ether sniffer:


3. The mechanism of functioning of the peripheral BLE device

First, let's look at 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 SimpleBLEPerepherial_Main.c file, but it is usually governed by
there is no sense, since the periphery and OSAL are initialized in it (some semblance of
operating system). Using the BLE stack, we access only the part of the processor
time (with the lowest priority). This determines, in particular, the programming style:
a large number of callback functions, the lack of endless cycles in the body
programs, 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 advertising are determined;
- the profiles supported by the device are registered, the Kelbacks of these
profiles;
-In OSAL, a message is displayed that the device is ready for operation.

Next, it is important to pay attention to the Kelback caused by the stack, which defines the parameters
connections, - peripheralStateNotificationCB. The function always allows you to understand whether
connection to the central device or not.

Any actions (pin management, reading sensor readings, etc.) are strongly
I recommend performing in a periodic task. For this you need a function from the library
OSAL - osal_start_timerEx (), which, in addition to the user task identifier, needs
pass the time after which the system interrupt occurs, and the bit mask of the event,
which when processed is handled in the SimpleBLEPeripheral_ProcessEvent () callback.

4. Support OAD

Now consider the function OAD - firmware update over the air. Immediately, I note that
This feature is only available in chips with a memory of 256 KB. Maximum detail mechanism
Creating applications for OAD is described in the document , but it’s worth a couple of points to clarify. First, the memory on the chip
allocated for two images of the program: the current (executable) and the area for the program,
taken by air. Secondly, a bootloader must be installed on the chip;
which, when the device starts, will choose which of the images to launch.
Let's try to create an application with the ability to update the firmware over the air. First
We will fix 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 by
Smart RF Flash Programmer (action Erase, Programm and Verify). Next, collect the image with
which our device will start: we will assemble the SimpleBLEPerepherial project in the configuration
CC2541-OAD-ImgA (by the way, the memory markup file, which we corrected at the very beginning,
in this assembly changed, so you have to make similar changes to the file
cc254x_f256_imgA.xcl). Get this image via Smart RF Flash Programmer (Append and
Verify), at this step, the most important thing is not to erase the pre-boot bootloader. Now by rebooting
chip and connect to it via BLE device monitor, we will see support for OAD.



Now we compile the image for loading over the air and load it onto the chip. To start
compile CC2541-OAD-ImgB configuration. Next in the BLE Device Monitor, go to
tab File-programm. Make sure the chip works on image “A”, select the .bin file in the folder
“ImgB” configuration output files and update the firmware.

We will reload the chip, reconnect and make sure that the chip works with the “B” image.



Therefore, the firmware has been updated and a new version has been launched. Now it is possible to allocate more memory for one of the sectors, but this is a completely different story ...

This is all about the stack. In the next part create your custom BLE profile. I hope that the article will be useful for starting work with CC2541.