Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.

Exercise 2 – DFU over USB, adding external flash & custom keys

v2.8.x – v2.7.0

This exercise is not yet supported in nRF Connect SDK v2.7.0 or v2.8.0. The support is ongoing.

Apologies for any inconvenience.

v2.6.2 -v2.5.2

In this exercise, we will modify the previous exercise (DFU over UART) to use DFU over USB instead.

Important

This exercise is only supported on nRF5340 DK, nRF52840 DK, nRF52833 DK, and nRF7002 DK since it requires an nRF SoC with a USB peripheral. For a list of which SoCs contain a USB peripheral, check the Nordic product guide.

We will use the Zephyr CDC ACM drivers to communicate over USB. For more information on this, you can see USB device support.

Exercise steps

1. Open the code base of the exercise by navigating to Create a new application in the nRF Connect for VS Code extension, select Copy a sample, and search for Lesson 8 – Exercise 2. Exercise 2 base code is the Exercise 1 solution with comments renamed.

2. Enable CDC ACM for Serial Recovery.

To enable CDC ACM for Serial Recovery, add CONFIG_BOOT_SERIAL_CDC_ACM to child_image/mcuboot.conf.

3. Increase the partition for the MCUboot bootloader.

The partition for the MCUboot bootloader is not large enough for MCUboot with CDC ACM and USB drivers. This size is 0xC000 by default. To increase this, set CONFIG_PM_PARTITION_SIZE_MCUBOOT to 0x10000 in child_image/mcuboot.conf. Or It is possible to make MCUboot take less space. See for example this samples child_image/mcuboot/prj_release.conf.

Important

For the nRF7002 DK set CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x20000 . For the nRF5340 DK set CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x15000 . Otherwise, you will get a linker error.

4. Configure the application to use CDC ACM for DFU.

Next , we will change the application to use CDC ACM for DFU. The configuration we use here is inspired by the SMP Server sample.

4.1 As you can see. We have an app.overlay file in the application directory. This is one way to set devicetree overlays, but you can use other ways to do the same. In this app.overlay, we will first configure CDC ACM by adding the following:

4.2 Then we point the uart-mcumgr driver to CDC ACM . by adding the line zephyr,uart-mcumgr = &cdc_acm_uart0; as chosen.

4.3 Next, we will have to add Kconfig options to prj.conf:

4.4 Lastly, USB must be enabled in our source files (main.c). First, include the header file for USB

4.5 Enable USB

Testing

5. Build and flash the application to your board.

6. Connect your computer to the nRF USB port on the DK.

In this step, we will assume that the hardware has no Debugger/Interface MCU (IMCU) and we use the nRF USB port as the transport for the firmware images.

Disconnect your board from the regular Debugger USB port and connect to The nRF USB port. The nRF USB port is only available on the nRF5340 DK, nRF52840 DK, nRF52833 DK, and nRF7002 DK since it requires an nRF SoC with a USB peripheral. For a list of which SoCs contain a USB peripheral, check the Nordic product guide.

7. DFU over USB

7.1 Now, hold button 2 while resetting the Development Kit. Instead of starting normally, the kit will now enter Serial Recovery mode over the nRF USB port. You can see this from LED2, which should be on.

7.2 We can use mcumgr-cli to communicate with the DK. First, we will add a configuration to mcumgr-cli:

“testDK” here can be named whatever we want. COM22 should be changed to whatever port the DKs nRF USB is connected to. Please note that the COM port for nRF USB will not be listed in nRF Connect for VS Code. Use Device Manager in Windows or equivalent on Linux/macOS to find the port allocated to nRF USB. A list of supported mcumgr-cli commands can be found here.

7.3 Check the listing of current images on the DK:

This should return the slots available, as we have seen in the previous exercise.

7.4 Before we try to upload a new firmware image to the DK, we should change something in the code, so we can verify the change. This can, for example, be to change the delay in the blinky code. Then rebuild the code.

7.5 Now we can upload the new image firmware to the DK, using:

Then this should be the result. The upload is done in a separate thread in the background. So the current firmware should be running as normal.

7.6 Since we use a dual slot configuration, the uploaded application does not automatically run. To make the application swap into the primary slot, we must tag it with either “test” or “confirm”. Let’s do “test” first. First, we need to get the hash of the image:

Will return

Then we use the <HASH> to tag that slot as test, and reset:

The new image will be swapped into the primary slot and the old image to the secondary slot. We can check this with:

Which should return:

If we reset the board again, we can, in the same way, see that the image swaps back to the old firmware. This is because we passed test not confirm to mcumgr.

Adding External Flash

8. To increase the flash available for the application, we can add an external flash.

The MCUboot secondary partition can then be placed in the external flash, increasing the available space for the application.

Note

There is an MCUboot with external flash test in the nRF Connect SDK, which can be used as a reference.

The QSPI on the nRF7002 DK is used to connect the host MCU (nRF5340 SoC) to the Wi-Fi Companion IC (nRF7002 IC). Therefore, SPI is used to interface with the external memory, and special configurations are needed that are outlined here: https://github.com/nrfconnect/sdk-nrf/tree/main/samples/net/aws_iot/child_image/mcuboot/boards.

8.1 We can tell the partition manager that we are using an external flash. See External flash memory partitions. Then MCUboot will automatically be partitioned to use external flash for the mcuboot_seconary partition. To do this, set the chosen nordic,pm-ext-flash = &mx25r64; in both app.overlay and child_image/mcuboot.overlay:

8.2 The QSPI drivers needed for external flash on our development kits are not always automatically added to the MCUboot child image. We will add these to child_image/mcuboot.conf:

8.3 We also need to increase the number of sectors used by MCUboot now, as the partitions are larger:

8.4 Connect your computer to the DK debug port again (not nRF USB), and build and flash the new firmware.

8.5 To verify that the partitions have moved, use the Memory Report:

9. Disconnect from the debug port and connect to nRF USB port, you can retest the DFU over USB with External Flash by redoing steps 7.2 – 7.5.

nRF5340 update

The application core of the nRF5340 can be updated, as explained above.

When doing DFU from the application, no extra configurations are needed to update the network core. Another DFU package file must be used for the network core. Instead of app_update.bin, use net_core_app_update.bin.

However, for Serial Recovery, some extra configurations are needed to update the network core. The needed configurations are listed in our docs on Developing with nRF5340 DK: MCUboot’s serial recovery of the networking core image.

Custom key

The more observant readers might have noticed the following warning from the build logs so far:

When building for MCUboot, a default key is used to ease development. For production, it is extremely important to use your own key instead. If not, anyone could update your device with their code.

9.1 To set our own key, we first need to generate a key. We will use imgtool for this:

9.2 To configure our project to use this key, follow docs at MCUboot adding custom signature key file. We can do this in two different ways. Either we can set this key in child_image/mcuboot.conf.

As you can see, this uses the full path to the project, which is a limitation.
9.3 It is possible to use CMakeLists.txt to set the path relative to the project folder. This is more powerful but also more complex. To do this, set the following in CMakeLists.txt:

Here, you can use CMake variables and pathing to choose any folder, as seen relative to your project.
It is up to you if you want to use 9.2 or 9.3 in your project. I suggest that you try both and find out which you like the best.
These steps will not be included in the solution, as they require a generated key.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.