Hi,

You are setting no input no output capability, which can only support "Just works" in the pairing process. However, if you need authentication, you can't use this, you need display or input keyboard. For more information, I would suggest you to go through the security section of below link.

https://docs.silabs.com/bluetooth/latest/general/security/pairing-processes

Thanks,

Kevin

Hi,

You need to add more include paths, the easiest way is to copy all the include path settings from Simplicity Studio, or the output of "make" to the target_include_directories command. E.g, if you build any example, you will see console output information like below:

arm-none-eabi-gcc -g -gdwarf-2 -mcpu=cortex-m4 -mthumb -std=c99 '-D__StackLimit=0x20000000' '-DHAL_CONFIG=1' '-D__STACK_SIZE=0x800' '-D__HEAP_SIZE=0xD00' '-DEFR32BG13P632F512GM48=1' -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/service/sleeptimer/config" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emlib/src" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/protocol/bluetooth/ble_stack/inc/common" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/CMSIS/Include" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/Device/SiliconLabs/EFR32BG13P/Include" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emlib/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/hardware/kit/common/halconfig" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/hardware/kit/common/bsp" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/hardware/kit/common/drivers" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/service/sleeptimer/src" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/radio/rail_lib/protocol/ieee802154" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emdrv/uartdrv/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emdrv/gpiointerrupt/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/Device/SiliconLabs/EFR32BG13P/Source" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emdrv/common/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/radio/rail_lib/common" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emdrv/sleep/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/protocol/bluetooth/ble_stack/inc/soc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/emdrv/sleep/src" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/radio/rail_lib/protocol/ble" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/service/sleeptimer/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/hardware/kit/EFR32BG13_BRD4104A/config" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/radio/rail_lib/chip/efr32/efr32xg1x" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/app/bluetooth/common/util" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/bootloader/api" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/halconfig/inc/hal-config" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/common/inc" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/Device/SiliconLabs/EFR32BG13P/Source/GCC" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se" -I"/Users/zhfu/SimplicityStudio/v4_workspace/bg13_se/platform/bootloader" -O2 -Wall -c -fmessage-length=0 -ffunction-sections -fdata-sections -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -MMD -MP -MF"platform/emlib/src/em_gpio.d" -MT"platform/emlib/src/em_gpio.o" -o "platform/emlib/src/em_gpio.o" "../platform/emlib/src/em_gpio.c"
 

then put all the paths with "-I" flag to the target_include_directories

Thanks,

Kevin

Hi,

Yes, if any attempt to access the attribute which requires encryption, the stack will try to initiate pairing. You can also explicitly call the gecko_cmd_sm_increase_security to force pairing any time you want.

Thanks,

Kevin

Hi,

You can use the gecko_cmd_mesh_test_get_local_model_pub to get the publication information including the address, just be noted you need to initialize the mesh test class in the beginning.

Thanks,

Kevin

NOTE

• Bluetooth Low Energy (BLE) Knowledge Base Articles are now moved to https://docs.silabs.com/bluetooth/latest/. They are not maintained any more.

• Bluetooth Mesh Knowledge Base Articles are still VALID and maintained here.

Introduction

This Knowledge Base Article (KBA) aims to act as a “master” KBA which keeps a curated index of all the Bluetooth related KBAs divided into logical categories for an easier and more convenient look-up. It may also include non-KBA content which is relevant for designing your Bluetooth application (e.g. app notes or web pages).

If you are just getting started with Silicon Labs Bluetooth solutions then your starting point should be QSG139: Getting Started with Bluetooth® Software Development. At the end of that document you are presented with the flowchart below which shows what documents should be read and in which order. Additionally you can check out our Bluetooth Training page for more training material.

Knowledge Base Articles List

The content listed below is grouped together into categories to make it easier for you to find what you are looking for. Want to know more about security, or looking for a peripheral example, then head down to the right section and see what KBAs or other relevant content has been created under those topics.

Each category has an associated index number and each individual KBA has its own index number within the category. The KBA's are prefixed with KBA_BT_AABB where AA is the category index and BB is the KBA index within that category. The category index numbers are as follows:

• [01] Bluetooth - General
• [02] Bluetooth - Advertising
• [03] Bluetooth - Stack features
• [04] Bluetooth - Performance
• [05] Bluetooth - Bluetooth Mesh
• [06] Bootloading - General
• [07] Bootloading - UART DFU
• [08] Bootloading - OTA DFU
• [09] Application Examples
• [10] Peripheral Examples
• [11] Security
• [12] Tools
• [13] Hardware
• [14] Migration
• [15] Mobile
• [16] NCP

Note: Do you want to get automatic notifications when new content is added to the list? Just click the Follow button in upper right corner to subscribe to email notifications. We will make comments when new content is created to trigger those notifications.

[01] Bluetooth General

• KBA_BT_0101: Selecting Your Blue Gecko SoC/Module
• KBA_BT_0102: BLE Basics (master/slave, GATT client/server, data RX/TX)
• KBA_BT_0103: Understanding the Bluetooth Connection Process
• KBA_BT_0104: Acknowledged vs Unacknowledged GATT operations 
• KBA_BT_0105: Bluetooth 5 Features 
• KBA_BT_0106: Bluetooth SIG Resources 
• KBA_BT_0107: Bluetooth Stack Operations Flowcharts

[02] Bluetooth - Advertising

• KBA_BT_0201: Bluetooth advertising data basics 
• KBA_BT_0202: Bluetooth advertising using manufacturer specific data 
• KBA_BT_0203: Providing Extra Data by Scan Response 
• KBA_BT_0204: Using scan request reporting
• KBA_BT_0205: Advertisement Constructor 
• KBA_BT_0206: Extended Advertising Example 
• KBA_BT_0207: Periodic Advertising
• KBA_BT_0208: Chained Advertisements

[03] Bluetooth - Stack features

• KBA_BT_0301: LE Coded PHY on EFR32xG13
• KBA_BT_0302: Advertising and Scanning with LE Coded PHY 
• KBA_BT_0304: Different characteristic value types 
• KBA_BT_0305: Handling GPIO Interrupts using External Signals 
• KBA_BT_0306: Using the lazy soft timer
• KBA_BT_0307: Enabling TX/RX activity indicator pins in BLE SDK 2.4.0 and later 
• KBA_BT_0308: Polymorphic GATT 
• KBA_BT_0309: How to save float values (or any arbitrary data) in PS keys
• KBA_BT_0310: Changes to the le_gap class of API functions
• KBA_BT_0311: Whitelisting
• KBA_BT_0312: Service Change Indications 
• KBA_BT_0313: GATT Caching

[04] Bluetooth - Performance

• KBA_BT_0401: Optimizing Current Consumption in Bluetooth Low Energy Devices 
• KBA_BT_0402: EM3 and EM4S for non-connectable advertising 
• KBA_BT_0403: Using Energy Modes with Bluetooth Stack 
• KBA_BT_0404: Throughput with Bluetooth Low Energy technology
• KBA_BT_0405: Bluetooth Tx power settings
• KBA_BT_0406: Adaptive Frequency Hopping
• KBA_BT_0407: Bluetooth Radio Task Priorities
• KBA_BT_0408: Current consumption during advertising with different Tx power setting
• KBA_BT_0409: Using the PLFRCO as low-frequency clock source
• KBA_BT_0410: TX power limitations for regulatory compliance (ETSI, FCC)

[05] Bluetooth - Bluetooth Mesh

• KBA_BT_0501: BT Mesh embedded provisioner example 
• KBA_BT_0502: Bluetooth Mesh Vendor Specific Model Example 
• KBA_BT_0503: Bluetooth Mesh Advertising Sets
• KBA_BT_0505: Bluetooth Mesh Training resources
• KBA_BT_0506: Minimalistic OnOff client for testing Bluetooth Mesh on custom board
• KBA_BT_0507: Bluetooth Mesh Host Switch Example
• KBA_BT_0508: Scanning BLE beacons in Bluetooth Mesh mode 
• KBA_BT_0509: Bluetooth Mesh Host Provisioner
• KBA_BT_0510: Blacklisting Nodes From Bluetooth Mesh Network
• KBA_BT_0512: Bluetooth Mesh Proxy Client Example
• KBA_BT_0513: IV Update & Recovery Procedure and Sequence Number Storing Strategy
• KBA_BT_0515: Bluetooth Mesh Mobile - Import/Export Functionalities Concepts
• KBA_BT_0517: Bluetooth Mesh Node Reset Procedure
• KBA_BT_0518: Self provisioning and configuration example

[06] Bootloading - General

• KBA_BT_0601: Why Doesn't My Sample Application Run?
• KBA_BT_0602: Bootloader changes in BLE SDK
• KBA_BT_0603: Adding Gecko Bootloader to Bluetooth projects
• KBA_BT_0604: Switching between firmware images using Internal Storage Bootloader
• KBA_BT_0605: Upgrading Gecko Bootloader
• KBA_BT_0606: Upgrading Gecko Bootloader with Slot address change
• KBA_BT_0607: Adding metadata to GBL files 
• KBA_BT_0608: Factory programmed firmware of Bluetooth devices

[07] Bootloading - UART DFU

• KBA_BT_0701: Upgrading from factory firmware (v2.0.0) and from Bluetooth SDK v2.1.x with UART DFU type legacy bootloader
• KBA_BT_0702: UART DFU - Upgrading BGM111 by EFM32PG example 

[08] Bootloading - OTA DFU

• KBA_BT_0801: Using Blue Gecko app OTA
• KBA_BT_0802: Uploading images to internal/external flash using OTA DFU 
• KBA_BT_0803: Bluetooth OTA updates using customized advertising data
• KBA_BT_0804: Secure OTA DFU
• KBA_BT_0805: Setting Bluetooth Address as device name in OTA 
• KBA_BT_0806: Using BLED112 to do Over-the-Air update of BGMxxx 
• KBA_BT_0807: Implementing OTA firmware update in the user application
• KBA_BT_0808: OTA options for NCP-based designs 

[09] Application Examples

• KBA_BT_0901: Bluetooth SoC-Empty example
• KBA_BT_0902: How to use Voice over Bluetooth Low Energy example for Thunderboard Sense
• KBA_BT_0903: SPP-over-BLE example 
• KBA_BT_0904: Creating an Eddystone-URL Beacon 
• KBA_BT_0905: SPP client example using BLED112 dongle 
• KBA_BT_0906: Multi-Slave Multi-Master Dual-Topology example 
• KBA_BT_0907: Parallel handling of multiple slaves with Bluetooth stack 
• KBA_BT_0908: Using RTCC as Timer or Calendar while running BLE stack 
• KBA_BT_0909: Scheduling application tasks while running BLE stack
• KBA_BT_0910: Using the UD flash in the Bluetooth C SDK 
• KBA_BT_0911: Midi over BLE 
• KBA_BT_0912: Control LEDs on a Wireless Starter Kit from a Mobile App 
• KBA_BT_0913: BLE Central and GATT client example - working with an Android app 
• KBA_BT_0914: ANCS 
• KBA_BT_0915: Throughput Tester Example 
• KBA_BT_0916: Working with Long Characteristic Values 
• KBA_BT_0917: Implementing wireless direct test mode (DTM) 
• KBA_BT_0919: Using EM3 or EM4 energy mode in a Bluetooth beacon app 
• KBA_BT_0920: Bluetooth Device Tracking with Tile
• KBA_BT_0921: Using Mbedtls with BLE 

[10] Peripheral Examples

• KBA_BT_1001: Using the LEUART 
• KBA_BT_1002: Using Low Energy Timers 
• KBA_BT_1003: Using accelerometer found in the WSTK expansion board 
• KBA_BT_1004: Hardware Timers with EFR32xG1x 
• KBA_BT_1005: Reporting Battery Voltage over BLE 
• KBA_BT_1006: Thermometer example with EFR32 internal temperature sensor 
• KBA_BT_1007: Enable LCD screen on WSTK 
• KBA_BT_1008: Watchdog on BGM111 (and other Blue Gecko modules / boards) 
• KBA_BT_1009: Waking from Deep Sleep Using RF Sense 
• KBA_BT_1010: Push buttons and interrupts in a Bluetooth project 
• KBA_BT_1011: How can I extend the Bluetooth examples with UART functionality? 
• KBA_BT_1012: Adding Watchdog in NCP Mode

Additional Resources

• MCU Peripheral Examples on GitHub (also includes EFR32)

[11] Security

• KBA_BT_1101: Using Bluetooth security features in Silicon Labs Bluetooth SDK
• KBA_BT_1102: Pairing Processes
• KBA_BT_1103: Application Layer Security 
• KBA_BT_1104: The New Bond Replacement Algorithm
• KBA_BT_1105: How to handle missing bonding keys 
• KBA_BT_1106: OOB introduction and example 
• KBA_BT_1107: Secure connection with serial communication between two BGM modules 
• KBA_BT_1108: Authenticating Bluetooth Devices with no User Interface 

[12] Tools

• KBA_BT_1201: Condensed Bluetooth SDK revision history (2.0.0 and later)
• KBA_BT_1202: Building C++ BLE projects
• KBA_BT_1203: Creating projects for EFR32BG on a custom board
• KBA_BT_1204: How to flash BGM11x or EFR32BG from command line?
• KBA_BT_1205: Programming an external BGM111 using the WSTK
• KBA_BT_1206: Log System
• KBA_BT_1207: Event and Error Checking 
• KBA_BT_1208: Using virtual COM port (VCOM)
• KBA_BT_1209: Debugging BGTool not being able to communicate with NCP target.
• KBA_BT_1210: Connect Custom board to Simplicity Studio using JTAG/SWD.

Additional Resources

• Simplicity Studio now Treats Bluetooth Modules as Parts

[13] Hardware

• KBA_BT_1301: How to find schematics and other documentation for radio boards?
• KBA_BT_1302: Supplying EFR32 PAVDD from 3.3V
• KBA_BT_1303: Enabling LNA on MGM12P for Bluetooth usage
• KBA_BT_1304: Antenna tuning for BGM12x (coin-cell usage example)
• KBA_BT_1305: Quartz Crystals, MEMS Oscillators, and Phase Noise for BLE Applications
• KBA_BT_1306: TX Power Levels 
• KBA_BT_1307: What is a STEP file and how to obtain a STEP file for Silicon Labs IOT products?
• KBA_BT_1308: Saving CTUNE value as manufacturing token
• KBA_BT_1309: Design and Assembly guidelines when using xGM parts based System in Package (SiP)

Additional Resources

• Debugging and Programming Interfaces for Custom Designs
• Production Programming Options for Silicon Labs Devices
• RF Range Calculator
• Driving FEMs (and PAs and LNAs) on EFR32

[14] Migration

• KBA_BT_1401: Updating NCP projects to SDK 2.4.x
• KBA_BT_1402: Bluetooth Smart SDK Migration Guide From V2.0.1 to V2.1.x
• KBA_BT_1403: Migrating Simplicity Studio projects from Bluetooth SDK 2.1.1 to 2.3.1
• KBA_BT_1404: Migrating Simplicity Studio projects from Bluetooth SDK 2.3.x to 2.4.x
• KBA_BT_1405: Migration guide to Bluetooth SDK 2.7.x
• KBA_BT_1406: Migrating Bluetooth Projects between SDK Releases

[15] Mobile

• KBA_BT_1501: BLE devices on iOS Bluetooth Settings page
• KBA_BT_1502: Evaluating SPP-over-BLE example using BLE1xx cable replacement app 
• KBA_BT_1503: iOS 9.1 with respect to Bluetooth LE
• KBA_BT_1504: Mobile Devices used for Interoperability Testing
• KBA_BT_1505: Selecting suitable connection parameters for iOS 
• KBA_BT_1506: How to find the Bluetooth 5 feature status of a listed device such as a smartphone

[16] NCP

• KBA_BT_1602: NCP Host Implementation and Example 
• KBA_BT_1603: Local Event Handling on Bluetooth NCP 

This article describes:

• Advertising Sets
• Advertising Sets Used by Bluetooth Mesh stack
• Adding Customized Advertising Sets to Bluetooth Mesh Applications

Advertising Sets

Advertising Sets are defined in Section 4.4.2.10, Part B, Vol 6, Bluetooth Specification Version 5.2. With advertising sets supported, Bluetooth stack actually provides a way to interleave multiple advertising events. Each advertising set has its own parameters, payload, timing etc. and is independed to the other advertising sets. For example, if you want to send a connectable advertisement and a non-connectable beacon simultaneously, you don't necessarily need to send the connectable advertisement once then modify the content and parameters to send the non-connectable beacon repeatedly, this will easy to achieve by using 2 advertising sets.

Advertising Sets Used by Bluetooth Mesh Stack

When the Bluetooth stack initializes, user application needs to configure the number of the maximum advertising sets used by both the stack and application. Other than the regular BLE examples, which typically don't use any advertising set, the Bluetooth Mesh stack uses some advertising sets to send data. You can find below inline description of the advertising sets used by Bluetooth Mesh stack in the main.c file of all Bluetooth Mesh examples.

/// Bluetooth advertisement set configuration
///
/// At minimum the following is required:
/// * One advertisement set for Bluetooth LE stack (handle number 0)
/// * One advertisement set for Mesh data (handle number 1)
/// * One advertisement set for Mesh unprovisioned beacons (handle number 2)
/// * One advertisement set for Mesh unprovisioned URI (handle number 3)
/// * N advertisement sets for Mesh GATT service advertisements
/// (one for each network key, handle numbers 4 .. N+3)
///
#define MAX_ADVERTISERS (4 + MESH_CFG_MAX_NETKEYS)

Here is a more verbose explanation for each set:

Advertising Set 0 - Reserved for Application

This advertising set is reserved for regular BLE advertising. It's created when the stack initializes by default and ready to be used by the application. For example, you can call the API gecko_cmd_le_gap_start_advertising with handle 0 to start advertising with this advertising set. This is NOT used by the Bluetooth Mesh stack, but has to be counted into the maximum number of the advertising sets.

Advertising Set 1 - Bluetooth Mesh Data

This advertising set is used for Bluetooth Mesh data traffic, which is the traffic happens on the Advertising bearer (section 3.3.1 of Mesh Profile v1.0.1) and PB-ADV (section 5.2.1 of Mesh Profile v1.0.1) . The stack is in control of the advertising data and the advertising parameters for this set, and the user application MUST NOT override the parameters or use this set for any other purpose.

Advertising Set 2 - Bluetooth Mesh Unprovisioned Device Beacon Without URI

This advertising set is used for sending the Unprovisioned Device Beacon (section 3.9.2 of Mesh Profile v1.0.1) when devices are in unprovisioned state. The Bluetooth Mesh stack will construct the advertising payload according to the definition of the Unprovisioned Device beacon format. User application shall not modify the advertising payload to this advertising set. What the user application can control in this case is the cadence for sending the Unprovisioned Device beacon, call the API - gecko_cmd_le_gap_set_advertise_timing with handle 2 BEFORE starting the Unprovisioned Device beacon.

Advertising Set 3 - Bluetooth Mesh Unprovisioned Device Beacon With URI

This advertising set is also used for sending the Unprovisioned Device Beacon (section 3.9.2 of Mesh Profile v1.0.1) when devices are in unprovisioned state. The only difference is there are 4-byte of URI hash appended to the data payload. See below lines from the Mesh Profile.

Along with the Unprovisioned Device beacon, the device may also advertise a separate non-connectable advertising packet with a Uniform Resource Identifier (URI) data type (as defined in [7]) that points to outof-band (OOB) information such as a public key. To allow the association of the advertised URI with the Unprovisioned Device beacon, the beacon may contain an optional 4-octet URI Hash field.

The latest Bluetooth Mesh stack doesn't support sending Unprovisioned Device beacon with URI, so this is reserved for future use.

Advertising Set 4 to N - Bluetooth Mesh Proxy Service Advertising

The usage of this advertising set is device state dependent.

If a device is in unprovisioned state, this advertising set will be used to advertise the Mesh Provisioning Service (section 7.1 of Mesh Profile v1.0.1) if the application call gecko_cmd_mesh_node_start_unprov_beaconing with PB-GATT bit set in the bearer parameter.

If a device is in provisioned state and supports Proxy feature, it shall start advertising the Mesh Proxy Service (section 7.2 of Mesh Profile v1.0.1) if the given situations are met. Alternatively, user application can start the advertising munally whenever the device is expected to connect to a proxy client.

Because a provisioned device could belong to multiple subnets, it could advertise multiple Mesh Proxy Service advertisements simultaneously. The maximum network key number that the device supports decides the maximum number of subnets the device can be in, so N is calculated to be 4 + the maximum network key on the device.

Adding Customized Advertising Sets to Bluetooth Mesh Applications

This example shows how to add your custom BLE advertising into a Bluetooth Mesh project.

Step 1: Increase the MAX_ADVERTISERS macro by the number of your custom advertising sets.

The .bluetooth.max_advertisers parameter in the gecko_configuration_t structure decides the maximum number of the advertising sets in the application. In all examples of the Bluetooth Mesh SDK, this value is feed by MAX_ADVERTISERS macro. So, modify the MAX_ADVERTISERS macro like below to add your own advertising sets.

/* Number of custom Advertising Sets */
#define MY_ADVERTISERS 2
#define MAX_ADVERTISERS (4 + MESH_CFG_MAX_NETKEYS + MY_ADVERTISERS)
/*
 * Advertising Set ID from the offset. E.g. to get the first custom advertising
 * set ID, put n as 1 like this - MY_ADVERTISING_SET_ID(1)
 */
#define MY_ADVERTISING_SET_ID(n)    (4 + MESH_CFG_MAX_NETKEYS + n)

Step 2: Configure the advertising sets if needed.

You can use the advertising configuration related APIs (gecko_cmd_le_gap_set_advertise_xxx) to configure the advertising sets specifically by the advertising set ID (handle), as well as the gecko_cmd_le_gap_bt5_set_adv_data to set the advertising payload. For more details about the advertising parameters and data payload format, you can check Bluetooth Advertising Data Basics. For constructing the advertising data in a much easier way, you can use the code example - Advertisement or Scan Response Constructor.

Step 3: Start the advertising sets

This is the final step to send your own advertisement, call gecko_cmd_le_gap_start_advertising with advertising set ID (handle) specified to start advertising the specific advertisement.

There is basically no difference compared to regular (non-mesh) BLE case. The key thing to take into account here is configuring the number of advertising sets and selecting the right advertising handle to use.

Hi,

It's very weird that you got the error because 154_rx_ci.c is not expected to be part of the Bluetooth application. I just tried creating the soc-empty project based on the part number you provided, but I didn't get any error by compiling the project. Project is attached, could you try to import and see how it works?

Thanks,

Kevin

Hi,

The difference is "if bonding is required for reading the attribute". Yes, you all understanding is correct, both needs encryption, and in your case, MITM protection is not provided. Just imagine one case where you don't bond with the device, you only pair with the device, attributes with encryption read can be read in this case, but not for bonded read.

Thanks,

Kevin

Hi,

The stack will do the transition automatically.

Thanks,

Kevin