Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nimble: Added Walkthrough tutorial for phy_prph example. (IDFGH-9693) #11034

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,347 @@
# BLE Peripheral PHY Example Walkthrough

## Introduction

In this tutorial, the ble_phy peripheral example code for the espressif chipsets with BLE5.0 support is reviewed.This example aims at understanding how to accept incoming connections on preferred PHY and process the request to change LE PHY once the connection is established.The code implements a BLE Peripheral PHY, which establishes a connection on LE 1M PHY and switches to LE 2M PHY/CODED once the connection is established.
## Includes

This example is located in the examples folder of the ESP-IDF under the [ble_phy/phy_prph/main](../main/). The [main.c](../main/main.c) file located in the main folder contains all the functionality that we are going to review. The header files contained in [main.c](../main/main.c) are:

```c
#include "esp_log.h"
#include "nvs_flash.h"

/* BLE */
#include "nimble/nimble_port.h"
#include "nimble/nimble_port_freertos.h"
#include "host/ble_hs.h"
#include "host/util/util.h"
#include "console/console.h"
#include "services/gap/ble_svc_gap.h"
#include "phy_prph.h"
```

These `includes` are required for the FreeRTOS and underlying system components to run, including the logging functionality and a library to store data in non-volatile flash memory. We are interested in `“nimble_port.h”`, `“nimble_port_freertos.h”`, `"ble_hs.h"` and `“ble_svc_gap.h”`, `“phy_prph.h”` which expose the BLE APIs required to implement this example.

* `nimble_port.h`: Includes the declaration of functions required for the initialization of the nimble stack.
* `nimble_port_freertos.h`: Initializes and enables nimble host task.
* `ble_hs.h`: Defines the functionalities to handle the host event
* `ble_svc_gap.h`:Defines the macros for device name and device appearance and declares the function to set them.
* `phy_prph.h`: Defines the macro name `LE_PHY_UUID16` and `LE_PHY_CHR_UUID16`.

## Main Entry Point

The program’s entry point is the app_main() function:

```c
void
app_main(void)
{
int rc;

/* Initialize NVS — it is used to store PHY calibration data */
esp_err_t ret = nvs_flash_init();
if (ret == ESP_ERR_NVS_NO_FREE_PAGES || ret == ESP_ERR_NVS_NEW_VERSION_FOUND) {
ESP_ERROR_CHECK(nvs_flash_erase());
ret = nvs_flash_init();
}
ESP_ERROR_CHECK(ret);

//ESP_ERROR_CHECK(esp_nimble_hci_and_controller_init());

ret = nimble_port_init();
if (ret != ESP_OK) {
MODLOG_DFLT(ERROR, "Failed to init nimble %d \n", ret);
return;
}

/* Initialize the NimBLE host configuration. */
ble_hs_cfg.reset_cb = bleprph_on_reset;
ble_hs_cfg.sync_cb = bleprph_on_sync;
ble_hs_cfg.gatts_register_cb = gatt_svr_register_cb;
ble_hs_cfg.store_status_cb = ble_store_util_status_rr;

ble_hs_cfg.sm_io_cap = CONFIG_EXAMPLE_IO_TYPE;
#ifdef CONFIG_EXAMPLE_BONDING
ble_hs_cfg.sm_bonding = 1;
#endif
#ifdef CONFIG_EXAMPLE_MITM
ble_hs_cfg.sm_mitm = 1;
#endif
#ifdef CONFIG_EXAMPLE_USE_SC
ble_hs_cfg.sm_sc = 1;
#else
ble_hs_cfg.sm_sc = 0;
#endif
#ifdef CONFIG_EXAMPLE_BONDING
ble_hs_cfg.sm_our_key_dist = 1;
ble_hs_cfg.sm_their_key_dist = 1;
#endif

rc = gatt_svr_init_le_phy();
assert(rc == 0);

/* Set the default device name. */
rc = ble_svc_gap_device_name_set("bleprph-phy");
assert(rc == 0);

/* XXX Need to have template for store */
ble_store_config_init();

nimble_port_freertos_init(bleprph_host_task);

/* Initialize command line interface to accept input from user */
rc = scli_init();
if (rc != ESP_OK) {
ESP_LOGE(tag, "scli_init() failed");
}
}
```

The main function starts by initializing the non-volatile storage library. This library allows us to save the key-value pairs in flash memory.`nvs_flash_init()` stores the PHY calibration data. In a Bluetooth Low Energy (BLE) device, cryptographic keys used for encryption and authentication are often stored in Non-Volatile Storage (NVS).BLE stores the peer keys, CCCD keys, peer records, etc on NVS. By storing these keys in NVS, the BLE device can quickly retrieve them when needed, without the need for time-consuming key generations.
```c
esp_err_t ret = nvs_flash_init();
if (ret == ESP_ERR_NVS_NO_FREE_PAGES || ret == ESP_ERR_NVS_NEW_VERSION_FOUND) {
ESP_ERROR_CHECK(nvs_flash_erase());
ret = nvs_flash_init();
}
ESP_ERROR_CHECK( ret );
```

## BT Controller and Stack Initialization
The main function calls `nimble_port_init()` to initialize BT Controller and nimble stack. This function initializes the BT controller by first creating its configuration structure named `esp_bt_controller_config_t` with default settings generated by the `BT_CONTROLLER_INIT_CONFIG_DEFAULT()` macro. It implements the Host Controller Interface (HCI) on the controller side, the Link Layer (LL), and the Physical Layer (PHY). The BT Controller is invisible to the user applications and deals with the lower layers of the BLE stack. The controller configuration includes setting the BT controller stack size, priority, and HCI baud rate. With the settings created, the BT controller is initialized and enabled with the `esp_bt_controller_init()` and `esp_bt_controller_enable()` functions:

```c
esp_bt_controller_config_t config_opts = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
ret = esp_bt_controller_init(&config_opts);
```

Next, the controller is enabled in BLE Mode.

```c
ret = esp_bt_controller_enable(ESP_BT_MODE_BLE);
```
>The controller should be enabled in `ESP_BT_MODE_BLE` if you want to use the BLE mode.

There are four Bluetooth modes supported:

1. `ESP_BT_MODE_IDLE`: Bluetooth not running
2. `ESP_BT_MODE_BLE`: BLE mode
3. `ESP_BT_MODE_CLASSIC_BT`: BT Classic mode
4. `ESP_BT_MODE_BTDM`: Dual mode (BLE + BT Classic)

After the initialization of the BT controller, the nimble stack, which includes the common definitions and APIs for BLE, is initialized by using `esp_nimble_init()`:

```c
esp_err_t esp_nimble_init(void)
{

#if !SOC_ESP_NIMBLE_CONTROLLER
/* Initialize the function pointers for OS porting */
npl_freertos_funcs_init();

npl_freertos_mempool_init();

if(esp_nimble_hci_init() != ESP_OK) {
ESP_LOGE(NIMBLE_PORT_LOG_TAG, "hci inits failed\n");
return ESP_FAIL;
}

/* Initialize default event queue */
ble_npl_eventq_init(&g_eventq_dflt);

os_msys_init();

void ble_store_ram_init(void);
/* XXX Need to have template for store */
ble_store_ram_init();
#endif

/* Initialize the host */
ble_hs_init();
return ESP_OK;
}
```

The host is configured by setting up the callbacks on Stack-reset, Stack-sync, registration of each GATT resource, and storage status.

```c
ble_hs_cfg.reset_cb = blecent_on_reset;
ble_hs_cfg.sync_cb = blecent_on_sync;
ble_hs_cfg.gatts_register_cb = gatt_svr_register_cb;
ble_hs_cfg.store_status_cb = ble_store_util_status_rr;
```

The Security Manager is configured by setting up the following SM's flag and attributes of the host

1. sm_io_cap: This attribute represents Security Manager's Local Input Output Capabilities.
2. sm_bonding: It represents Security Manager Bond Flag.
3. sm_mitm : It represents the Security Manager MITM Flag which results in requiring Man-In-The-Middle protection while pairing if it is set.
4. sm_sc: It represents Security Manager Secure Connections Flag.
5. sm_our_key_dist: It represents Security Manager's local key distribution mask.
6. sm_their_key_dist: It represents Security Manager remote key distribution mask.

```c
ble_hs_cfg.sm_io_cap = CONFIG_EXAMPLE_IO_TYPE;
#ifdef CONFIG_EXAMPLE_BONDING
ble_hs_cfg.sm_bonding = 1;
#endif
#ifdef CONFIG_EXAMPLE_MITM
ble_hs_cfg.sm_mitm = 1;
#endif
#ifdef CONFIG_EXAMPLE_USE_SC
ble_hs_cfg.sm_sc = 1;
#else
ble_hs_cfg.sm_sc = 0;
#endif
#ifdef CONFIG_EXAMPLE_BONDING
ble_hs_cfg.sm_our_key_dist = 1;
ble_hs_cfg.sm_their_key_dist = 1;
#endif
```

The main function calls `ble_svc_gap_device_name_set()` to set the default device name. 'bleprph_phy' is passed as the default device name to this function.
```c
rc = ble_svc_gap_device_name_set("bleprph-phy");
```

main function calls `ble_store_config_init()` to configure the host by setting up the storage callbacks which handle the read, write, and deletion of security material.
```c
/* XXX Need to have a template for store */
ble_store_config_init();
```


The main function ends by creating a task where nimble will run using `nimble_port_freertos_init()`. This enables the nimble stack by using `esp_nimble_enable()`.
```c
nimble_port_freertos_init(bleprph_host_task);

```
`esp_nimble_enable()` create a task where the nimble host will run. It is not strictly necessary to have a separate task for the nimble host, but since something needs to handle the default queue, it is easier to create a separate task.


## Intializaion of LE PHY to Default 1M PHY.
1M PHY is the default PHY for BLE devices which enables it to provide a data rate of 1 Mbps. It is used while establishing the connection between devices and maintains backward compatibility with all those devices that don't have BLE5.0 support.`set_default_le_phy_before_conn()` function set default LE PHY before establishing a connection.

```c
void set_default_le_phy_before_conn(uint8_t tx_phys_mask, uint8_t rx_phys_mask)
{
int rc = ble_gap_set_prefered_default_le_phy(tx_phys_mask, rx_phys_mask);
if (rc == 0)
{
MODLOG_DFLT(INFO, "Default LE PHY set successfully; tx_phy = %d, rx_phy = %d",
tx_phys_mask, rx_phys_mask);
} else {
MODLOG_DFLT(ERROR, "Failed to set default LE PHY");
}
}
```

## Changing Default LE PHY to Preferred PHY.

2M PHY is introduced in BLE5.0 to increase the symbol rate at the physical layer. It provides a symbol rate of 2 Mega symbols per second where each symbol corresponds to a single bit. This allows the user to double the number of bits sent over the air during a given period, or conversely reduce energy consumption for a given amount of data by having the necessary transmit time.

The following lines change the default LE PHY to the preferred PHY.
As the phy_cent disconnects the connection link with the peripheral, `BLE_GAP_EVENT_DISCONNECT` event occurs, and the peripheral changes the value of `s_current_phy` to the next LE PHY. It then starts advertising again with the same process.

```c
case BLE_GAP_EVENT_DISCONNECT:
MODLOG_DFLT(INFO, "disconnect; reason=%d ", event->disconnect.reason);
bleprph_print_conn_desc(&event->disconnect.conn);
MODLOG_DFLT(INFO, "\n");

/* Connection terminated; resume advertising. */

#if CONFIG_EXAMPLE_EXTENDED_ADV
switch (s_current_phy) {
case BLE_HCI_LE_PHY_1M_PREF_MASK:
/* Setting current phy to create a connection on 2M PHY */
s_current_phy = BLE_HCI_LE_PHY_2M_PREF_MASK;
break;

case BLE_HCI_LE_PHY_2M_PREF_MASK:
/* Setting current phy to create a connection on CODED PHY */
s_current_phy = BLE_HCI_LE_PHY_CODED_PREF_MASK;
break;

case BLE_HCI_LE_PHY_CODED_PREF_MASK:
return 0;

default:
return 0;
}
set_default_le_phy_before_conn(s_current_phy, s_current_phy);
ext_bleprph_advertise();
#else
bleprph_advertise();
#endif
```


## Advertisement Functionalities

To support increased messaging, BLE5.0 is added with extended advertising PDUs. These PDUs are broadcast-only events (like electronic beacons). The following function is used to make extended advertisements. In Bluetooth® 4.0, all advertising was done on 3 of the 40 – 2.4GHz ISM band channels. With Bluetooth 5 there are now two sets of advertising channels: primary and secondary. The primary advertising channels are the original 3 of the 40 advertising channels defined in Bluetooth® 4.0 While the secondary advertising channels use the 37 fixed channels previously reserved for data.

As the value of `s_current_phy` keeps changing , the advertising data also gets modified.


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a line describing, that as s_current_phy value keeps changing , the advertising data also gets modified.

```c
static void
ext_bleprph_advertise(void)
{
struct ble_gap_ext_adv_params params;
struct os_mbuf *data = NULL;
uint8_t instance = 1;
int rc;

/* use defaults for non-set params */
memset (&params, 0, sizeof(params));

/* enable connectable advertising */
params.connectable = 1;
params.scannable = 1;
params.legacy_pdu = 1;

/* advertise using random addr */
params.own_addr_type = BLE_OWN_ADDR_PUBLIC;

/* Set current phy; get mbuf for scan rsp data; fill mbuf with scan rsp data */
switch (s_current_phy) {
case BLE_HCI_LE_PHY_1M_PREF_MASK:
params.primary_phy = BLE_HCI_LE_PHY_1M;
params.secondary_phy = BLE_HCI_LE_PHY_1M;
data = ext_get_data(ext_adv_pattern_1M, sizeof(ext_adv_pattern_1M));
break;

case BLE_HCI_LE_PHY_2M_PREF_MASK:
params.primary_phy = BLE_HCI_LE_PHY_1M;
params.secondary_phy = BLE_HCI_LE_PHY_2M;
data = ext_get_data(ext_adv_pattern_2M, sizeof(ext_adv_pattern_2M));
break;

case BLE_HCI_LE_PHY_CODED_PREF_MASK:
params.primary_phy = BLE_HCI_LE_PHY_CODED;
params.secondary_phy = BLE_HCI_LE_PHY_CODED;
data = ext_get_data(ext_adv_pattern_coded, sizeof(ext_adv_pattern_coded));
break;
}

//params.tx_power = 127;
params.sid = 1;

params.itvl_min = BLE_GAP_ADV_FAST_INTERVAL1_MIN;
params.itvl_max = BLE_GAP_ADV_FAST_INTERVAL1_MIN;

/* configure instance 0 */
rc = ble_gap_ext_adv_configure(instance, &params, NULL,
bleprph_gap_event, NULL);
assert (rc == 0);

rc = ble_gap_ext_adv_set_data(instance, data);
assert (rc == 0);

/* start advertising */
rc = ble_gap_ext_adv_start(instance, 0, 0);
assert (rc == 0);
}
```