The nRF Connect Lock Example demonstrates how to remotely control a door lock device with one basic bolt. It uses buttons to test changing the lock and device states and LEDs to show the state of these changes. You can use this example as a reference for creating your own application.
The example is based on CHIP and Nordic Semiconductor's nRF Connect SDK, and supports remote access and control of a simulated door lock over a low-power, 802.15.4 Thread network.
The example behaves as a CHIP accessory, that is a device that can be paired into an existing CHIP network and can be controlled by this network.
This example is running on the nRF Connect platform, which is based on Nordic Semiconductor‘s nRF Connect SDK and Zephyr RTOS. Visit CHIP’s nRF Connect platform overview to read more about the platform structure and dependencies.
The CHIP device that runs the lock application is controlled by the CHIP controller device over the Thread protocol. By default, the CHIP device has Thread disabled, and it should be paired with CHIP controller and get configuration from it. Some actions required before establishing full communication are described below.
The example also comes with a test mode, which allows to start Thread with the default settings by pressing button manually. However, this mode does not guarantee that the device will be able to communicate with the CHIP controller and other devices.
The example can be configured to use the secure bootloader and utilize it for performing over-the-air Device Firmware Upgrade using Bluetooth LE.
In this example, to commission the device onto a CHIP network, it must be discoverable over Bluetooth LE. For security reasons, you must start Bluetooth LE advertising manually after powering up the device by pressing Button 4.
In this example, the commissioning procedure is done over Bluetooth LE between a CHIP device and the CHIP controller, where the controller has the commissioner role.
To start the rendezvous, the controller must get the commissioning information from the CHIP device. The data payload is encoded within a QR code, printed to the UART console, and shared using an NFC tag. For security reasons, you must start NFC tag emulation manually after powering up the device by pressing Button 4.
Last part of the rendezvous procedure, the provisioning operation involves sending the Thread network credentials from the CHIP controller to the CHIP device. As a result, device is able to join the Thread network and communicate with other Thread devices in the network.
The example allows enabling the over-the-air Device Firmware Upgrade feature. In this process, the device hosting new firmware image sends the image to the CHIP device using Bluetooth LE transport and Simple Management Protocol. The MCUboot bootloader solution then replaces the old firmware image with the new one.
MCUboot is a secure bootloader used for swapping firmware images of different versions and generating proper build output files that can be used in the device firmware upgrade process.
The bootloader solution requires an area of flash memory to swap application images during the firmware upgrade. The Nordic devices use an external memory chip for this purpose. The memory chip communicates with the microcontroller through the QSPI bus.
See the Building with Device Firmware Upgrade support section to learn how to change MCUboot and flash configuration in this example.
Simple Management Protocol (SMP) is a basic transfer encoding that is used for device management purposes, including application image management. SMP supports using different transports, such as Bluetooth LE, UDP, or serial USB/UART.
In this example, the CHIP device runs the SMP Server to download the application update image using the Bluetooth LE transport.
See the Building with Device Firmware Upgrade support section to learn how to enable SMP and use it for the DFU purpose in this example.
The application requires a specific revision of the nRF Connect SDK to work correctly. See Setting up the environment for more information.
The example supports building and running on the following devices:
| Hardware platform | Build target | Platform image |
|---|---|---|
| nRF52840 DK | nrf52840dk_nrf52840 | nRF52840 DK |
| nRF5340 DK | nrf5340dk_nrf5340_cpuapp | nRF5340 DK |
This section lists the User Interface elements that you can use to control and monitor the state of the device. These correspond to PCB components on the platform image.
LED 1 shows the overall state of the device and its connectivity. The following states are possible:
Short Flash On (50 ms on/950 ms off) — The device is in the unprovisioned (unpaired) state and is waiting for a commissioning application to connect.
Rapid Even Flashing (100 ms on/100 ms off) — The device is in the unprovisioned state and a commissioning application is connected through Bluetooth LE.
Short Flash Off (950ms on/50ms off) — The device is fully provisioned, but does not yet have full Thread network or service connectivity.
Solid On — The device is fully provisioned and has full Thread network and service connectivity.
LED 2 simulates the lock bolt and shows the state of the lock. The following states are possible:
Solid On — The bolt is extended and the door is locked.
Off — The bolt is retracted and the door is unlocked.
Rapid Even Flashing (100 ms on/100 ms off during 2 s) — The simulated bolt is in motion from one position to another.
Button 1 can be used for the following purposes:
Pressed for 6 s — Initiates the factory reset of the device. Releasing the button within the 6-second window cancels the factory reset procedure. LEDs 1-4 blink in unison when the factory reset procedure is initiated.
Pressed for less than 3 s — Initiates the OTA software update process. This feature is disabled by default, but can be enabled by following the Building with Device Firmware Upgrade support instruction.
Button 2 — Pressing the button once changes the lock state to the opposite one.
Button 3 — Pressing the button once starts the Thread networking in the test mode using the default configuration.
Button 4 — Pressing the button once starts the NFC tag emulation and enables Bluetooth LE advertising for the predefined period of time.
SEGGER J-Link USB port can be used to get logs from the device or communicate with it using the command line interface.
NFC port with antenna attached can be used to start the rendezvous by providing the commissioning information from the CHIP device in a data payload that can be shared using NFC.
Before building the example, check out the CHIP repository and sync submodules using the following command:
$ git submodule update --init
The example requires a specific revision of the nRF Connect SDK. You can either install it along with the related tools directly on your system or use a Docker image that has the tools pre-installed.
If you are a macOS user, you won't be able to use the Docker container to flash the application onto a Nordic development kit due to certain limitations of Docker for macOS. Use the native shell for building instead.
To use the Docker container for setup, complete the following steps:
If you do not have the nRF Connect SDK installed yet, create a directory for it by running the following command:
$ mkdir ~/nrfconnect
Download the latest version of the nRF Connect SDK Docker image by running the following command:
$ docker pull nordicsemi/nrfconnect-chip
Start Docker with the downloaded image by running the following command, customized to your needs as described below:
$ docker run --rm -it -e RUNAS=$(id -u) -v ~/nrfconnect:/var/ncs -v ~/connectedhomeip:/var/chip \
-v /dev/bus/usb:/dev/bus/usb --device-cgroup-rule "c 189:* rmw" nordicsemi/nrfconnect-chip
In this command:
Update the nRF Connect SDK to the most recent supported revision, by running the following command:
$ cd /var/chip $ python3 scripts/setup/nrfconnect/update_ncs.py --update
Now you can proceed with the Building instruction.
To use the native shell for setup, complete the following steps:
Download and install the following additional software:
If you do not have the nRF Connect SDK installed, follow the guide in the nRF Connect SDK documentation to install the latest stable nRF Connect SDK version. Since command-line tools will be used for building the example, installing SEGGER Embedded Studio is not required.
If you have the SDK already installed, continue to the next step and update the nRF Connect SDK after initializing environment variables.
Initialize environment variables referred to by the CHIP and the nRF Connect SDK build scripts. Replace nrfconnect-dir with the path to your nRF Connect SDK installation directory, and toolchain-dir with the path to GNU Arm Embedded Toolchain.
$ source nrfconnect-dir/zephyr/zephyr-env.sh $ export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb $ export GNUARMEMB_TOOLCHAIN_PATH=toolchain-dir
Update the nRF Connect SDK to the most recent supported revision by running the following command (replace chip-dir with the path to CHIP repository directory):
$ cd chip-dir $ python3 scripts/setup/nrfconnect/update_ncs.py --update
Now you can proceed with the Building instruction.
Complete the following steps, regardless of the method used for setting up the environment:
Navigate to the example's directory:
$ cd examples/lock-app/nrfconnect
Run the following command to build the example, with build-target replaced with the build target name of the Nordic Semiconductor's kit you own, for example nrf52840dk_nrf52840:
$ west build -b build-target
You only need to specify the build target on the first build. See Requirements for the build target names of compatible kits.
The output zephyr.hex file will be available in the build/zephyr/ directory.
If you're planning to build the example for a different kit or make changes to the configuration, remove all build artifacts before building. To do so, use the following command:
$ rm -r build
To build the example with release configuration that disables the diagnostic features like logs and command-line interface, run the following command:
$ west build -b build-target -- -DOVERLAY_CONFIG=third_party/connectedhomeip/config/nrfconnect/app/release.conf
Remember to replace build-target with the build target name of the Nordic Semiconductor's kit you own.
To build the example with configuration that enables DFU, run the following command with build-target replaced with the build target name of the Nordic Semiconductor's kit you own (for example nrf52840dk_nrf52840):
WARNING: Please do remember about replacing build-target also in the PM_STATIC_YML_FILE path.
$ west build -b build-target -- -DOVERLAY_CONFIG=third_party/connectedhomeip/config/nrfconnect/app/overlay-dfu_support.conf -DPM_STATIC_YML_FILE="configuration/build-target/pm_static.yml"
To change the default MCUboot configuration, edit the overlay-dfu_support.conf overlay file that contains bootloader configuration options. The file is located in the config/nrfconnect/app directory. You can also define the desired options in your example's prj.conf file.
Make sure to apply the same configuration changes in the child_image/mcuboot.conf file. This is necessary for the configuration to work, as the bootloader image is a separate application from the user application and it has its own configuration file. The contents of this file must be consistent with the application configuration.
In the default configuration, the MCUboot uses the Partition Manager to configure flash partitions used for the bootloader application image slot purposes. You can change these settings by defining static partitions. This example uses this option to define using an external flash.
To modify the flash settings of your board (that is, your build-target, for example nrf52840dk_nrf52840), edit the pm_static.yml file located in the configuration/build-target/ directory.
The Zephyr ecosystem is based on Kconfig files and the settings can be modified using the menuconfig utility.
To open the menuconfig utility, run the following command from the example directory:
$ west build -b build-target -t menuconfig
Remember to replace build-target with the build target name of the Nordic Semiconductor's kit you own.
Changes done with menuconfig will be lost if the build directory is deleted. To make them persistent, save the configuration options in the prj.conf file. For more information, see the Configuring nRF Connect SDK examples page.
To flash the application to the device, use the west tool and run the following command from the example directory:
$ west flash --erase
If you have multiple development kits connected, west will prompt you to pick the correct one.
To debug the application on target, run the following command from the example directory:
$ west debug
Check the CLI tutorial to learn how to use command-line interface of the application.
Read the Android commissioning guide to see how to use CHIPTool for Android smartphones to commission and control the application within a CHIP-enabled Thread network.
Read the DFU tutorial to see how to upgrade your device firmware.