Sidewalk end device¶
This sample demonstrates how to implement an end device for the Sidewalk End Device application. It supports Bluetooth® LE, LoRa, and FSK link modes. It also uses external Quad Serial Peripheral Interface (QSPI) Flash for firmware updates.
Requirements¶
This sample supports the following development kits:
Hardware platforms |
PCA |
Board name |
Build target |
---|---|---|---|
nRF52840 DK |
PCA10056 |
|
|
nRF5340 DK |
PCA10095 |
|
|
Thingy53 |
PCA20053 |
|
|
nRF54L15 PDK * |
PCA10156 |
|
* The nRF54L15 PDK does not support LoRa and FSK configurations.
To run the sample in the Bluetooth LE link mode, you only need the development kit. However, if you want to run the sample with LoRa or FSK configuration, you also need the LoRa radio module. The supported modules are as follows:
Radio chip |
Board name |
Interface |
---|---|---|
SX126xMB2xAS |
SPI @ 8Mhz |
Note
To use sub-GHz radio, the Semtech shield must be connected to the development kit header, and the antenna must be connected to the radio module. For the exact pin assignment, refer to the Pinout section.
Overview¶
The purpose of the Sidewalk end device sample is to use it as a starting point when implementing a Sidewalk device. The sample demonstrates a simple Sidewalk application that allows you to send and receive messages, as well as update firmware. It also has a few variants you can choose from depending on your application needs.
Source file setup¶
The application consists of two source files:
main.c
– The main source file. Starts Sidewalk application.sidewalk.c
(sidewalk.h
) – Sidewalk thread file. It is a common source file for all sample configurations. It implements a separate thread that calls the Sidewalk API. The file also includes support for the device firmware update (DFU). The following diagram shows the behavior of the state machine:
Additionally, it has a variant-specific file:
app.c
(app.h
) – Implements application logic. It communicates to the Sidewalk thread using events defined in thesidewalk.h
file, and receives Sidewalk callbacks defined in thesid_api.h
file. An application may consist of multipleapp_*
files that are used to define user interface and realize application logic.
Configuration overview¶
When running the sample, you can use different configuration files depending on the supported features.
Configuration files¶
Configuration files are provided for different build types and are located in the application’s root directory. Build types are covered by dedicated files with the respective build type added to the file name. The same naming convention is followed if a board has other configuration files that are, for example, associated with a partition layout or child image configuration.
Before you start testing the application, you can select one of the build types supported by the sample. The sample supports the following build types:
Build type |
File name |
Supported board |
Description |
---|---|---|---|
Debug (default) |
|
All from Requirements |
Debug version of the application. It can be used to enable additional features for verifying the application behavior, such as logs or command-line shell. |
Release |
|
All from Requirements |
Release version of the application. It can be used to enable only the necessary application functionalities to optimize its performance. |
You can build the release
firmware for build_target
by running the following command in the project directory:
$ west build -b build_target -- -DCONF_FILE=prj_release.conf
For example:
$ west build -b nrf52840dk_nrf52840 -- -DCONF_FILE=prj_release.conf
Note
Selecting a build type is optional.
However, if the build type is not selected, the debug
build type is used by default.
Selecting a sample variant¶
You can choose a sample variant depending on your needs. Testing application scenarios differ depending on the selected Sidewalk configuration:
overlay-hello
– The default configuration. Use it to run the Hello Sidewalk variant.overlay-demo
– Use this configuration to run the Sensor monitoring variant.overlay-dut
– Use this configuration to run the Device under test (DUT) variant. The overlay enables CLI and disables sample automation.
You can build an end device application with the selected overlay by running the following command in the project directory:
$ west build -b build_target -- -DOVERLAY_CONFIG="overlay-name.conf"
For example, to build the Sidewalk DUT configuration overlay, run the following command:
$ west build -b nrf52840dk_nrf52840 -- -DOVERLAY_CONFIG="overlay-dut.conf"
See the details on running and testing individual variants, as well as enabling available Kconfig options: