 |
Synergy Software Package User's Manual
|
|
Synergy Software Package User's Manual
|
Bluetooth® Low Energy (BLE), sometimes referred to as Bluetooth Smart, is a light-weight subset of Classic Bluetooth, and was introduced as part of the Bluetooth 4.0 core specification. In contrast to Classic Bluetooth, BLE is designed to provide significantly lower power consumption. This allows Internet of Thing (IoT) devices that have stricter power capacity to transfer small amounts of data between nearby devices.
Application developers access the functionality provided by the BLE stack using its APIs. The BLE stack APIs provided by different vendors are not standardized, and as a result, Application developers have to update their code when porting to different BLE stacks.
The Synergy BLE Framework handles this issue by providing a generic interface for the underlying BLE stack provided by various vendors, thereby preventing coupling between application and vendor-specific BLE stack code. The use of generic APIs makes application development simpler and portable.
The BLE Framework provides a high-level API for BLE applications and uses the Synergy Software Package (SSP) communication framework, which in turn enables the UART driver for communication to the underlying BLE module. It also integrates the generic BLE profile framework (g_sf_ble_onboard_profile), which provides a uniform interface to BLE profiles. For the RL78G1D BLE hardware module, the generic BLE profiles are implemented by the BLE module firmware.
The BLE Framework defines APIs for initializing, setting and getting values, and stopping modules. A complete list of the available APIs, an example API call and a short description of each can be found in the following table. A table of status return values follows the API summary table.
BLE Framework Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_ble0.p_api->open(g_ sf_ble_0.p_cfg);This function initializes and enables the BLE module. It accepts the BLE module configuration as an argument, which has the following parameters: - 48-bit Bluetooth Address - Device scan interval - Device scan window - Device discoverable time - Device connection interval - Slave latency - Supervision timeout - Own address type - Maximum slaves allowed to be connected |
| close | g_sf_ble0.p_api->close (g_ sf_ble0.p_cfg);This API de-initializes the interface and may put the BLE module in low power mode or power it off. It also closes the driver, disables the driver link, disables the interrupt in the BLE module driver. |
| infoGet | g_sf_ble0.p_api->infoGet (g_sf_ble_0.p_cfg, p_handle, p_ble_info);The infoGet API takes the BLE control structure as an argument. It returns the following information obtained from the BLE module: - Chipset/driver information string - RSSI value (unsigned integer 16 bits) |
| provisionGet | g_sf_ble0.p_api->provisionGet (g_sf_ble_0.p_cfg, p_ble_provisioning);The provisionGet API gets the BLE GAP provisioning information and takes the BLE control structure as an argument. It returns the following parameters: - Bonding Mode - Security Mode - GAP Role (Central/Master or Peripheral/Slave) - Security Keys |
| provisionSet | g_sf_ble0.p_api->provisionSet (g_sf_ble_0.p_cfg, p_ble_provisioning);The provisionSet() function provisions the BLE module. It takes the BLE control structure and the provisioning structure as an argument.- Bonding Mode - Security Mode - GAP Role (Central/Master or Peripheral/Slave) - Security Keys - GAP user event callback |
| scan | g_sf_ble0.p_api->scan (g_sf_ble_0.p_cfg, p_scan, p_cnt, p_scan_info);The scan() function takes BLE control structure as an argument. The scan() function returns a list of BLE devices scanned by the BLE module with below parameters. - Bluetooth address (48-bits) - RSSI - Scan data - Advertising Event type The scan() function takes device count as an argument, which acts as an in/out parameter. It specifies the size of the scan result array and the BLE framework sets it to count indicating the number of scan results stored in the array. The function takes scan type as an argument (active/passive). |
| advertisementStart | g_sf_ble0.p_api->advertisementStart (g_sf_ble_0.p_cfg, p_advt_info);The advertisementStart() function takes the following parameters:- Discovery mode (General/Limited) - Filter policy – Support for scan/connect request filtering combinations - Advertisement data - Connection mode - Advertisement intervals - Channel map - Address type - Advertising type - Scan response data |
| advertisementStop | g_sf_ble0.p_api->advertisementStop (g_sf_ble_0.p_cfg);Stops advertisement. |
| whitelistAdd | g_sf_ble0.p_api->whitelistAdd (g_sf_ble_0.p_cfg, p_bp_addr);The whitelistAdd() function adds devices to the whitelist for advertisements, scan requests and connection requests. |
| whitelistDel | g_sf_ble0.p_api->whitelistDel (g_sf_ble_0.p_cfg, p_bp_addr);The whitelistDel() function deletes devices from the whitelist for advertisements, scan requests and connection requests. |
| bondingStart | g_sf_ble0.p_api->bondingStart (g_sf_ble_0.p_cfg, p_handle, p_bp_addr, p_bonding_start);The bondingStart() function starts bonding with a remote device. |
| bondingResponse | g_sf_ble0.p_api->bondingResponse (g_sf_ble_0.p_cfg, p_handle, p_bp_addr, p_bonding_resp);The bondingResponse() function responds to a bonding request. |
| startEncryption | g_sf_ble0.p_api->startEncryption (g_sf_ble_0.p_cfg, p_enc_info);The startEncryption() function begins an encryption operation. |
| connect | g_sf_ble0.p_api->connect (g_sf_ble_0.p_cfg, p_handle, p_conn);The connect() function connects to a remote device. |
| disconnect | g_sf_ble0.p_api->disconnect (g_sf_ble_0.p_cfg, p_handle);The disconnect() function disconnects from a remote device. |
| listen | g_sf_ble0.p_api->listen (g_sf_ble_0.p_cfg);The listen() function listens for an incoming connect request from aremote device. |
| authorization | g_sf_ble0.p_api->authorization (g_sf_ble_0.p_cfg, &conhandle);The authorization() function authorizes a remote device after connection. |
| setTxPower | g_sf_ble0.p_api->setTxPower(g_sf_ble_0.p_cfg, &con_handle, &tx_power_info);The setTxPower() function sets the transmit power for the procedure specified by the connection handle. |
BLE Framework On-Board Profiles Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_ble_onboard_profile0.p_api->open (g_ sf_ble_onboard_profile0.p_cfg);This API initializes the interface for data transfers. |
| close | g_sf_ble_onboard_profile0.p_api->close (g_ sf_ble_onboard_profile0.p_cfg);This API de-initializes the interface and may put it in low power mode or power it off. The API closes the driver, and disables the driver link and interrupt. |
| onbpEnable | g_sf_ble_onboard_profile0.p_api->onbpEnable (sf_ble_onboard_profile0.p_cfg, p_handle, profile, p_prf_cb, sec);Enables the profile in server mode or client mode. |
| onbpServerWriteData | g_sf_ble_onboard_profile0.p_api->onbpServerWriteData (sf_ble_onboard_profile0.p_cfg, p_handle, profile, characteristics, p_data);Updates the value of the characteristic in the local database. |
| onbpServerSendNotification | g_sf_ble_onboard_profile0.p_api->onbpServerSendNotification (sf_ble_onboard_profile0.p_cfg, p_handle, profile, characteristics, p_data);Sends notifications. |
| onbpServerSendIndication | g_sf_ble_onboard_profile0.p_api->onbpServerSendIndication (sf_ble_onboard_profile0.p_cfg, p_handle, profile, characteristics, p_data);Sends indications. |
| onbpClientWriteCCCD | g_sf_ble_onboard_profile0.p_api->onbpClientWriteCCCD (sf_ble_onboard_profile0.p_cfg, p_handle, profile, cccd_char, cccd_val);Sets the Client Configuration Control Descriptor on the remote device. |
| onbpDisable | g_sf_ble_onboard_profile0.p_api->onbpDisable (sf_ble_onboard_profile0.p_cfg, p_handle, profile);Disables the profile in server mode and clientmode. |
| onbpClientReadChar | g_sf_ble_onboard_profile0.p_api->onbpClientReadChar (sf_ble_onboard_profile0.p_cfg, p_handle, profile, characteristics);Reads a GATT characteristic associated with the profile or service. |
| onbpClientWriteChar | g_sf_ble_onboard_profile0.p_api->onbpClientWriteChar (sf_ble_onboard_profile0.p_cfg, p_handle, profile, characteristics);Writes a GATT characteristic associated with the profile or service. |
| versionGet | g_sf_ble_onboard_profile0.p_api-> versionGet(&version);Retrieves the API version using the version pointer. |
BLE Framework GATT API Summary
| Function Name | Example API Call and Description |
|---|---|
| gattAddCustomProfiles | g_sf_ble0.p_api->gattAddCustomProfiles (g_sf_ble_0.p_cfg, p_handle, p_sf_ble_svc_dscv_req, p_sf_ble_svc_dscv_rsp, p_rsp_cnt);This function adds custom profiles to the GATT database. |
| gattServiceDiscovery | g_sf_ble0.p_api->gattServiceDiscovery (g_sf_ble_0.p_cfg, p_handle, p_sf_ble_svc_dscv_req, p_sf_ble_svc_dscv_rsp, p_rsp_cnt);The gattServiceDiscovery() function performs service discovery. |
| gattCharDiscovery | g_sf_ble0.p_api->gattCharDiscovery (g_sf_ble_0.p_cfg, p_handle, p_sf_ble_svc_dscv_req, p_sf_ble_svc_dscv_rsp, p_rsp_cnt);The gattCharDiscovery() function performs the Char discovery operation. |
| gattCharDescDiscovery | g_sf_ble0.p_api->gattCharDescDiscovery (g_sf_ble_0.p_cfg, p_handle, start_handle, end_handle, p_sf_ble_svc_dscv_rsp, p_rsp_cnt);Discovers GATT characteristics descriptor on a remote device. |
| gattCharRead | g_sf_ble0.p_api->gattCharRead (g_sf_ble_0.p_cfg, p_handle, start_handle, p_char_read_req, p_char_read_rsp);Reads GATT characteristics on a remote device. |
| gattCharWrite | g_sf_ble0.p_api->gattCharWrite (g_sf_ble_0.p_cfg, p_handle, p_char_read_req);Writes GATT characteristics on a remote device. |
| gattCharExecuteWrite | g_sf_ble0.p_api->gattCharExecuteWrite (g_sf_ble_0.p_cfg, p_handle, execute_flag);Executes a write (commit) on GATT characteristics on a remote device. |
| gattCharWriteLocal | g_sf_ble0.p_api->gattCharWriteLocal (g_sf_ble_0.p_cfg, char_handle, data_length);Updates the local GATT database. |
| gattSendNotify | g_sf_ble0.p_api->gattSendNotify (g_sf_ble_0.p_cfg, p_handle, char_handle);Sends notifications from local GATT server to remote GATT client. |
| gattSendIndicate | g_sf_ble0.p_api->gattSendIndicate (g_sf_ble_0.p_cfg, p_handle, char_handle);Sends indications from local GATT server to remote GATT client. |
| gattWriteResponse | g_sf_ble0.p_api->gattWriteResponse (g_sf_ble_0.p_cfg, p_handle, char_handle);Responds to the write characteristic value request from the remote GATT client. |
| versionGet | g_sf_ble0.p_api->versionGet(&version);Retrieves the API version using the version pointer. |
Status Return Values
| Name | Description |
|---|---|
| SSP_SUCCESS | API Call Successful. |
| SSP_ERR_ASSERTION | Parameter has invalid value. |
| SSP_ERR_INVALID_PTR | p_version is NULL. |
This section provides the Synergy BLE Framework software architecture overview and highlights the major SSP modules used as part of BLE framework along with the operational flow sequence from the user's application level.
The BLE framework provides a common interface for the application. The implementation of the interface is specific for each module. The Synergy BLE framework currently defines an interface implemented for RL78G1D BLE module. Each implementation interacts with the corresponding BLE device driver. The BLE device driver uses the underlying SSP communication framework (g_sf_comms), which in turn interacts with the SSP HAL components such as Universal Asynchronous Receiver/Transmitter (UART), Data Transfer Controller (DTC), and General PWM Timer (GPT) drivers to communicate with the BLE module. The following figure shows a high-level architectural description of the BLE Framework module.
GAP and GATT APIs
The BLE framework provides a generic interface for the application to configure and provision the BLE module. The BLE module has various configuration parameters as specified by the family of Bluetooth Smart standards. It is possible that individual device drivers and/or BLE modules might not support all configuration parameters. At a bare minimum, the provisioning API provides a mechanism to set the operating mode, security mode, security keys, and bonding mode of the BLE interface. It also provides an API for the GAP/GATT layers.
On-Board Profiles APIs
The on-board profiles APIs provide a uniform interface to the BLE profiles implemented by the BLE module firmware.
BLE Stack
The BLE module host stack is typically provided by the BLE module vendor. The BLE module typically comes in three different flavors depending on the HW/SW partitioning between the host MCU and BLE module. The RL78G1D BLE module is part of the Network Controller Implementation architecture, where the BLE chipset includes all the implementation for the BLE link layer, GAP, GATT, and on-board profiles. The module interfaces with the MCU over the sf_comms framework provided by SSP.
A: BLE radio-only mode
Link layer, L2CAP, GATT, GAP layers, profiles, and application run on the host MCU. Physical layer runs on BLE chipset.
B: BLE controller implementation
Link layer runs on BLE chipset, L2CAP, and higher BLE protocol (GATT, GAP) layers. Profiles and application run on the host MCU.
C: Network controller implementation
Link layer, L2CAP, GATT, GAP layers, and generic profiles run on the BLE chipset. Optional profiles and application run on the host processor.
BLE Framework Instances
An application must define the BLE Framework instance before using it. The instance is a structure that includes pointers to any of the following:
BLE Framework Control Structure
This structure is used in all BLE Framework APIs. This structure includes pointer to driver handle, which is used by the framework for storing the required information by the BLE device driver.
BLE Framework Configuration Structure
This structure is passed to sf_ble_api_t::open API and you can use this structure to configure the BLE module. This configuration is applied either during initialization, such as open or provisioning such as sf_ble_api_t::provisionSet API. Configuration parameters that are not supported by the BLE module are ignored by the framework.
BLE Framework APIs Structure
This structure contains pointers to the BLE Framework APIs that are specific to a given module. See Configuring the BLE Framework Module for more details on these APIs.
The steps for using the BLE Framework module in an application are:
The following BLE module initialization sequence is part of the Synergy auto-generated code:
On-Board Profile-Based Client Application Flow Sequence
On-Board Profile-Based Server Application Flow Sequence
GAP/GATT-Based Client Application Flow Sequence
GAP/GATT-Based Server Application Flow Sequence
Security Manager provides BLE protocol stack the ability to generate and exchange security keys which is used to encrypt communication link. The Security Manager has two functions:
The initiator is the master device that initiate the security procedure, however the slave device can asynchronously request the initiator to begin the security procedure.
BLE Security provides modes with levels associated with each mode. Security mode and level is a combination of support for authenticated or unauthenticated pairing, encryption or data signing. Pairing is required to satisfy various security requirements. Two types of pairing are available:
Authenticated pairing where devices are protected from MITM (Man In The Middle) attacks
Unauthenticated pairing where they are not protected from MITM.
Security Mode 1
Security Mode 2
No Security: If On-Board Profile security is set to No Security then Profile communication works in unsecured mode regardless of BLE GAP Security Mode and Level.
Unauthenticated: For this Profile Security method to work any of the BLE GAP Security Method other than Security Mode 1 Level 1 should be used. Module should have completed Pairing with the remote device.
Authenticated: For this Profile Security method to work any of the following BLE GAP Security Method should be used. Module should have completed Pairing with the remote device.
Authorization: For this Profile Security method to work the remote device should have been Authorized during GAP connection using BLE Framework authorization API. This On-Board profile security parameter is specific to server API only.
Encryption: In this Security procedure, the profile will use encrypted communication. For this Profile Security method to work, any of the BLE GAP Security methods other than Security Mode 1 Level 1 should be used. If any security method that does not use encryption is used, then the profile works in unencrypted mode.
BLE Security has the following procedures:
Pairing creates a secure link that lasts for the lifetime of the connection, whereas bonding creates a permanent association called bond.
BLE Security goes through three phases. Two devices establish connection using the GAP connection procedure, followed by the three phases to establish a secure communication link:
The BLE framework is only tested on the following boards:
Refer to the most recent SSP Release Notes for module limitations.
This section describes how to include the BLE Framework module in an application using the SSP configurator.
To add the BLE Framework module to an application, simply add it to a HAL /Common thread using the stacks selection sequence given in the following table. (The default name for the BLE Framework module is g_sf_ble0. This name can be changed in the associated Properties window.)
BLE Framework Module Selection Sequence
| Resource | ISDE Tab | Stacks Selection Sequence |
|---|---|---|
| g_sf_ble0 RL78G1D BLE GAP and GATT on sf_ble_rl78g1d | Threads | New Stack> Framework> Networking> BLE> RL78G1D BLE GAP and GATT on sf_ble_rl78g1d |
| g_sf_ble_onboard_profile0 On-Board Profile on RL78G1D BLE Framework | Threads | New Stack> Framework> Networking> BLE> On-Board Profile on RL78G1D BLE Framework |
When the BLE Framework module on sf_ble is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description include Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.
In the stack above, the Add Communication Framework block has not been populated yet. There are multiple possible selections for the Communication Frameowork; they are not all provided so as to not complicate needlessly, the figure and the following configuration tables. Typical options include:
The BLE Framework module must be configured by the user for the desired operation. The SSP configuration window will automatically identify (by highlighting the block in red) any required configuration selections, such as interrupts or operating modes, which must be configured for lower-level modules in order to ensure successful operation. Furthermore, only those properties that can be changed without causing conflicts are available for modification. Other properties are 'locked' and are not available for changes, and are identified with a lock icon for the 'locked' property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous 'manual' approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP configurator, and are shown in the following tables for easy reference.
Configuration Settings for the On-Board Profile on RL78G1D BLE Framework
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enables or disables the parameter checking. |
| Heart Rate Profile | Enabled, Disabled Default: Enabled | Heart rate profile selection. |
| Alert Notification Profile | Enabled, Disabled Default: Disabled | Alert notification profile selection. |
| Blood Pressure Profile | Enabled, Disabled Default: Disabled | Blood pressure profile selection. |
| Find Me Profile | Enabled, Disabled Default: Disabled | Find me profile selection. |
| HID Over GATT Profile | Enabled, Disabled Default: Disabled | HID gatt profile selection. |
| Health Thermometer Profile | Enabled, Disabled Default: Disabled | Health thermometer profile selection. |
| Phone Status Alert Profile | Enabled, Disabled Default: Disabled | Phone alert profile selection. |
| Proximity Profile | Enabled, Disabled Default: Disabled | Proximity profile selection. |
| Scan Parameter Profile | Enabled, Disabled Default: Disabled | Scan parameter profile selection. |
| Time Profile | Enabled, Disabled Default: Disabled | Time profile selection. |
| Name | g_sf_ble_onboard_profile0 | Module name. |
| Name of generated initialization function | sf_ble_rl78g1d_onboard_profile_init0 | Name of generated initialization function. |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection. |
Configuration Settings for the BLE GAP and GATT on sf_ble_rl78g1d
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enables or disables the parameter checking. |
| Name | g_sf_ble0 | Module name. |
| Bluetooth Device Address (Restart Board after first run to see changed Address) | {0x0, 0x0, 0x0, 0x0, 0x0} | Bluetooth device address selection. |
| Address Type | Public Address, Random Address Default: Public Address | Address type selection. |
| Scan Interval | 48 | Scan interval selection. |
| Scan Window | 48 | Scan window selection. |
| Maximum Connection Interval | 40 | Maximum connection interval selection. |
| Connection Slave Latency | 0 | Connection slave latency selection. |
| Supervision Timeout | 80 | Supervision timeout selection. |
| BLE Driver Thread Priority | 1 | BLE Driver thread priority selection. |
| BLE Serial Thread Priority | 1 | BLE Serial thread priority selection. |
| Name of generated initialization function | sf_ble_rl78g1d_init0 | Name of generated initialization function. |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection. |
Typically, only a small number of settings must be modified from the default for lower-level drivers as indicated with red text in the thread stack block. Notice that some of the configuration properties must be set to a certain value for proper framework operation and will be locked to prevent user modification. The following tables identify all the settings within the properties section for the lower-level modules.
Configuration Settings for the Timer Driver on r_gpt
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enables or disables the parameter checking. |
| Name | g_timer0 | Module name. |
| Channel | 0 | Channel selection. |
| Mode | Periodic | Warning: One-shot functionality is not available in the GPT hardware, so it is implemented in software by stopping the timer in the ISR, called when the period expires. For this reason, ISRs must be enabled for one-shot mode even if the callback is unused. |
| Duty Cycle Range (only applicable in PWM mode) | Shortest: 2 PCLK, Longest (Period-1) PCLK/Shortest: 1 PCLK, Longest: (Period-2) PCLK Default: Shortest 2 PCLK, Longest: (Period-1) PCLK | Select the duty cycle range. Due to hardware limitations, one PCLK is added before the output pin toggles after the duty cycle is reached. This extra clock cycle is added to the ON time (if Shortest: 2 PCLK is selected) or the OFF time (if Shortest: 1 PCLK is selected) based on this configuration. |
| Period Value | 10 | See Timer Period Calculation. |
| Period Unit | Milliseconds | See Timer Period Calculation. |
| Duty Cycle Value | 50 | Duty cycle value selection. |
| Duty Cycle Unit | Unit Raw Counts | Duty cycle unit selection. |
| Auto Start | True | Set to true to start the timer after configuring or false to leave the timer stopped until timer_api_t::start is called. |
| GTIOCA Output Enabled | False | Set to true to output the timer signal on a port pin configured for GPT. Set to false for no output of the timer signal. |
| GTIOCA Stop Level | Pin Level Low | Controls output pin level when the timer is stopped. |
| GTIOCB Output Enabled | False | Set to true to output the timer signal on a port pin configured for GPT. Set to false for no output of the timer signal. |
| GTIOCB Stop Level | Pin Level Low | Controls output pin level when the timer is stopped. |
| Callback | RBLE_Timer_cb | A user callback function can be registered in timer_api_t::open. If this callback function is provided, it will be called from the interrupt service routine (ISR) each time the timer period elapses. Warning: Since the callback is called from an ISR, care should be taken not to use blocking calls or lengthy processing. Spending excessive time in an ISR can affect the responsiveness of the system. |
| Overflow Interrupt Priority | Priority 0 (highest), Priority 1:2, Priority 3 (lowest - not valid if using ThreadX), Disabled Default: Disabled | Overflow interrupt priority selection. |
The BLE Framework module uses the clocks specified by the lower-level modules.
The BLE Framework module uses the pins specified by the lower-level modules.
The steps in using the Bluetooth Low Energy Framework module in a typical application are:
1. Initialization- registration of callback functions, provisioning, and advertisement using the sf_ble_api_t::open API.
2. Provision the BLE module using the sf_ble_api_t::provisionSet API.
3. Scan for advertisement using the sf_ble_api_t::scan API.
4. Connect to remote BLE device using the sf_ble_api_t::connect API.
5. Enable the on-board profile using the sf_ble_onboard_profile_api_t::onbpEnable API.
6. Enable notification using the sf_ble_onboard_profile_api_t::onbpClientWriteCCCD API.
7. Write profile characteristics using the sf_ble_onboard_profile_api_t::onbpServerWriteData API.
8. Read profile characteristics using the sf_ble_onboard_profile_api_t::onbpClientReadChar API.
9. Disable the profile using the sf_ble_onboard_profile_api_t::onbpDisable API.
10. Disconnect from the remote BLE device using the sf_ble_api_t::disconnect API.
11. Close the BLE module using the sf_ble_api_t::close API.
The following figure illustrates common steps in a typical operational flow diagram:
