All information contained in these materials, including products and product specifications,
Electronics Corp. without notice. Please review the latest information published by
Renesas Electronics Corp. through various means, including the Renesas Electronics Corp.
®
Low Energy Protocol Stack
User’s
represents information on the product at the time of publication and is subject to change by
Renesas
website (http : //www.renesas.com).
Notice
on of
1. Descriptions of circuits, software and other related information in this document are provided only to illustrate the operati
semiconductor products and application examples. You are fully responsible for the incorporation or any other use of the circuits,
software, and i nformation i n the desi gn of your produc t or syste m. Renesa s Electr onics discla ims any and al l liabilit y for any loss es and
damages incurred by you or third parti es arising from the use of these circuits, software, or infor ma tion.
2. Renesas Elec tronics hereby expressly disclai ms any warranties against and liabi lity for infringeme nt or any other claims involving patents,
copyrights, or other intellectual prop erty rights of third part ies, by or arising from the use of Renesas Electronics pr oducts or technical
information described in this document, including but not limited to, the product data, drawings, charts, programs, algorithms, and
application examples.
3. No license, expr ess, impli ed or otherwi se, is gra nted hereb y under an y patents , copyright s or other intell ectual prop erty rights of Renesas
Electronics or others.
4. You shall not alter , modify, copy, or revers e engineer any Renes as Electr onics product , whether in whole or in part. Renesas Electronics
disclaims any and all liability for any losses or damages incurred by you or third parties arising from such alteration, modification,
copying or reverse engineering.
5. Renesas Electroni cs products are cla ssified accordi ng to the following two qua lity grades: “Sta ndard” and “High Quali ty”. The intended
applications for each Renesas Electronics product depends on the product’s quality grade, a s indicated below.
“Standard”: Computers; office equipment; communications equipment; test and measurement equi pment; audio and visual equipment;
home electronic appliances; machine tools; personal electronic eq uipment; industria l robots; etc.
“High Quality”: Transportation equipment (automobiles, trains, ships, etc.); traffic control (traffic lights); large-scale communication
equipment; key financial terminal systems; safety control equipment; etc.
Unless expressl y designated a s a high reli abilit y product or a product for ha rsh environ ments in a Renes as Elec tronics data sheet or ot her
Renesas Electr onic s docum ent, Ren esa s El ectr onic s pr oduc ts a re not i ntended or a uthor i z ed for us e in produc t s or systems tha t may pose a
direct threat to huma n life or bodily injury (ar tificial life supp ort devices or systems; s urgical implantations ; etc.), or may cause ser ious
property damage (s pace system; unders ea repeaters ; nuclear power cont rol systems; a ircraft control systems; key pla nt systems; milit ary
equipment; etc. ). Renesa s El ectroni cs dis claims a ny and al l liab ilit y for any damages or los ses i ncurred b y you or any thi rd parties arising
from the use of any Renes as Electronics product that is inconsistent with any Renesa s Electronics data sheet, us er’s manual or other
Renesas Electronics document.
6. When using Renesas Elect roni cs product s, r efer to t he lates t product informa tion ( data sheet s, user ’s manu als, applica tion not es, “Genera l
Notes for Handling a nd Using Semic onductor Devices ” in the relia bility handbook, etc.), and ens ure that usage c onditions are w ithin the
ranges specified by Renesas Electronics with respect to maximum ratings, operating power supply voltage range, heat dissipation
characterist ics, insta llation, etc. Renesa s Electr onics dis claims any and a ll liabi lity for any ma lfunct ions, fa ilure or acc ident aris ing out of
the use of Renesas Electronics products outside of such specified ranges.
7. Although Renesa s Electroni cs endeavors to imp rove the qual ity and relia bility of Renes as Electroni cs products, semiconductor products
have specific cha racteristics, such as the occurrenc e of failure at a certain rate and malf unctions under certain use conditi ons. Unless
designated as a high reliability product or a product for harsh environments in a Renesas Electronics data sheet or other Renesas
Electronics document, Renesa s Elect ronics produc ts are not s ubject t o radiation res istance des ign. You are r esponsib le for implement ing
safety measures to gua rd aga ins t the pos sibi lity of b odil y injur y, injur y or da mage c aus ed by fir e, a nd/or d anger t o the p ublic in the e vent
of a failure or malf unction of Renesas Elec tronics pr oducts, s uch as safety design for ha rdware a nd software, including b ut not limited t o
redundancy, fire control and malfunction prevention, appropriate treatment for aging degradation or any other appropriate measures.
Because the e valuat ion of mic roc omputer s oft ware a lone is very dif fi cult and imp ract ical, you are res pons ibl e for eval uat ing the s afet y of
the final products or systems manufactured by you.
8. Please contact a Renesas El ectronics sa les office f or details as to environmenta l matters such as the en vironmental compatibility of each
Renesas Elec tronic s produc t. Y ou are r esp onsibl e for c aref ully and s uff icient ly inves ti gati ng appl icab le laws and r egulat ions that regula te
the inclusion or use of controlled substances, including without limitation, the EU RoHS Directive, and using Renesas Electronics
products in compl iance with all these applicab le laws and regul ations. Renesa s Electr onics disclai ms any and all liab ility for damages or
losses occurring as a result of your noncompliance wit h applicable laws and regulations.
9. Renesas Electr oni cs pr oduc ts and t echnol ogi es s ha ll not be us ed f or or incorp or ated i nt o any pr oduc ts or s ystems whos e manuf act ur e, us e,
or sale is pr ohibited under a ny applica ble domestic or foreign laws or regulati ons. You shall comply with an y applicabl e export contr ol
laws and regulations promulgated and administered by the governments of any countries asserting jurisdiction over the parties or
transactions.
10. It is the respons ibility of the buyer or distributor of Renesas Electronics products, or any other party who distr ibutes, disposes of, or
otherwise sell s or tr ansf er s the p r oduct to a thi rd pa r ty, t o noti f y such t hir d p ar ty in a dvanc e of the c ont ent s a nd condi t ions s et f orth i n t his
document.
11. This document sha ll not be repri nted, rep roduced or dup licated i n any form, in whole or in part, wit hout prior wr itten consent of Renesa s
Electronics.
12. Please contact a Renesas Electronics sales of fice if you have any q uestions regarding the information contained in t his document or
Renesas Electronics products.
(Note 1) “Renesas Elect ronics” as used in t his document m eans Renesas Electronics Corporation a nd also incl udes its direc tly or indirect ly
controlled subsidiaries.
(Note 2) “Renesas Electronics product(s)” means any product developed or manufactured by or for Renesas Electronics.
(Rev.4.0-1 November 2017)
General Preca ut ions in the Handl ing of Microprocessing Unit a nd Microcontrol l e r Unit Products
The following usage notes are applicab le to all Microprocessing unit and Microcontroller unit products from Renesas.
For detailed usage notes on the products covered by this document, refer to the relevant sections of the document as well
as any technical updates that have been issued for the products.
1. Handling of Unused Pins
Handle unused pins in accordance with the directions given under Handling of Unused Pins in the
manual.
The input pins of CMOS products are generally in the high-impedance state. In operation with an
unused pin in the open-circuit state, extra electromagnetic noise is induced in the vicinity of LSI, an
associated shoot-through current flows internally, and malfunctions occur due to the false
recognition of the pin state as an input signal become possible. Unused pins should be handled as
described under Handling of Unused Pins in the manual.
2. Processing at Power-on
The state of the produc t is undef in ed at the moment when power is supplied.
The states of internal circuits in the LSI are indeterminate and the states of register settings and
pins are undefined at the moment when power is supplied.
In a finished product where the reset signal is applied to the external reset pin, the states of pins
are not guaranteed from the moment when power is supplied until the reset process is completed.
In a similar way, the states of pins in a product that is reset by an on-chip power-on reset function
are not guaranteed from the moment when power is supplied until the power reaches the level at
which resetting has been specified.
3. Prohibition of Access to Reserved Addresses
Access to reserved addresses is prohibited.
The reserved addresses are provided for the possible future expansion of functions. Do not access
these addresses; the correct operation of LSI is not guaranteed if they are accessed.
4. Clock Signals
After applying a reset, only release the reset line after the operating clock signal has become stable.
When switching the clock signal during program execution, wait until the target clock signal has
stabilized.
When the clock signal is generated with an external resonator (or from an external oscillator)
during a reset, ensure that the reset line is only released after full stabilization of the clock signal.
Moreover, when switching to a clock signal produced with an external resonator (or by an external
oscillator) while program execution is in progress, wait until the target clock signal is stable.
5. Differences between Products
Before changing from one product to another, i.e. to a product with a different part number, confirm
that the change will not lead to problems.
The characteristics of Microprocessing unit or Microcontroller unit products in the same group but
having a different part number may differ in terms of the internal memory capacity, layout pattern,
and other factors, which can affect the ranges of electrical characteristics, such as characteristic
values, operating margins, immunity to noise, and amount of radiated noise. When changing to a
product with a different part number, implement a system-evaluation test for the given product.
How to Use This Manual
1. Purpose and Target Readers
This manual describes setup method, organization, and features of the Bluetooth Low Energy protocol stack (BLE
software), which is used to develop Bluetooth applications that incorporate the Renesas Bluetooth low energy
microcontroller RL78/G1D. It is intended for users designing application systems incorporating this software. A basic
knowledge of microcontrollers and Bluetooth low energy is necessary in order to use this manual.
Related documents
The related documents indicated in this publication may include preliminary versions. However, preliminary versions are
4. Installing BLE Software ................................................................................................................................. 4
4.1 Components Included ......................................................................................................................................... 4
4.2 BLE software build environment ........................................................................................................................ 4
5.2 rBLE API .......................................................................................................................................................... 18
5.3 RL78/G1D Hardware Resources used by the BLE Software ........................................................................... 20
5.4 Serial Communication in Modem Configuration .............................................................................................. 21
5.5 Customer-specific information ......................................................................................................................... 43
5.6 Selection of own Bluetooth Device address ..................................................................................................... 43
6.1 Changing the Configuration Parameters ........................................................................................................... 44
6.1.1 Maximum Number of Simultaneous Connections ................................................................................... 46
6.1.2 Allocating the Heap Area ........................................................................................................................ 47
6.1.3 Changing the Operating Frequency ......................................................................................................... 47
6.1.4 Setting MCU part initialization ................................................................................................................ 48
6.1.5 Setting RF part initialization .................................................................................................................... 49
Index-1
6.1.6 Selecting the serial communication method ............................................................................................ 51
6.1.7 Setting the UART baud rate ..................................................................................................................... 53
6.1.8 Setting the CSI baud rate ......................................................................................................................... 58
6.1.9 Setting the IIC transfer clock ................................................................................................................... 58
6.1.10 Wait for the time Sub Clock is stabled .................................................................................................... 58
6.1.11 Setting the Profile Service ....................................................................................................................... 58
6.2 Building a Project ............................................................................................................................................. 70
7. Description of Features ............................................................................................................................... 72
7.1.4 White List ................................................................................................................................................ 74
7.2.1 GAP roles ................................................................................................................................................ 76
7.2.2 GAP modes and procedures ..................................................................................................................... 76
7.3.3 Key distribution ....................................................................................................................................... 90
7.4.2 Creating a User Profile ............................................................................................................................ 98
7.4.3 GATT Service ........................................................................................................................................ 101
7.5 Find Me Profile ............................................................................................................................................... 102
7.5.1 Use case implemented by using the Immediate Alert service ................................................................ 102
7.11.1 Use case implemented by using the Heart Rate service and the Device Information service ................ 116
7.12 Cycling Speed and Cadence Profile ................................................................................................................ 117
7.12.1 Use case implemented by using the Cycling Speed and Cadence service and the Device Information
service .................................................................................................................................................... 117
7.12.2 Use case implemented by using the SC Control Point characteristic..................................................... 118
7.13 Cycling Power Profile ..................................................................................................................................... 119
7.13.1 Use case implemented by using the Cycling Power service, the Device Information service and the
Battery service ....................................................................................................................................... 119
7.13.2 Use case implemented by using the Cycling Power Control Point characteristic .................................. 121
7.13.3 Use case implemented by Broadcaster role and Observer role .............................................................. 122
7.14.1 Use case implemented by using the Glucose service and the Device Information service .................... 123
7.14.2 Use case implemented by using the Record Access Control Point characteristic .................................. 124
7.15 Time Profile .................................................................................................................................................... 125
7.15.1 Use case implemented by using the Current Time service .................................................................... 125
7.15.2 Use case implemented by using the Next DST Change service ............................................................ 125
7.15.3 Use case implemented by using the Reference Time Update service .................................................... 126
7.16 Running Speed and Cadence Profile ............................................................................................................... 127
7.16.1 Use case implemented by using the Running Speed and Cadence service and the Device Information
service .................................................................................................................................................... 127
7.16.2 Use case implemented by using the SC Control Point characteristic..................................................... 128
7.17.1 Use case implemented by using the Alert Notification service ............................................................. 129
7.17.2 Use case implemented by using the Alert Notification Control Point characteristic ............................. 130
7.18 Phone Alert Status Profile ............................................................................................................................... 131
7.18.1 Use case implemented by using the Phone Alert Status service ............................................................ 131
7.18.2 Use case implemented by using the Ringer Control Point characteristic ............................................... 131
7.19 Location and Navigation Profile ..................................................................................................................... 133
Index-3
7.19.1 Use case implemented by using the Location and Navigation service, the Device Information service and
the Battery service ................................................................................................................................. 133
7.19.2 Use case implemented by using the LN Control Point characteristic .................................................... 134
7.20 Vendor Specific .............................................................................................................................................. 136
7.20.1 Peak current consumption notification .................................................................................................. 136
9.1 About the Code Flash Library......................................................................................................................... 144
9.2 About setting for the Code Flash library ......................................................................................................... 144
9.3 Notes on using the Code Flash library ............................................................................................................ 144
10. Note on Writing User Application .............................................................................................................. 145
10.1 Note on RWKE Timer Management Function ............................................................................................... 145
10.2 Interrupt disabled time of the task and the interrupt handler .......................................................................... 145
10.3 Data transmission of large size data ................................................................................................................ 145
10.4 Performance of BLE MCU ............................................................................................................................. 145
11. Implementation of FW Update Feature ..................................................................................................... 147
11.1 The FW Update Feature .................................................................................................................................. 147
11.2 Function required for FW Update ................................................................................................................... 147
11.2.1 Writing function to the code flash ......................................................................................................... 147
11.2.2 Data transmission and reception profile ................................................................................................. 147
11.2.3 Application for update control (for Receiver device) ............................................................................ 149
11.2.4 Application for update control (for Sender device) ............................................................................... 150
11.3 Limitation and Special Processing .................................................................................................................. 151
11.3.1 Area switching control ........................................................................................................................... 151
11.3.2 Update the standard library (IAR Embedded Workbench only) ............................................................ 151
11.3.3 Limitation for FW Update feature implementation ............................................................................... 152
11.3.4 Update target area and User RAM area ................................................................................................. 153
12.3.2 How to Use ............................................................................................................................................ 157
Appendix A Referenced Documents ................................................................................................................ 159
Appendix B Terminology................................................................................................................................... 160
Index-5
Bluetooth Low Energy Protocol Stack
User
’s Manual
R01UW0095EJ0122
Rev.1.22
Mar. 30, 2018
1. Overview
This manual describes the API (Application Program Interface) of the basic features of the Bluetooth Low Energy
protocol stack (BLE software), which is used to develop Bluetooth applications that incorporate Renesas Bluetooth low
energy microcontroller RL78/G1D.
For details about the BLE software APIs, see Bluetooth Low Energy Protocol Stack API Reference Manual.
R01UW0095EJ0122 Rev.1.22 Page 1 of 162
Mar. 30, 2018
2. Applicability
2. Applicability
The descriptions in this manual apply to Bluetooth Low Energy protocol stack Version 1.21 or later.
R01UW0095EJ0122 Rev.1.22 Page 2 of 162
Mar. 30, 2018
3. Restrictions
3. Restrictions
This section describes the restrictions that apply to BLE software.
R01UW0095EJ0122 Rev.1.22 Page 3 of 162
Mar. 30, 2018
4. Installing BLE Software
4. Installing BLE Software
4.1 Components Included
The compressed package of the BLE software includes the followings:
•Documents
- Bluetooth Low Energy Protocol Stack User's Manual (this document)
- Bluetooth Low Energy Protocol Stack API Reference Manual
- Bluetooth Low Energy Protocol Stack Sample Program Application Note
- rBLE command specifications
•Project files used for creating the executable file
- Executable file
- BLE software library
- Sample source code
- Source code that configures parameters
2
studio project file
- e
- CS+ for CC project file
- CS+ for CA,CX project file
- IAR Embedded Workbench workspace file
•Sample applications for computer
- Executable file
- Source code
- Microsoft Visual Studio Express 2015 project file
•HCI packet monitor application for computer
- Executable file
- INI file
4.2 BLE software build environment
The environment in which BLE software was built is shown below.
•Hardware environment
- Host
• PC/AT™-compatible computer
• Processor : At least 1.6 GHz
• Main memory : At least 1 GB
• Display : 1024 x 768 or higher resolution and 65,536 colors
• Interface : USB 2.0 (E1 and USB-serial conversion cable)
• Tools used
• Renesas on-chip debugging emulator E1
• Software environment
• Windows 7 or later
• Microsoft Visual Studio Express 2015 for Desktop
R01UW0095EJ0122 Rev.1.22 Page 4 of 162
Mar. 30, 2018
4. Installing BLE Software
• Microsoft .NET Framework 4 + language pack
• Renesas CS+ for CC V4.00.00/ RL78 Compiler CC-RL V1.03.00
or e² studio 4.3.1.001/RL78 Family C Compiler Package V1 (without IDE) V1.03.00
or Renesas CS+ for CA, CX V3.02.00/Renesas CA78K0R V1.72
or IAR Embedded Workbench for Renesas RL78 V2.20.1
•Renesas Flash Programmer V3
(available from https://www.renesas.com/software-tool/renesas-flash-programmer-programming-gui)
For details about the environment in which to run the sample application for computers, see Bluetooth Low Energy
Protocol Stack Sample Program Application Note.
4.3 Installation Procedure
Copy the decompressed contents of the package to any folder in your computer.
2
Note: If using the e
To build the BLE software, the EEPROM Emulation Library and Code Flash Library are needed. Libraries for testing are
contained in the BLE software package in advance. But when you start to develop a product, it is necessary to download the
newest libraries corresponding to your development environment from Renesas website and copy to the following folder.
The EEPROM Emulation Library and Code Flash Library are provided by Renesas Electronics Corporation. Regarding
how to install the libraries, refer to 4.4.2 (7) and 4.4.2 (8).
EEPROM Emulation Library and Data Flash Access Library
The transmission sequence including rBLE_Host and serial communications driver's function calls is shown.
[When beginning to transmit]: The serial communications driver is T1 according to the call of rBLE_Host of the
transmission function that begins the transmission operation of the RSCIP packet.
[When the transmission ends]: The serial communications driver notifies rBLE_Host the transmission completion by
calling the transmission completion notification function when RSCIP packet transmission T1- T3 is completed.
BLE MCU APP MCU
R01UW0095EJ0122 Rev.1.22 Page 33 of 162
Mar. 30, 2018
Figure 5-21 Transmit Sequence (APP MCU)
SI00
SDIR
SO00
ACK(0x88)
SCK00
[R2]
[R4]
[R1]
1st byte
last byte
[R3]
[R5]
SI00
SDIR
SCK00
1byte目 最終byte
ACK(0x88)
2byte目 最終byte
[T3]
1byte目
[T1]
[T2]
SO00
[R3]
[R5]
5. BLE Software Configuration
(2) Receive Operation (APP MCU)
The handshaking procedure when APP MCU receives the RSCIP packet from BLE MCU is following R5.
When R1 - R5 is executed, the transmission from APP MCU is assumed to be a prohibition for the half duplex
transmission.
R1: APP MCU waits for the pulse of the SDIR signal of the transmission request.
R2: APP MCU transmits ACK byte (0x88) when the pulse of the SDIR signal is detected, and waits for Low of the SDIR
signal.
R3: APP MCU detects Low of the SDIR signal.
R4: APP MCU supplies the clock, and receives the RSCIP packet.
R5: APP MCU detects High of the SDIR signal.
Figure 5-22 Receive timing chart (APP MCU)
When the transmission request of APP MCU collides with the transmission request of BLE MCU, BLE MCU postpones
transmitting, and receives the RSCIP packet of APP MCU. After completing the RSCIP packet reception, BLE MCU
outputs the pulse again by the SDIR signal.
[R1]
[R2]
Figure 5-23 Transmit requested collision timing chart (APP MCU and BLE MCU)
[R4] [R1]
The reception sequence including rBLE_Host and serial communications driver's function calls is shown. When one
RSCIP packet is received, rBLE_Host calls the reception function two or more times because the RSCIP packet is
variable-length.
[When beginning to receive it]: RBLE_Host calls the reception function. As a result, the serial communications driver is
R1 that begins the reception operation of the RSCIP packet, and waits for the pulse of the SDIR signal.
[When the reception ends the packet on the way]: The serial communications driver notifies rBLE_Host the reception
completion by calling the reception completion notification function after ending R1 - R4, and rBLE_Host calls the
R01UW0095EJ0122 Rev.1.22 Page 34 of 162
Mar. 30, 2018
[R1] SDIR Signal (Pulse)
[R2] ACK
rBLE Host
Serial
Rx Func
Rx Comp Func
[R3] SDIR Signal (Low)
[R4] Packet (1/2)
Rx Func
Rx Status Func
[R4] Packet (2/2)
[R5] SDIR Signal (High)
Rx Comp Func
5. BLE Software Configuration
reception function again. The serial communications driver is R4 that confirms the reception state acquisition function,
supplies the clock again while receiving the packet, and restarts the reception.
[When the reception of the entire packet ends]: The serial communications driver notifies rBLE_Host the reception
completion by calling the reception completion notification function after ending R4, and rBLE_Host calls the reception
function again. The reception state acquisition function is confirmed, and if he or she is packet reception completion, the
serial communications driver is R5 that waits for the SDIR signal to become High.
BLE MCU APP MCU
Rx Func
Rx Status Func
Figure 5-24 Receive Sequence (APP MCU)
5.4.5 CSI 5-wire Connection
In this connected method, APP MCU and BLE MCU communicate by using control signal line WAKEUP to make BLE
MCU get up when control signal line SDIR and APP MCU to control the direction of the communication and the
communication timing of APP MCU and BLE MCU in addition to SO that is the data signal line of CSI as shown in the
following, SI, and SCK transmit data.
The communication is half duplex, and when transmitting or receiving it, it is necessary to do handshaking. It is
operation because it notifies APP MCU the transmission request from BLE MCU so that this may confirm BLE MCU
completes the preparation for the reception or the transmission necessary to fix the direction of the communication in the
half duplex transmission. Moreover, please observe by the time-out to do a reliable communication at handshaking, and
execute handshaking again when you generate the time-out.
Time-out of reply from APP MCU is prepared on BLE MCU. For time-out, Timer Array Unit is used.
R01UW0095EJ0122 Rev.1.22 Page 35 of 162
Mar. 30, 2018
BLE MCU Pin Name
Direction
Function
APP MCU
BLE MCU
BLE MCU
(while WAKEUP signal is inactive) Request-To-Send from BLE MCU
level.
5. BLE Software Configuration
APP MCU
(Master)
SOmn (mn=00,20) BLE MCU->
SImn (mn=00,20) APP MCU->
SCKmn (mn=00,20) APP MCU->
SDIR(P23) BLE MCU->
APP MCU
SI
SO
SOmn
SImn
(Slave)
SCK SCKmn
SDIR SDIR
WAKEUP WAKEUP
Figure 5-25 CSI 5-wire connection
Serial Output Data Signal (MISO : Master-Input-Slave-Output)
Serial Input Data Signal (MOSI : Master-Output-Slave-Input)
Data Communication Timing Clock Signal
Communication Direction Control Signal / Response Control Signal
Low : Data Direction is BLE MCU -> APP MCU
High : Data Direction is APP MCU -> BLE MCU
Pulse (High -> Low -> High) : pulse width = BLE MCU CPU clock x 4
(While WAKEUP signal is active) Clear-To-Send from BLE MCU
BLE MCU
WAKEUP(P30/INTP3)
– Low Active
APP MCU->
BLE MCU
External Trigger Input Signal for Wakeup
It sets it at an active level at the transmission request from APP MCU.
- The response of SDIR from BLE MCU is waited for, and it returns it to an inactive
- In the timing chart described from now on, the terminal name of the BLE MCU side is described.
(1) Transmit Operation (APP MCU)
The handshaking procedure when APP MCU transmits the RSCIP packet to BLE MCU is following T4.
T1: APP MCU makes the WAKEUP signal an active level for the transmission request, and waits for the pulse of the
SDIR signal.
- It is necessary to return the WAKEUP signal to an inactive level once when the time-out is generated by the pulse
waiting about the SDIR signal, and to make it to an active level again.
T2: APP MCU detects the pulse of the SDIR signal of the communication permission response.
T3: The WAKEUP signal is returned to an inactive level.
T4: APP MCU continuously transmits everything from the first byte to the final byte of the RSCIP packet.
R01UW0095EJ0122 Rev.1.22 Page 36 of 162
Mar. 30, 2018
SI00
SDIR
SO00
SCK00
[T1]
1st byte
Last byte
[T4]
WAKEUP
[T2]
[T3]
SI00
SDIR
SO00
SCK00
1st byte
last byte
[T4]
WAKEUP
[T2]
[T3]
[T1]
[T1]
[T2] SDIR Signal (Pulse)
rBLE Host
Serial
[T1]WAKEUP Signal (Active)
[T3] WAKEUP Signal (Inactive)
[T4] Packet
5. BLE Software Configuration
Figure 5-26 Transmit timing chart (APP MCU)
After the transmission request, the serial communications driver begins the time-out watch. When the time-out is
generated, the serial communications driver is T1 that returns the WAKEUP signal to an inactive level for the
re-transmission demand once, and outputs an active level again. The recommended value at the timeout period is assumed
to be 5msec.
GATT characteristics Service Changed Start of Affected Attribute Handle Range
Health Thermometer Service
characteristic
Blood Pressure Service characteristic Blood Pressure Feature Supported features
HID Service characteristic Instance setting Number of instances, instance information
Battery Service characteristic Format of Battery level value Presentation Format
Product information of Device
Information Service
Temperature Type Indicates where the temperature was
Measurement Interval Time between measurements
Valid Range Valid range of values for the Measurement
Report ID
(defined in HID of USB)
HID information
(defined in HID of USB)
Report Map
(defined in HID of USB)
PnP ID
(Defined in HID of USB)
System ID System ID
Model Number Character string indicating the model number
Serial Number Character string indicating the serial number
Firmware Revision Character string indicating the firmware
Hardware Revision Character string indicating the hardware
Software Revision Character string indicating the software
Manufacturer Name Character string indicating the manufacturer
IEEE Certification Value IEEE 11073-20601 regulatory certification data
Discoverable time
Scan interval
Scan window
Connection interval
Slave latency
Supervision timeout
Connection interval
Slave latency
Supervision timeout
End of Affected Attribute Handle Range
measured
Interval
0x00 to 0xFF
BcdHID
BCountryCode
Flags
Report Map
Vendor ID Source
Vendor ID
Product ID
Product Version
revision
revision
revision
name
list
R01UW0095EJ0122 Rev.1.22 Page 45 of 162
Mar. 30, 2018
6. Creating Executable Files
User-Configurable Items Specifiable Value
Heart Rate Service characteristic Body Sensor Location Location of the heart rate sensor
Cycling Speed and Cadence Service
characteristic
Cycling Power Service characteristic Support Sensor Location Num Number of supported sensor location
Glucose Service characteristic Glucose Feature Supported features
Current Time Service characteristic Local Time Information time zone
Running Speed and Cadence Service
characteristic
Alert Notification Service characteristic Supported New Alert
Location and Navigation Service
characteristic
Support Sensor Location Num Number of supported sensor location
Support Sensor Location Byte array containing values of each supported
sensor location
Sensor Location Physical location of the CSC sensor
CSC Feature Supported features
Support Sensor Location Byte array containing values of each supported
sensor location
Sensor Location Physical location of the CP sensor
Cycling Power Feature Supported features
DST offset
Reference Time Information The information about the reference time
source
Support Sensor Location Num Number of supported sensor location
Support Sensor Location Byte array containing values of each supported
sensor location
Sensor Location Physical location of the RSC sensor
RSC Feature Supported features
Bit map of supported new alert categories
Category
Supported Unread Alert
Category
LN Feature Supported features
Bit map of supported unread alert categories
Note:
*1: For details about peak current consumption notification, see 7.20.1.
*2: For details about HCI packet monitoring feature, see 12.
*3: For details about how to create custom profile, see 7.4.2.
6.1.1 Maximum Number of Simultaneous Connections
When operating as Master device, the number of Slave devices that can be connected at the same time can be specified in
the range of 1-8.
Since allocating memory from the Heap area required for the connection, the amount of required RAM can be reduced by
limiting the number of simultaneous connections.
When operating as Slave device only, set 1 to the number of simultaneous connections.
The maximum number of simultaneous connections can be changed by the value of following macro.
Macro name: CFG_CON
Note: In all of the connection parameters, connections up to a maximum number of simultaneous connections are not
guaranteed. The maximum number of simultaneous connections might be limited by the Heap size.
R01UW0095EJ0122 Rev.1.22 Page 46 of 162
Mar. 30, 2018
Setting of user option byte
Operating frequency
Operating mode
000C0
000C1
000C2
2B
4MHz
LV (low voltage main) mode
AA
8MHz
LS (low speed main) mode
E9
16MHz
E8
32MHz
6. Creating Executable Files
6.1.2 Allocating the Heap Area
The heap area used by BLE software is allocated by the ke_mem_heap array. The current setting (BLE_HEAP_SIZE) is
the minimum memory capacity for BLE software to run. When the user program runs on the BLE MCU and ke_malloc is
used in the Embedded configuration, for example, memory for the amount required by the user program should be added.
The heap memory size can be changed in the following source file.
Note: GATT database structure of existing profiles that are defined in the above file shall not be changed. Therefore it isn't
possible to changes order or add/delete elements. If you do not want to expose the optional characteristics, please use
the RBLE_GATT_PERM_HIDE permission.
6.1.11.1 Profile Enable / Disable Setting
It is possible to enable / disable each profile roll. The amount of the ROM/RAM size can be reduced by enabling only the
profile roll used.
Table 6-22 shows the macro name to enable / disable each profile role. Setting the value of corresponding macro to 1
enables the profiling role.
Table 6-22 Macro name to enable / disable each profile role
Find Me Profile
R01UW0095EJ0122 Rev.1.22 Page 58 of 162
Mar. 30, 2018
Reporter
PRF_SEL_PXPR
Collector
PRF_SEL_HTPC
Thermometer
PRF_SEL_HTPT
Collector
PRF_SEL_BLPC
Sensor
PRF_SEL_BLPS
HID Device
PRF_SEL_HGHD
Boot Host
PRF_SEL_HGBH
Report Host
PRF_SEL_HGRH
Scan Client
PRF_SEL_SPPS
Scan Server
PRF_SEL_SPPC
Collector
PRF_SEL_HRPC
Sensor
PRF_SEL_HRPS
Profile
Collector
PRF_SEL_CSCC
Sensor
PRF_SEL_CSCS
Collector
PRF_SEL_CPPC
Sensor
PRF_SEL_CPPS
Client
PRF_SEL_ANPC
Server
PRF_SEL_ANPS
Profile
Collector
PRF_SEL_LNPC
Sensor
PRF_SEL_LNPS
Collector
PRF_SEL_GLPC
Sensor
PRF_SEL_GLPS
Client
PRF_SEL_TIPC
Server
PRF_SEL_TIPS
Client
PRF_SEL_PASC
Server
PRF_SEL_PASS
Cadence Profile
Collector
PRF_SEL_RSCC
Sensor
PRF_SEL_RSCS
Macro name
Description
Note
GAP_DEV_SEARCH_TIME
Device Search time
procedure).
GAP_DEV_SEARCH_SCAN_INTV
Scan interval
GAP_DEV_SEARCH_SCAN_WINDOW
Scan window
discoverable mode.
GAP_SCAN_FAST_INTV
Scan interval
GAP_SCAN_FAST_WINDOW
Scan window
GAP_INIT_CONN_MIN_INTV
Max connection interval
GAP_INIT_CONN_MAX_INTV
Min connection interval
6. Creating Executable Files
Health Thermometer Profile
Blood Pressure Profile
HID over GATT Profile
Scan Parameters Profile
Heart Rate Profile
Cycling Speed and Cadence
Cycling Power Profile
Alert Notification Profile
Location and Navigation
Glucose Profile
Time Profile
Phone Alert Status Profile
Running Speed and
To disable the profile role, set the value of corresponding macro to 0.
6.1.11.2 GAP Parameters Setting
Parameters related to the GAP modes/procedures can be set by the value of the defined macros in Table 6-23. These
macros are defined in source file.
Table 6-23 Macro name for GAP parameters
GAP_LIM_ADV_TIMEOUT Discoverable time
R01UW0095EJ0122 Rev.1.22 Page 59 of 162
Mar. 30, 2018
Parameters for device search
(Limited / General discovery
Parameters for limited
Parameters for Auto / Selective
connection procedure.
GAP_CONN_SLAVE_LATENCY
Slave latency
GAP_DEV_SUPERVISION_TIMEOUT
Supervision timeout
TV
interval
according to the product use.
Macro name
Description
Note
Name characteristic value
string.
Macro name
Description
Note
- Appearance Values
Macro name
Description
Note
GAP_PPCP_CONN_INTV_MAX
Maximum connection interval
GAP_PPCP_CONN_INTV_MIN
Minimum connection interval
GAP_PPCP_SLAVE_LATENCY
Slave latency
GAP_PPCP_STO_MULT
Supervision timeout
6. Creating Executable Files
GAP_RESOLVABLE_PRIVATE_ADDR_IN
Private address change
Set the favorite value
6.1.11.3 GAP Characteristic Setting
The following GAP characteristic value can be set.
• Device Name
• Appearance
• Peripheral Preferred Connection Parameters
It is possible to set the initial value of the Device Name characteristic value, which indicates a user-friendly name to
identify a device, can be set by the macro definitions shown in Table 6-24.
Table 6-24 Device Name setting macro
GAP_DEV_NAME
Note: Device name that was written in the Code Flash last block (see 5.5) is priority than this definition value. Also, it is
possible to change the device name using API after a BLE software start-up.
Initial value of the Device
It is possible to set the Appearance characteristic value, which indicates appearance of device, can be set by the macro
definitions shown in Table 6-25.
Table 6-25 Appearance setting macro
Set the device name as an UTF-8
Set it according to the product,
referring to the following.
https://www.bluetooth.com/specificatio
ns/assigned-numbers/
GAP_APPEARANCE_CHAR_VAL
Initial value of the device
appearance setting
For more information about the GAP Appearance characteristic, refer to Bluetooth Core Specification v4.2 [Vol. 3], the
Part C Section 12.2.
The Peripheral Preferred Connection Parameters characteristic value, which is desired by the peripheral device
connection parameters, can be set by the macro shown in Table 6-26.
For more information about the each characteristic, refer Alert Notification Service Specification v1.0
6.1.11.17 Location and Navigation Service Characteristic Setting
The LN Feature characteristic value, which indicates the supported features of LN sensor, can be set by the following
variables in Table 6-53.
R01UW0095EJ0122 Rev.1.22 Page 68 of 162
Mar. 30, 2018
Variable name
Description
Note
6. Creating Executable Files
Table 6-53 LN Feature setting variable
static const uint8_t
lns_ln_feature[ ]
Supported features of LN
sensor.
Set this according to the product, in
accordance with the specifications of
Location and Navigation Service.
For more information about the LN Feature characteristic, refer Location and Navigation Profile Specification v1.0, the
Section 4.4.
R01UW0095EJ0122 Rev.1.22 Page 69 of 162
Mar. 30, 2018
Environment
ration
Creation Folder
(CA78K0R)
Modem
CubeSuite\BLE_Modem\BLE_Modem.mtpj
rBLE_emb\DefaultBuild
Embedded
CubeSuite\BLE_Embedded\BLE_Embedded.mtpj
BLE_Emb\DefaultBuild
Workbench V2
Modem
iar_v2\BLE_Modem\BLE_Modem.eww
BLE_Emb\Debug
Embedded
iar_v2\BLE_Embedded\BLE_Embedded.eww
BLE_Emb\Debug
(CC-RL)
Modem
CS_CCRL\BLE_Modem\BLE_Modem.mtpj
rBLE_Mdm\DefaultBuild
Embedded
CS_CCRL\BLE_Embedded\BLE_Embedded.mtpj
rBLE_Emb\DefaultBuild
Modem
e2studio\BLE_Modem\rBLE_Mdm\ (*1)
rBLE_Mdm\DefaultBuild
Embedded
e2studio\BLE_Embedded\rBLE_Emb\ (*1)
rBLE_Emb\DefaultBuild
6. Creating Executable Files
6.2 Building a Project
Follow the procedure below to build a project for creating an executable file.
1. See 6.1 for how to change the parameters to accord with your environment.
2. To open a file in each environment, double-click in the following folder a project file or workspace file which is
shown in Table 6-54 and matches the development environment and BLE software configuration in use.
\Renesas\BLE_Software_Ver_X_XX\RL78_G1D\Project_Source\renesas\tools\project\
3. For CS+, click the Build menu and then select Build Project. For IAR Embedded Workbench, click the Project
menu and then select Make. For e
4. When build is finished, an executable file is output to the executable file creation folder shown in Table 6-54.
Table 6-54 Correspondence between Development Environment and Build Environment
2
studio, click the Project menu and then select Build Project.
Development
CS+ for CA, CX
IAR Embedded
CS+ for CC
e2 studio
(CC-RL)
Configu-
Project File or Workspace File
*1 : e2 studio project need to import for workspace in e2 studio.
Executable File
R01UW0095EJ0122 Rev.1.22 Page 70 of 162
Mar. 30, 2018
Status
Value
Description
RBLE_VERSION_FAIL
0xF7
Library combination error
RBLE_TEST_VERSION
0xF8
BLE software is test version
Required stack size
824bytes
6. Creating Executable Files
6.3 Additional Note
BLE software provides multiple libraries, so it is possible that the BLE software does not work properly due to the wrong
combination of library even if the build succeeds. To avoid this situation, the BLE software has a function to check the
combination of the library and to notify by the completion status of the GAP reset show in in Table 6-55 Library
Management Status.
Also, for example, if the profile of the prototype has been added to the BLE software, there is a case to provide a version
of the library for evaluation. Also in this case, it is can be determined by the status of the in Table 6-55 Library Management
Status at the completion of GAP reset.
Note that if you have the evaluation version, do not apply to your product and please wait for the official release.
Table 6-55 Library Management Status
In addition, BLE software requires the stack size shown in Table 6-56.
Table 6-56 BLE software stack size
The stack size of the caller of API and callback function of the application which BLE software calls are not contained in
the above stack size. Please ensure enough stack size, when developing application.
R01UW0095EJ0122 Rev.1.22 Page 71 of 162
Mar. 30, 2018
Allowable Response
SCAN_REQ
CONNECT_REQ
Connectable Undirected Event
ADV_IND
YES
YES
Connectable Directed Event
ADV_DIRECT_IND
NO
YES
Non-connectable Undirected Event
ADV_NONCONN_IND
NO
NO
Scannable Undirected Event
ADV_SCAN_IND
YES
NO
7. Description of Features
7. Description of Features
This section describes the features of the BLE software.
7.1 Controller Stack
The controller stack includes the Host Controller Interface (HCI) and Link Layer (LL), and is used to control the RF/BB
according to requests from the Host stack, and perform packet processing such as advertising and scanning.
7.1.1 Advertising
Advertising is used to establish a connection or periodically provide user data to the scanning device. During advertising,
packets are transmitted on the advertising channel and the response from the scanning device is received and responded to.
A device in this state is called an Advertiser.
When an Advertiser receives a connection request from another device and connects to that device, it operates as a slave
device.
There are four types of advertising, and the relationships between the allowable responses for each advertising type are
indicated in the following table.
Table 7-1 Advertising Event Types
Advertising Event Type
SCAN_REQ: Requests additional information.
CONNECT_REQ: Starts connection establishment.
Advertising uses any channel out of the advertising channels (channels 37, 38, or 39). The period during which
advertising data is transmitted is called an advertising event, and the interval between advertising events is calculated as
follows as T_advEvent.
T_advEvent = advInterval + advDelay
•advInterval : An integral multiple of 0.625 ms in the range of 20 ms to 10.24 s
(In the case of a scannable undirected event type or non-connectable undirected event type, this interval is not
less than 100 ms. In the case of a connectable undirected event type, this interval is 20 ms or greater.)
•advDelay : Pseudorandom value in the range of 0 ms to 10 ms
R01UW0095EJ0122 Rev.1.22 Page 72 of 162
Mar. 30, 2018
Advertiser
ADV_IND
37ch
ADV_IND
38ch
ADV_IND
39ch
ADV_IND
37ch
ADV_IND
38ch
ADV_IND
39ch
Event starts
Event closes
Advertiser
ADV_IND
ADV_IND
ADV_IND
Scanner
SCAN_RSP
SCAN_REQ
SCAN_REQ
SCAN_RSP
ADV_IND
7. Description of Features
TX
≤10 ms ≤10 ms
TX TX
T_advEvent
advInterval advDelay
TX TX TX
≤10 ms ≤10 ms
Figure 7-1 Advertising Event (ADV_IND)
For details about Advertising, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.4.2.
7.1.2 Scanning
Scanning is used to receive data broadcasts from an Advertiser. A device that waits for packets from an Advertiser on an
advertising channel is called a scanner. There two types of scanning : passive scanning and active scanning.
7.1.2.1 Passive Scanning
During passive scanning, the scanner only receives packets and does not transmit any packets.
7.1.2.2 Active Scanning
During active scanning, the scanner waits for advertising packets from the Advertiser and responds according to the
advertising event type. Upon receiving an ADV_IND packet or ADV_SCAN_IND packet, the scanner can obtain
additional information by sending a SCAN_REQ packet to the Advertiser.
An example of the operation of a scanner that receives an ADV_IND packet on channel 38 during active scanning is
shown below.
37ch
38ch
TX
TX
RX
TX
≤10 ms
T_IFS
T_IFS
T_IFS
T_IFS
≤10 ms
RX
TX
RX
Figure 7-2 Active Scanning (ADV_IND)
39ch
TX
* T_IFS = 150 us
For details about Scanning, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.4.3.
R01UW0095EJ0122 Rev.1.22 Page 73 of 162
Mar. 30, 2018
Advertiser
ADV_IND
Initiator
RX
CONNECT_REQ
ADV_IND
connInterval
CONNECT_REQ
1.25ms
transmitWindowOffset
transmitWindowSize
Slave device
Master device
* T_IFS = 150 us
7. Description of Features
7.1.3 Initiating
Initiating is used to establish a connection with another device. A device that waits for an advertising packet on an
advertising channel in order to connect to another device is called an Initiator. An Initiator that receives an ADV_IND
packet or ADV_DIRECT_IND packet operates as a master upon the end of initiation triggered by sending a
CONNECT_REQ packet.
The first packet following transmission of a CONNECT_REQ packet is transmitted within transmitWindowSize that
starts after 1.25ms + transmitWindowOffset.
• transmitWindowOffset : A multiple of 1.25 ms in the range of 0 ms to connInterval
• transmitWindowSize : A multiple of 1.25 ms in the range of 1.25 ms to 10 ms
While connected, the master and slave send and receive packets to each other alternately using connInterval.
•connInterval : A multiple of 1.25 ms in the range of 7.5 ms to 4.0 s
An example of the operation from when the initiator receives an ADV_IND packet from the Advertiser until it becomes
the master device is shown below.
38ch
TX
T_IFS
RX
T_IFS
RX
T_IFS
TX
T_IFS
TX RX
Figure 7-3 Connection Setup
TX
RX
TX RX
TX
7.1.4 White List
allowed to be received. This list includes device addresses and address types (public address or random address).
is set by the application.
R01UW0095EJ0122 Rev.1.22 Page 74 of 162
Mar. 30, 2018
For details about Initiating, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.4.4.
The White List is used to filter devices from which advertising packets, scan packets, and connection requests are
The White List is managed in the Link Layer block of the Controller stack. In the Reset state, the White List is empty and
For details about the White List, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.3.1.
7. Description of Features
7.1.4.1 Advertising filter policy
The advertising filter policy determines how scan and connection requests are processed. When connectable directed
advertising is used, the advertising filter policy is ignored. At all other times, one of the following advertising filter policies
set by the application is used.
• The White List is not used and scan and connection requests from all devices are processed (default state).
• Only scan and connection requests from devices registered to the White List are processed.
• Scan requests from all devices are processed, but only connection requests from devices on the White List are
processed.
• Connection requests from all devices are processed, but only scan requests from devices on the White List are
processed.
For details about the Advertising filter policy, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.3.2.
7.1.4.2 Scanner filter policy
The scanner filter policy determines how advertising packets are processed. One of the following scanner filter policies
set by the Host stack is used.
• The White List is not used and advertising packets from all devices are processed (default state).
• Only advertising packets from devices registered to the White List are processed.
For details about the Scanner filter policy, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.3.3.
7.1.4.3 Initiator filter policy
The initiator filter policy determines how advertising packets are processed. One of the following initiator filter policies
set by the application is used.
• Connectable advertising packets from all devices registered to the White List are processed.
• The White List is ignored and the connectable advertising packets from a single device that is specified are processed.
For details about the Initiator filter policy, see Bluetooth Core Specification v4.2 [Vol. 6], Part B Section 4.3.4.
R01UW0095EJ0122 Rev.1.22 Page 75 of 162
Mar. 30, 2018
GAP Roles
Description
In the Link Layer, it is called the Advertiser.
In the Link Layer, it is called the Scanner.
In the Link Layer, it is called the Master.
In the Link Layer, it is called the Slave.
Advertising Event Type
Description
(connectable).
Connectable Directed
Only connectable with specified device.
Scannable Undirected
Can respond to SCAN_REQ (non-connectable).
Non-connectable Undirected
Only information sent from Advertiser (non-connectable)
7. Description of Features
7.2 Generic Access Profile
The Generic Access Profile (GAP) executes access procedures according to the link management and security
requirements for processes such as device discovery and peer device connection and disconnection.
7.2.1 GAP roles
The BLE software supports all four of the roles prescribed in the GAP listed in Table 7-2.
Table 7-2 GAP Roles
Broadcaster Transmits advertising events.
Observer Receives advertising events.
Central Establishes a physical link.
Peripheral Accepts the establishment of a physical link.
For details about the GAP roles, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 9.
7.2.2 GAP modes and procedures
This section describes the GAP modes and the GAP procedures supported by the BLE software.
Advertising event types are used according to each mode and procedure, as shown in Table 7-3.
Table 7-3 Advertising Event Type
Connectable Undirected Can respond to CONNECT_REQ or SCAN_REQ
7.2.2.1 Broadcast mode and Observation procedure
The broadcast mode and observation procedure allow two devices to communicate with each other without establishing
connection between them.
A device in the broadcast mode is called the Broadcaster. It broadcasts data during advertising events. All data sent by a
device in the broadcast mode is considered unreliable since there is no acknowledgment from any device that may have
received the data. The advertising event types that can be transmitted are non-connectable undirected events and scannable
undirected events. The AD type flag of the advertising data must be set to 0 both for the LE General Discoverable Mode and
LE Limited Discoverable Mode.
The device executing the observation procedure is called the Observer. It receives advertising events.
The rBLE API provides APIs for executing the broadcast mode and observation procedure. The advertising data in the
broadcast mode can be set freely by the user.
For details about the Broadcast mode and Observation procedure, see Bluetooth Core Specification v4.2 [Vol. 3], Part C
Section 9.1.
R01UW0095EJ0122 Rev.1.22 Page 76 of 162
Mar. 30, 2018
Flags AD Type
Mode
Mode
Do not transmit
discovery procedure.
Undirected
Undirected
Discovery Procedure
Description
Limited Discovery
Only devices in limited discoverable mode can be discovered.
discovered.
retrieved by using GATT.
7. Description of Features
7.2.2.2 Discovery mode and procedure
Peripheral device discovery is possible in the discovery modes and by using the discovery procedures. The discovery
modes are modes that allow discovery from remote devices by transmitting advertising data. The discovery procedures are
procedures for receiving advertising data from scanning and discovering peripheral devices. They are executed by a central
device.
Table 7-4 lists the relationships between the discovery modes, transmittable advertising event types, and AD type flag
setting values of the advertising data.
Table 7-4 Discovery Modes
Transmittable
Discovery Mode
Non-Discoverable • Non-connectable
Limited Discoverable • Non-connectable
General Discoverable • Non-connectable
Advertising Event
Types
Undirected
•Scannable
Undirected
•
Undirected
•Scannable
Undirected
•Connectable
Undirected
•Scannable
Undirected
•Connectable
LE General
Discoverable
The discovery procedures are outlined in Table 7-5 below.
Table 7-5 Discovery Procedure
LE Limited
Discoverable
0 0
0 1
1 0
Description
Not discoverable by any
device performing either
the general discovery
procedure or the limited
Discoverable for a limited
period of time by other
devices performing the
limited or general device
discovery procedure.
Discoverable by devices
performing the general
discovery procedure.
General Discovery Devices in general or limited discoverable mode can be
Name Discovery The device names of connectable remote devices are
The rBLE API provides APIs for executing discovery mode, peripheral device discovery, and device name retrieval. It is
also possible to discover only existing devices by using peripheral device discovery. Any advertising data can be set by the
user in discovery mode. The AD type flag of the advertising data must be set according to the mode to be executed.
For details about each mode and procedures, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 9.2.
R01UW0095EJ0122 Rev.1.22 Page 77 of 162
Mar. 30, 2018
Event Types
Scannable Undirected
procedure.
connection establishment procedure.
Connection Procedure
Description
using the White List of the Initiator.
connectable mode or undirected connectable mode.
the connection configuration parameters selected by the host.
connection configuration parameters selected by the host.
connection.
Terminate connection
Terminates the connection with a peer device.
7. Description of Features
7.2.2.3 Connection mode and procedure
The connection modes and procedures can be used to establish connections with other devices. The connection modes
are modes that allow connection from remote devices by sending advertising data. These modes are executed by peripheral
devices. The connection procedures are procedures for establishing a connection with a peripheral device. They are
executed by a central device. (The terminate connection procedure, which cuts off a link can be executed from both a
central and peripheral devices.)
Table 7-6 shows the relationships among the connection modes and transmittable advertising event types that can be
sent.
Table 7-6 Connection Modes
Connection Mode
Non-connectable • Non-connectable
Directed connectable • Connectable Directed Connection is possible only from known
Undirected connectable • Connectable Undirected Connection is possible from devices that
Transmittable Advertising
Undirected
•
Description
Connection not allowed.
devices that execute the auto
connection establishment procedure or
general connection establishment
execute the auto connection
establishment procedure or general
The connection procedures are outlined in Table 7-7 below.
Table 7-7 Connection Procedure
Auto connection establishment Automatically establishes a connection with devices in the
directed connectable mode or undirected connectable mode,
General connection establishment Establishes a connection with known devices in the directed
Selective connection establishment Establishes a connection with devices on the White List using
Direct connection establishment Establishes a connection with one known device using the
Connection parameter update Changes the connection parameters of an established
The rBLE API provides APIs for executing the connection modes and connection procedures. In a connection mode,
advertising data can be set freely by the user. A connection mode can be executed in combination with a discovery mode.
For details about each mode and procedures, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 9.3.
R01UW0095EJ0122 Rev.1.22 Page 78 of 162
Mar. 30, 2018
Bonding Mode
Description
Non-Bondable
Bonding with peer devices is not allowed.
Bondable
Bonding with peer devices is allowed in the bondable mode.
Security Mode
Security Level
Description
1
No security (no authentication and no encryption)
2
Unauthenticated pairing with encryption
3
Authenticated pairing with encryption
encryption
1
Unauthenticated pairing with data signing
2
Authenticated pairing with data signing
7. Description of Features
7.2.2.4 Bonding mode and procedure
Bonding allows two connected devices to exchange and store security and identity information to create a trusting
relationship. Security and identity information is called bonding information. When devices store bonding information,
they are said to have bonded.
There are two bonding modes, as shown in Table 7-8 below.
Table 7-8 Bonding Modes
The bonding procedure is executed when a device that is not bonded accesses a service that requires bonding. Pairing is
used for bonding.
The rBLE API provides APIs for executing bonding and responding to bonding requests.
For details about bonding, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 9.4.
7.2.3 Security
This section describes BLE security as defined in the GAP.
7.2.3.1 Security mode
The security requirements of a device, a service, or a service request are expressed in terms of a security mode and
security level. Each service or service request may have its own security requirement. The device may also have a security
requirement. Pairing is required in order to satisfy the various security requirements. There are two types of pairing,
authenticated pairing in which the paired devices are protected from MITM (man-in-the-middle) attacks, and
unauthenticated pairing in which the paired devices are not protected from MITM. The security mode level is determined
by device pairing, encryption, and the use or non-use of data signing. Table 7-9 lists the security modes and security levels
defined in the BLE standard.
Table 7-9 Security Modes and Levels
LE Security Mode 1
4 Authenticated LE Secure Connections pairing with
LE Security Mode 2
Note: BLE software is not supported LE security mode 1 level 4 (LE Secure Connections).
LE security mode 1 level 2 satisfies the security requirements for LE security mode 1 level 1.
LE security mode 1 level 3 satisfies the security requirements for LE security mode 1 level 2. LE security mode 1 level 3
satisfies the security requirements for LE security mode 2.
If LE security mode 1 and LE security mode 2 level 2 are required for a given physical link, then LE security mode 1
level 3 is used.
If LE security mode 1 level 3 and LE security mode 2 are required for a given physical link, then LE security mode 1
R01UW0095EJ0122 Rev.1.22 Page 79 of 162
Mar. 30, 2018
7. Description of Features
level 3 is used.
If LE security mode 1 level 2 and LE security mode 2 level 1 are required for a given physical link, then LE security
mode 1 level 2 is used.
The rBLE API provides an API for setting the security mode. The security mode can be set for each profile.
For details about the security modes, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 10.2.
7.2.3.2 Authentication procedure
The authentication procedure describes how the required security is established when a device initiates a service request
to a remote device and when a device receives a service request from a remote device. The authentication procedure covers
both LE security mode 1 and LE security mode 2. The authentication procedure is only initiated after a connection has been
established.
If security is not required, or the security requirements are already satisfied, service requests will continue. If security is
required, pairing will be necessary.
The rBLE API allows the execution of pairing by executing bonding.
For details about the Authentication procedure, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 10.3.
7.2.3.3 Data Signing
Data signing is used for transferring authenticated data between two devices in an unencrypted connection. The data
signing method is used by services that require fast connection setup and fast data transfer.
If a service request specifies LE security mode 2, the connection data signing procedure is used.
In the BLE software, data signing is used when sending the Signed Write command of ATT (Bluetooth Core
Specification v4.2[Vol. 3], Part F Section 3.4.5.4). The CSRK key for data signing must be set in advance to the rBLE API.
The validity of the received signed data is verified internally by the BLE software. The CSRK of the remote device that is
required at that time is requested from the application by the rBLE API. Management of the CSRK distributed from remote
devices and generation of the CSRK of the local device must be performed by the application.
For details about the data signature, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 10.4.
7.2.3.4 Privacy features
The privacy feature is possible to prevent to be tracked and identified from an attacker by using random address.
The rBLE API provides an API that enables the privacy feature, and random addresses are generated according to the
role by setting IRK in advance. The IRK must be generated and managed by the application.
For details about the privacy features, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 10.7.
7.2.4 Bluetooth Device Address
Each Bluetooth device shall be allocated a unique 48-bit Bluetooth device address (BD_ADDR) to identify the Bluetooth
devices. The BLE specification, two types of public address and a random address has been defined as a Bluetooth device
address.
7.2.4.1 Public address
Public address shall be created in accordance with IEEE 802-2001 standard, and using 24bit OUI (Organizationally
R01UW0095EJ0122 Rev.1.22 Page 80 of 162
Mar. 30, 2018
Type
Description
initialized until the device is power cycled.
periodically changing the address.
shall not use for the connection.
Address Resolution procedure.
7. Description of Features
Unique Identifier). Public address is uniquely given to each of the device. A device shall not change its public address value
during the lifetime of the device.
This address shall be obtained from the IEEE Registration Authority.
7.2.4.2 Random address
Random addresses may be of the sub-types listed in Table 7-10 below.
Table 7-10 Random Address
Static address When not needing registration to IEEE Registration
Authority, it's possible to use as substitution of the public
address.
A device may choose to initialize its static address to a
new value after each power cycle. It’s also possible to
use the same address during the lifetime.
A device shall not change its static address value once
Private address Private addresses are used for privacy, it is possible to
make it difficult to track and identify from an attacker by
Non-resolvable private address Bluetooth Core Specification v4.1 or later, this address
Resolvable private address This type of address is generated from an IRK and a
24-bit random number. Only devices which is shared
IRK can identify the device by Resolvable Private
Note: Bluetooth Specification does not support random device address collision avoidance or detection. And
therefore, random addresses have a very small chance of being in conflict. When using private address,
reconnection takes time because Resolvable Private Address Resolution procedure is required.
• Interpretation of resolvable private address
Using the Resolvable Private Address Resolution procedure, the host can resolve the resolvable private addresses of
all peer devices that have an IRK. Once a resolvable private address is resolved, the host can link this address to the
peer device. If the host stores multiple IRKs, this procedure is repeated for each stored IRK until the corresponding
address is successfully resolved.
The BLE software can use the address type other than Non-resolvable. Private addresses are generated automatically by
enabling the privacy feature using the IRK specified from the application. Resolvable private addresses are resolved
internally by the BLE software. The IRK of the remote device required at that time is requested from the application by the
rBLE API. The IRKs of remote devices must be managed by the application.
For details about the random address, see Bluetooth Core Specification v4.2 [Vol. 3], Part C Section 10.8.
7.2.5 Advertising and Scan response data formats
Advertising and Scan Response data are created in the format shown in Figure 7-4.
R01UW0095EJ0122 Rev.1.22 Page 81 of 162
Mar. 30, 2018
Value
Bit
Description
0
LE Limited Discoverable Mode
1
LE General Discoverable Mode
2
BR/EDR not supported
(Controller)
(Host)
Advertising data can include only one Flags AD type.
0x02
Usable 16-bit service UUID
0x03
Usable 16-bit service UUID (complete list)
7. Description of Features
Figure 7-4 Advertising and Scan Response Data Formats
The Advertising and Scan Response data has the following characteristics:
• Total data size of 31 octets
• Consists of multiple AD structures
• Each AD structure consists of 1 octet of length information and the data of the length octet.
• The data of the length octet consists of an AD type of n octets and AD data of length – n octets.
• If the total size of all the AD structures is less than 31 octets, it is padded with 0s.
• Data consisting of all 0s is used only to allow early termination of Advertising or Scan Response.
• Only the significant part of the Advertising or Scan Response data is transmitted over the air.
• The Advertising and Scan Response data is transmitted in advertising events.
• Advertising data is placed in the AdvData field of the ADV_IND, ADV_NONCONN_IND, and ADV_SCAN_IND
packets.
• The Scan Response data is transmitted in the ScanRspData field of the SCAN_RSP packet.
The definitions of the AD types that can be used for AD structures and the AD data format are shown in Table 7-11.
Table 7-11 AD Type Definitions and AD Data Format
AD Type AD Type
Flags 0x01 Flags are configured of the following bits :
Service
R01UW0095EJ0122 Rev.1.22 Page 82 of 162
Mar. 30, 2018
AD Data Description
3 Simultaneous LE and BR/EDR operation supported
4 Simultaneous LE and BR/EDR operation supported
• The Flags AD type must not include Scan Response data.
•
Value
0x06
Usable 128-bit service UUID
0x07
Usable 128-bit service UUID (complete list)
0x08
Short local device name
0x09
Complete local device name
0xXX : −127 to +127 dBm
0x0D
Class of device (3 bytes)
0x0E
Simple Pairing Hash C (16 bytes)
0x0F
Simple Pairing Randomizer R (16 bytes)
TK Value
0x10
TK (Temporary Key) used for pairing (128 bits)
Bit
Description
(0 = OOB data not present, 1 = OOB data present)
1
LE supported by host
2
Simultaneous LE and BR/EDR operation supported (Host)
(0 = public address, 1 = random address)
0xFFFF : don’t care
Solicitation
0x14
16-bit service UUID list
0x15
128-bit service UUID list
Service Data
0x16
Additional service data that follows the 16-bit service UUID
Specific Data
The company ID is included in the first 2 bytes.
7. Description of Features
AD Type AD Type
AD Data Description
Local Name
TX Power Level 0x0A Advertising packet transmission power level (1 byte)
OOB Data
OOB Flags 0x11 The OOB Flags field consists of the following bits :
0 OOB Flags field
3 Address type
Slave Connection
Interval Range
Service
Manufacturer
0x12 Includes the connection interval requested by a Peripheral for all the logical
links. A Central should use the data of this AD type in the Peripheral.
The first 2 bytes indicate the minimum connection interval.
N = 0x0006 to 0x0C80 (Time = N * 1.25 ms)
The next 2 bytes indicate the maximum connection interval.
N = 0x0006 to 0x0C80 (Time = N * 1.25 ms)
0xFF Manufacturer specific data
R01UW0095EJ0122 Rev.1.22 Page 83 of 162
Mar. 30, 2018
Value
Description
0x02
Data length of this AD structure (2 octets)
0x01
AD type = Flags
0x06
LE Limited Discoverable Flag bit and BR/EDR not supported bit set
0x08
Data length of this AD structure (8 octets)
0x09
AD type = Complete local device name
0x52
‘R’
0x65
‘e’
0x6E
‘n’
0x65
‘e’
0x73
‘s’
0x61
‘a’
0x73
‘s’
0x07
Data length of this AD structure (7 octets)
0x03
AD type = Usable 16-bit service UUID (complete list)
0x02
0x18
0x03
0x18
0x04
0x18
7. Description of Features
Table 7-12 shows an advertising data setting example. In this example, Flags is set as the AD type, along with the
complete device name and 16-bit UUID.
Table 7-12 Advertising Data Example
Immediate Alert service (UUID : 0x1802)
Link Loss service (UUID : 0x1803)
Tx Power service (UUID : 0x1804)
The Advertising and Scan Response data can be set freely by the user. This data must be set as appropriate for the use
case according to the above format.
For details about the Advertising Scan Response data formats, see Bluetooth Core Specification v4.2 [Vol. 3], Part C
Section 11. For details about the AD Type, see Bluetooth Core Specification Supplement (CSS) v7, Part A.
R01UW0095EJ0122 Rev.1.22 Page 84 of 162
Mar. 30, 2018
Characteristics
Property
Description
Device Name
Read
Indicates user-friendly Device Name
Val
Category
Val
Category
0
Unknown
13
Heart rate Sensor
1
Phone
14
Blood Pressure
Device (HID)
3
Watch
16
Glucose Meter
Sensor
5
Display
18
Cycling
6
Remote Control
49
Pulse Oximeter
7
Eye-glasses
50
Weight Scale
Device
Monitor
10
Media Player
53
Insulin Pump
Scanner
Activity
•Connection Supervision Timeout
7. Description of Features
7.2.6 GAP Service for GATT Server
GAP service is a GATT-based service containing generic information about the device. Central device and Peripheral
device working as a GATT server have to contain GAP service.
The GATT server exposes the characteristics shown in the table below by using the GAP service.
Regarding the GATT-based service or characteristics, refer to the section 7.4 "Generic Attribute Profile" in this
document.
Table 7-13 GAP Service Characteristics
Appearance Read Indicates a category of device
Peripheral Preferred
Connection Parameters
2 Computer 15 Human Interface
4 Clock 17 Running Walking
8 Tag 51 Personal Mobility
9 Keyring 52 Continuous Glucose
11 Barcode
12 Thermometer 81 Outdoor Sports
Read Indicates recommended Connection Parameters
54 Medication Delivery
• Minimum Connection Interval
• Maximum Connection Interval
• Slave Latency
For details about the property of each characteristic, see Table 7-19.
Regarding the GAP Service, refer to Bluetooth Core Specification v4.2[Vol. 3], Part C Chapter.12 "GAP SERVICE
AND CHARACTERISTICS FOR GATT SERVER".
R01UW0095EJ0122 Rev.1.22 Page 85 of 162
Mar. 30, 2018
Key Type
Description
Generated by
(Identity Resolving Key)
addresses
Resolving Key)
upon key size)
(Encrypted Diversifier)
generated each time an LTK is distributed.
Pairing Request
Pairing Response
Key distribution
Phase 1
Phase 2
Phase 3
Key distribution
Key distribution
7. Description of Features
7.3 Security Manager
The Security Manager (SM) is in charge of ensuring secure BLE communication, including pairing, encryption, private
address resolution and data signing.
Pairing is performed to generate the key used for link encryption and data signing. The device that initiates pairing is
called the Initiator, and the device that responds is called the Responder. Pairing is executed in the phases listed below and
shown in Figure 7-5.
• Phase 1: Pairing feature exchange
• Phase 2: STK generation. The STK generation method is based on the information that was exchanged during phase
1.
•Phase 3: Distribution of the generated key. This is done via a link encrypted by using the key generated in phase 2.
Initiator Responder
Connection establishment
STK generation
Encryption using key generated in phase 2
Figure 7-5 LE Pairing Phases
The keys used for pairing, encryption, private address resolution, and data signing are shown in the table below.
Table 7-14 Key Definitions
IRK
CSRK
(Connection Signature
LTK
(Long Term Key)
EDIV
R01UW0095EJ0122 Rev.1.22 Page 86 of 162
Mar. 30, 2018
128-bit key used to generate and resolve random
128-bit key used to create signatures and verify
the signatures of received data
128-bit key used to generate the session key for
encryption (partially used according to the agreed
16-bit key used to identify the LTK. A new EDIV is
The application
The application
The application
The application
Key Type
Description
Generated by
(Random Number)
generated each time an LTK is distributed.
(Short Term Key)
TK and used to encrypt the link after phase 2
TK passed from the application
(Temporary Key)
the STK
Input Capability
Description
‘no’.
time limit, and ‘no’ is displayed upon timeout.)
allows ‘yes’ or ‘no’ indication.
Output Capability
Description
communicate a 6-digit number.
6-digit number.
7. Description of Features
Rand
STK
TK
64-bit key used to identify the LTK. A new Rand is
128-bit key generated in pairing phase 2 by using
128-bit key used in pairing phase 2 to generate
The application
The BLE software by using the
The application
For details about generating each key, see Bluetooth Core Specification v4.2 [Vol. 3], Part H Section 2.4.1 and 2.4.2.
7.3.1 Pairing feature exchange
In pairing phase 1, the Initiator and Responder perform a pairing feature exchange. The fields of the features that are
exchanged are described below. The pairing method used in phase 2 is determined based on the information that is
exchanged here.
• IO Capability
This field indicates the input and output capabilities of the device. IO Capability (Table 7-17) is the combination of the
Input Capability (Table 7-15) and Output Capability (Table 7-16).
Table 7-15 Input Capability
No input The device does not have the capability to indicate ‘yes’ or
Yes / No The device has at least two buttons that can indicate ‘yes’ and
‘no’, or a mechanism that allows ‘yes’ or ‘no’ indication.
(Example : ‘yes’ is indicated by pressing a button within the
Keyboard The device has a numeric keyboard that can be used to input
numbers ‘0’ through ‘9’. The device also has at least two
buttons that can indicate ‘yes’ and ‘no’, or a mechanism that
Table 7-16 Output Capability
No output The device does not have the capability to display or
Numeric output The device has the capability to display or communicate a
The input capability (Table 7-15) and output capability (Table 7-16) are mapped to a single IO capability shown in
Table 7-17, which is used for the pairing feature exchange.
R01UW0095EJ0122 Rev.1.22 Page 87 of 162
Mar. 30, 2018
Input
No input
NoInputNoOutput
DisplayOnly
Yes / No
NoInputNoOutput1
DisplayYesNo
Keyboard
KeyboardOnly
KeyboardDisplay
7. Description of Features
Table 7-17 IO Capability Mapping
Output
Note: The combination of Yes/No and No Output is regarded as NoInputNoOutput.
No output Numeric output
• Validity of OOB authentication data
The data required for authentication of a remote device that is using a communication method other than Bluetooth is
called OOB (Out Of Band) data. This field indicates the presence/non-presence of the OOB authentication data
required for remote device authentication.
• Authentication requirement
This field indicates the following security properties used for authentication :
- Protection from MITM (man-in-the-middle) attacks required/not required
- Perform/don’t perform bonding
• Encryption key size
This field indicates the size of the key to be used for link encryption. The smaller of the key sizes indicated by the two
devices is used for encryption. The size can be specified in 1-byte units from 7 bytes (56 bits) to 16 bytes (128 bits).
• Key distribution
This field indicates the keys whose distribution in phase 3 is requested by the pairing Initiator and Responder. The
distribution of multiple keys can be requested.
- EncKey (LTK, EDIV, and Rand)
- IdKey (IRK)
- Sign (CSRK)
The rBLE API allows the above-described pairing features to be freely set during bonding execution or in the response
API. Set the appropriate pairing feature according to the functions and/or purpose of the local device.
For details about each feature, see Bluetooth Core Specification v4.2 [Vol. 3], Part H Section 2.3.1 to 2.3.4.
7.3.2 STK generation
In phase 2, the pairing method (STK generation method) is determined using the information exchanged between the
devices in phase 1. The TK required for STK generation is determined by pairing. The BLE pairing methods and
characteristics are shown below.
• Just Works
This method provides no protection against eavesdroppers or man-in-the-middle attacks during the pairing process. If
no eavesdropping or MITM attack occurs during the pairing process, security is ensured by encryption during future
connections.
No action on the user’s part is required during the pairing process.
The TK used by both devices is 0x00000000000000000000000000000000.
R01UW0095EJ0122 Rev.1.22 Page 88 of 162
Mar. 30, 2018
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.