LE Mesh Embedded Provisioner demo application

Overview

This demo application shows an implementation of a self-organized LE mesh network. One of the devices shall become an embedded provisioner. The device which becomes an embedded provisioner searches for the unprovisioned devices and adds them to the network. A network may only have a single embedded provisioner. To build the application, the following flags shall be set to 1 in the makefile or on the make command line:

SELF_CONFIG?=1
EMBEDDED_PROVISION?=1

The sample application waits for the button push (interrupt) as an indication that it needs to assume the embedded provisioner role. When it assumes the role of embedded provisioner it creates a network, provisions the local device into the network and reboots. The next time the app starts up, it is already provisioned and serves as the provisioner to the network. When a new unprovisioned device is found, the embedded provisioner checks if the device matches required criteria, for example, some pattern in the UUID, and if it matches, provisions and configures the device to the network.

A device which is not set to be an embedded provisioner acts as a normal LE Mesh network device. In addition to that it supports a vendor specific model which allows quicker configuration. If a provisioner sends the vendor specific command to perform a self config, the device binds all existing models to an existing app key. And subscribes all the models to a hardcoded group address (0xC000).

The app uses the Remote Provisioning Service feature to add devices to the network. On startup the app goes through all network devices and tells them to scan for unprovisioned devices. When a new device is found, the app starts a guard timeout to allow other provisioners to report the same device and when the timeout expires, the app selects the best provisioner and performs provisioning using that remote provisioning server.

To decide if an unprovisioned device needs to be added to the network, the app can either use RSSI or can use a magic number in the UUID. See the mesh_provsioner_validate_unprovision_device() function in the mesh_scanner.c file. It is expected for a production app to update this function to use a pre-programmed list of UUIDs and some OOB data.

After the new device is provisioned, the app performs configuration. To do that the app adds an application key, binds the vendor specific model to this application key ,and then sends the command to self-configure. The configuration values are hard-coded in the embedded_provisioner.h file. This application also support the DFU feature. An MCU can download an image to the embedded provisioner over the "WICED HCI" UART and tell the app to perform download to all other devices in the network. The app uses the DFU procedure to perform the download. At the end of the DFU the receivers verify the image using an ECDSA procedure. To support this functionality each application shall include ecdsa256_pub.c. The project directory also contains the private key ecdsa256_key.pri.bin that was used to generate the public key. That pair needs to be replaced for production. See tools/ecdsa directory for more information.

For Mesh topology information, see this link For Mesh protocol details, see this link For Mesh application structure, see this link

Features demonstrated

Auto-provisioning and configuration of unprovisioned devices
Vendor Specific self-configuration
DFU

Instructions

To demonstrate the app, work through the following steps:

Build and download the application to several AIROC™ Kits.
Push and release a button on one of the kits to set it up as an embedded provisioner.
For 20721B2 based AIROC™ kits with the audio shield equipped, use the Custom button on audio shield board as application button rather than the button on the base board.

Note: The CYW920721M2EVK-01 kit includes the audio shield, but does not connect buttons or LEDs. To use the Embedded Provisioner or Dimmer Self Config apps with this kit, remove the audio shield, and flywire J3.6 (D12) to J11.3 (LED2) and J4.1 (D7) to J12.1 (USER button). See makefile AUDIO_SHIELD_REMOVED flag.

Notes

The board will factory reset if you press and hold the user button (SW3) on the board for more than 15 seconds.
All mesh apps use a common shared source library for common application framework functionality located at: mtb_shared\wiced_btsdk\dev-kit\libraries\btsdk-mesh\COMPONENT_mesh_app_lib. This library may be edited as needed. For example, to change the PUART baud rate see mesh_app_hci_init() function in mesh_app_hci.c. The default PUART baud rate is set in that location to 921600.
The application GATT database is located in mesh_app_lib as well, in file mesh_app_gatt.c. If you create a GATT database using Bluetooth® Configurator, update the GATT database in the location mentioned above.
For 20835B1 based AIROC™ kits, Mesh debug trace flags (MESH_MODELS_DEBUG_TRACES, MESH_CORE_DEBUG_TRACES, and MESH_PROVISIONER_DEBUG_TRACES) shall all be set to 0 in the makefile or on the make command line.

BTSTACK version

BTSDK AIROC™ chips contain the embedded AIROC™ Bluetooth® stack, BTSTACK. Different chips use different versions of BTSTACK, so some assets may contain variant sets of files targeting the different versions in COMPONENT_btstack_vX (where X is the stack version). Applications automatically include the appropriate folder using the COMPONENTS make variable mechanism, and all BSPs declare which stack version should be used in the BSP .mk file, with a declaration such as:

COMPONENTS+=btstack_v1
or:
COMPONENTS+=btstack_v3

Common application settings

Application settings below are common for all BTSDK applications and can be configured via the makefile of the application or passed in via the command line.

BT_DEVICE_ADDRESS

Set the BDA (Bluetooth® Device Address) for your device. The address is 6 bytes, for example, 20819A10FFEE. By default, the SDK will set a BDA for your device by combining the 7 hex digit device ID with the last 5 hex digits of the host PC MAC address.

UART

Set to the UART port you want to use to download the application. For example 'COM6' on Windows or '/dev/ttyWICED_HCI_UART0' on Linux or '/dev/tty.usbserial-000154' on macOS. By default, the SDK will auto-detect the port.

ENABLE_DEBUG

For HW debugging, configure ENABLE_DEBUG=1. See the document AIROC™-Hardware-Debugging for more information. This setting configures GPIO for SWD.

CYW920819EVB-02/CYW920820EVB-02: SWD signals are shared with D4 and D5, see SW9 in schematics.
CYBT-213043-MESH/CYBT-213043-EVAL/CYBT-253059-EVAL: SWD signals are routed to P12=SWDCK and P13=SWDIO. Use expansion connectors to connect VDD, GND, SWDCK, and SWDIO to your SWD Debugger probe.
CYBT-223058-EVAL/CYW920835M2EVB-01/CYBT-243053-EVAL/CYBLE-343072-EVAL-M2B/CYBLE-333074-EVAL-M2B/CYBLE-343072-MESH: SWD signals are routed to P02=SWDCK and P03=SWDIO. Use expansion connectors to connect VDD, GND, SWDCK, and SWDIO to your SWD Debugger probe.
CYBT-263065-EVAL/CYBT-273063-EVAL: SWD signals are routed to P02=SWDCK and P04=SWDIO. Use expansion connectors to connect VDD, GND, SWDCK, and SWDIO to your SWD Debugger probe.
CYBT-343026-EVAL/CYBT-353027-EVAL/CYBT-333047-EVAL: SWD signals are routed to P11=SWDCK and P15=SWDIO. Use expansion connectors to connect VDD, GND, SWDCK, and SWDIO to your SWD Debugger probe.
CYBT-413055-EVAL/CYBT-413061-EVAL: SWD signals are routed to P16=SWDCK and P17=SWDIO. Use expansion connectors to connect VDD, GND, SWDCK, and SWDIO to your SWD Debugger probe.
CYW989820EVB-01: SWDCK (P02) is routed to the J13 DEBUG connector, but not SWDIO. Add a wire from J10 pin 3 (PUART CTS) to J13 pin 2 to connect GPIO P10 to SWDIO.
CYW920719B2Q40EVB-01: PUART RX/TX signals are shared with SWDCK and SWDIO. Remove RX and TX jumpers on J10 when using SWD. PUART and SWD cannot be used simultaneously on this board unless these pins are changed from the default configuration.
CYW920721M2EVK-02/CYW920721M2EVB-03: The default setup uses P03 for SWDIO and P05 for SWDCK. Check the position of SW15 if using JLink with the DEBUG connector.
CYW920706WCDEVAL: SWD debugging requires fly-wire connections. The default setup P15 (J22 pin 3 or J24 pin 1) for SWDIO and P11 (J23 pin 5 or J22 pin 4) for SWDCK.
CYW920736M2EVB-01: SWD hardware debugging requires fly-wire connections. The only option is using P14 for SWDCK and P15 for SWDIO. These route to Arduino header J2, A1 and A0. These can be fly-wired to Arduino header J4, D4 and D5. From there the signals connect to the KitProg3 SWD bridge. In addition, the debug macros (SETUP_APP_FOR_DEBUG_IF_DEBUG_ENABLED and BUSY_WAIT_TILL_MANUAL_CONTINUE_IF_DEBUG_ENABLED) are placed in sparinit.c in code common to all applications for this device. Most applications for this device call bleprofile_GPIOInit() in subsequent code, overwriting the SWD pin configuration. To use hardware debugging after the call to bleprofile_GPIOInit(), place the debug macros in code after that call.
CYW943012B2EVK-01: SWD signals are shared with D4 and D5.
CYW920820M2EVB-01 & CYW920819M2EVB-01: The default setup uses P03 for SWDIO and P02 for SWDCK. Check the position of SW15 if using JLink with the DEBUG connector.
CYW989820M2EVB-01: SWD hardware debugging requires a fly-wire connection to use P14 for SWDIO. P2 is connected directly to SWDCK / ARD_D4. Fly-wire P14 / ARD_D8 on J3.10 to J4.3 / ARD_D5 to connect SWDIO.
SWD hardware debugging is not supported on the following:

CYW920721M2EVK-01

CYW920835REF-RCU-01

CYW9M2BASE-43012BT

CYBT-423054-EVAL

CYBT-423060-EVAL

CYBT-483056-EVAL

CYBT-483062-EVAL

CYW955572BTEVK-01

Building code examples

Using the ModusToolbox™ Eclipse IDE

Install ModusToolbox™ 2.2 (or higher).
In the ModusToolbox™ Eclipse IDE, click the New Application link in the Quick Panel (or, use File > New > ModusToolbox IDE Application).
Pick your board for BTSDK under AIROC™ Bluetooth® BSPs.
Select the application in the IDE.
In the Quick Panel, select Build to build the application.
To program the board (download the application), select Program in the Launches section of the Quick Panel.

Using command line

Install ModusToolbox™ 2.2 (or higher).
On Windows, use Cygwin from \ModusToolbox\tools_2.x\modus-shell\Cygwin.bat to build apps.
Use the tool 'project-creator-cli' under \ModusToolbox\tools_2.x\project-creator\ to create your application.

project-creator-cli --board-id (BSP) --app-id (appid) -d (dir)
See 'project-creator-cli --help' for useful options to list all available BSPs, and all available apps per BSP.
For example:
project-creator-cli --app-id mtb-example-btsdk-empty --board-id CYW920706WCDEVAL -d .
To build the app call make build. For example:

cd mtb-examples-btsdk-empty
make build
To program (download to) the board, call:

make qprogram
To build and program (download to) the board, call:

make program

Note: make program = make build + make qprogram

Downloading an application to a board

If you have issues downloading to the board, follow the steps below:

Press and hold the 'Recover' button on the board.
Press and hold the 'Reset' button on the board.
Release the 'Reset' button.
After one second, release the 'Recover' button.

Note: this is only applicable to boards that download application images to FLASH storage. Boards that only support RAM download (DIRECT_LOAD) such as CYW9M2BASE-43012BT can be power cycled to boot from ROM.

Over The Air (OTA) Firmware Upgrade

Applications that support OTA upgrade can be updated via the peer OTA app in:

<Workspace Dir>\mtb_shared\wiced_btsdk\tools\btsdk-peer-apps-ota

See the readme.txt file located in the above folder for instructions.
To generate the OTA image for the app, configure OTA_FW_UPGRADE=1 in the app makefile, or append OTA_FW_UPGRADE=1 to a build command line, for example:

make PLATFORM=CYW920706WCDEVAL OTA_FW_UPGRADE=1 build

This will the generate <app>.bin file in the 'build' folder.

SDK software features

Dual-mode Bluetooth® stack included in the ROM (BR/EDR and LE)
Bluetooth® stack and profile level APIs for embedded Bluetooth® application development
AIROC™ HCI protocol to simplify host/MCU application development
APIs and drivers to access on-board peripherals
Bluetooth® protocols include GAP, GATT, SMP, RFCOMM, SDP, AVDT/AVCT, LE Mesh
LE and BR/EDR profile APIs, libraries, and sample apps
Support for Over-The-Air (OTA) upgrade
Device Configurator for creating custom pin mapping
Bluetooth® Configurator for creating LE GATT Database
Peer apps based on Android, iOS, Windows, etc. for testing and reference
Utilities for protocol tracing, manufacturing testing, etc.
Documentation for APIs, datasheets, profiles, and features
BR/EDR profiles: A2DP, AVRCP, HFP, HSP, HID, SPP, MAP, PBAP, OPP
LE profiles: Mesh profiles, HOGP, ANP, BAP, HRP, FMP, IAS, ESP, LE COC
Apple support: Apple Media Service (AMS), Apple Notification Center Service (ANCS), iBeacon, Homekit, iAP2
Google support: Google Fast Pair Service (GFPS), Eddystone
Amazon support: Alexa Mobile Accessories (AMA)

Note: this is a list of all features and profiles supported in BTSDK, but some AIROC™ devices may only support a subset of this list.

List of boards available for use with BTSDK

Folder structure

All BTSDK code examples need the 'mtb_shared\wiced_btsdk' folder to build and test the apps. 'wiced_btsdk' includes the 'dev-kit' and 'tools' folders. The contents of the 'wiced_btsdk' folder will be automatically populated incrementally as needed by the application being used.

dev-kit

This folder contains the files that are needed to build the embedded Bluetooth® apps.

baselib: Files for chips supported by BTSDK. For example CYW20819, CYW20719, CYW20706, etc.
bsp: Files for BSPs (platforms) supported by BTSDK. For example CYW920819EVB-02, CYW920706WCDEVAL etc.
btsdk-include: Common header files needed by all apps and libraries.
btsdk-tools: Build tools needed by BTSDK.
libraries: Profile libraries used by BTSDK apps such as audio, LE, HID, etc.

tools

This folder contains tools and utilities need to test the embedded Bluetooth® apps.

btsdk-host-apps-bt-ble: Host apps (Client Control) for LE and BR/EDR embedded apps, demonstrates the use of AIROC™ HCI protocol to control embedded apps.
btsdk-host-peer-apps-mesh: Host apps (Client Control) and Peer apps for embedded Mesh apps, demonstrates the use of AIROC™ HCI protocol to control embedded apps, and configuration and provisioning from peer devices.
btsdk-peer-apps-ble: Peer apps for embedded LE apps.
btsdk-peer-apps-ota: Peer apps for embedded apps that support Over The Air Firmware Upgrade.
btsdk-utils: Utilities used in BTSDK such as BTSpy, wmbt, and ecdsa256.

See README.md in the sub-folders for more information.

Software Tools

The following tool applications are installed on your computer either with ModusToolbox™, or by creating an application in the workspace that can use the tool.

BTSpy:

BTSpy is a trace viewer utility that can be used with AIROC™ Bluetooth® platforms to view protocol and application trace messages from the embedded device. The utility is located in the folder below. For more information, see readme.txt in the same folder.
This utility can be run directly from the filesystem, or it can be run from the Tools section of the ModusToolbox™ QuickPanel, or by right-clicking a project in the Project Explorer pane and selecting the ModusToolbox™ context menu.
It is supported on Windows, Linux and macOS.
Location: <Workspace Dir>\wiced_btsdk\tools\btsdk-utils\BTSpy

Bluetooth® Classic and LE Profile Client Control:

This application emulates host MCU applications for LE and BR/EDR profiles. It demonstrates AIROC™ Bluetooth® APIs. The application communicates with embedded apps over the "WICED HCI UART" interface. The application is located in the folder below. For more information, see readme.txt in the same folder.
This utility can be run directly from the filesystem, or it can be run from the Tools section of the ModusToolbox™ QuickPanel, or by right-clicking a project in the Project Explorer pane and selecting the ModusToolbox™ context menu.
It is supported on Windows, Linux, and macOS.
Location: <Workspace Dir>\wiced_btsdk\tools\btsdk-host-apps-bt-ble\client_control

LE Mesh Client Control:

Similar to the above app, this application emulates host MCU applications for LE Mesh models. It can configure and provision mesh devices and create mesh networks. The application is located in the folder below. For more information, see readme.txt in the same folder.
This utility can be run directly from the filesystem, or it can be run from the Tools section of the ModusToolbox™ QuickPanel (if a mesh-capable project is selected in the Project Explorer pane), or by right-clicking a mesh-capable project in the Project Explorer pane and selecting the ModusToolbox™ context menu.
The full version is provided for Windows (VS_ClientControl) supporting all Mesh models.
A limited version supporting only the Lighting model (QT_ClientControl) is provided for Windows, Linux, and macOS.
Location: <Workspace Dir>\wiced_btsdk\tools\btsdk-host-peer-apps-mesh\host

Peer apps:

Applications that run on Windows, iOS or Android and act as peer Bluetooth® apps to demonstrate specific profiles or features, communicating with embedded apps over the air.
LE apps location: <Workspace Dir>\wiced_btsdk\tools\btsdk-peer-apps-ble
LE Mesh apps location: <Workspace Dir>\wiced_btsdk\tools\btsdk-host-peer-apps-mesh\peer
OTA apps location: <Workspace Dir>\wiced_btsdk\tools\btsdk-peer-apps-ota

Device Configurator:

Use this GUI tool to create source code for a custom pin mapping for your device. Run this tool from the Tools section of the ModusToolbox™ QuickPanel, or by right-clicking a project in the Project Explorer pane and selecting the ModusToolbox™ context menu.
It is supported on Windows, Linux and macOS.
Note: The pin mapping is based on wiced_platform.h for your board.
Location: <Install Dir>\tools_2.x\device-configurator

Bluetooth® Configurator:

Use this GUI tool to create and configure the LE GATT Database and the BR/EDR SDP Database, generated as source code for your application.
Run this tool from the Tools section of the ModusToolbox™ QuickPanel, or by right-clicking a project in the Project Explorer pane and selecting the ModusToolbox™ context menu.
It is supported on Windows, Linux and macOS.
Location: <Install Dir>\tools_2.x\bt-configurator

Tracing

To view application traces, there are 2 methods available. Note that the application needs to configure the tracing options.

"WICED Peripheral UART" - Open this port on your computer using a serial port utility such as TeraTerm or PuTTY (usually using 115200 baud rate for non-Mesh apps, and 921600 for Mesh apps).
"WICED HCI UART" - Open this port on your computer using the Client Control application mentioned above (usually using 3M baud rate). Then run the BTSpy utility mentioned above.

Using BSPs (platforms)

BTSDK BSPs are located in the \mtb_shared\wiced_btsdk\dev-kit\bsp\ folder by default.

a. Selecting an alternative BSP

The application makefile has a default BSP. See "TARGET". The makefile also has a list of other BSPs supported by the application. See "SUPPORTED_TARGETS". To select an alternative BSP, use Library Manager from the Quick Panel to deselect the current BSP and select an alternate BSP. Then right-click the newly selected BSP and choose 'Set Active'. This will automatically update TARGET in the application makefile.

b. Custom BSP

Complete BSP

To create and use a complete custom BSP that you want to use in applications, perform the following steps:

Select an existing BSP created through ModusToolbox™ Project Creator that you wish to use as a template.
Make a copy in the same folder and rename it. For example mtb_shared\wiced_btsdk\dev-kit\bsp\TARGET_mybsp.
Note: This can be done in the system File Explorer and then refresh the workspace in ModusToolbox™ to see the new project. Delete the .git sub-folder from the newly copied folder before refreshing in Eclipse. If done in the IDE, an error dialog may appear complaining about items in the .git folder being out of sync. This can be resolved by deleting the .git sub-folder in the newly copied folder.
In the new mtb_shared\wiced_btsdk\dev-kit\bsp\TARGET_mybsp\release-vX.X.X\ folder, rename the existing/original (BSP).mk file to mybsp.mk.
In the application makefile, set TARGET=mybsp and add it to SUPPORTED_TARGETS.
In the application libs folder, edit the mtb.mk file and replace all instances of the template BSP name string with 'mybsp'.
Update design.modus for your custom BSP if needed using the Device Configurator link under Configurators in the Quick Panel.
Update the application makefile as needed for other custom BSP specific attributes and build the application.

Custom Pin Configuration Only - Multiple Apps

To create a custom pin configuration to be used by multiple applications using an existing BSP that supports Device Configurator, perform the following steps:

Create a folder COMPONENT_(CUSTOM)_design_modus in the existing BSP folder. For example mtb_shared\wiced_btsdk\dev-kit\bsp\TARGET_CYW920819EVB-02\release-vX.X.X\COMPONENT_my_design_modus
Copy the file design.modus from the reference BSP COMPONENT_bsp_design_modus folder under mtb_shared\wiced_btsdk\dev-kit\bsp\ and place the file in the newly created COMPONENT_(CUSTOM)_design_modus folder.
In the application makefile, add the following two lines
DISABLE_COMPONENTS+=bsp_design_modus
COMPONENTS+=(CUSTOM)_design_modus
(for example COMPONENTS+=my_design_modus)
Update design.modus for your custom pin configuration if needed using the Device Configurator link under Configurators in the Quick Panel.
Building of the application will generate pin configuration source code under a GeneratedSource folder in the new COMPONENT_(CUSTOM)_design_modus folder.

Custom Pin Configuration Only - Per App

To create a custom configuration to be used by a single application from an existing BSP that supports Device Configurator, perform the following steps:

Create a folder COMPONENT_(BSP)_design_modus in your application. For example COMPONENT_CYW920721M2EVK-02_design_modus
Copy the file design.modus from the reference BSP under mtb_shared\wiced_btsdk\dev-kit\bsp\ and place the file in this folder.
In the application makefile, add the following two lines
DISABLE_COMPONENTS+=bsp_design_modus
COMPONENTS+=(BSP)_design_modus
(for example COMPONENTS+=CYW920721M2EVK-02_design_modus)
Update design.modus for your custom pin configuration if needed using the Device Configurator link under Configurators in the Quick Panel.
Building of the application will generate pin configuration source code under the GeneratedSource folder in your application.

Using libraries

The libraries needed by the app can be found in in the mtb_shared\wiced_btsdk\dev-kit\libraries folder. To add an additional library to your application, launch the Library Manager from the Quick Panel to add a library. Then update the makefile variable "COMPONENTS" of your application to include the library. For example:
COMPONENTS += fw_upgrade_lib

Documentation

BTSDK API documentation is available online

Note: For offline viewing, git clone the documentation repo

BTSDK Technical Brief and Release Notes are available online

License

Infineon/mtb-example-btsdk-mesh-demo-embedded-provisioner

About

Resources

License

Stars

Watchers

Forks

Releases

Packages 0

Languages

Packages