DFU process in Nrf connect SDK for Nrf52840

RE: DFU process in Nrf connect SDK for Nrf52840

Marte Myrvold — Tue, 15 Aug 2023 13:31:10 GMT

Hi,

[quote user="Sarvesh"]

As I will get the start and end address from these about two, can I use the APIs from following for writing the image data in flash on given address ?

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/dfu/dfu_multi_image.html

[/quote]

This API is for multi image DFU, so if your application consists of several separate images you can use it. For single image, you can use zcbor directly without the added DFU multi-image API on top.

[quote user="Sarvesh"]And how do I do this, it would be great if you can help me with these[/quote]

You can send a SMP confirmed command similar to how it is done in send_smp_confirm() here: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/blob/main/bootloader_samples/client_smp/smp_client_ble/src/main.c#L993.

You can also use the Device Firmware Upgrade API, which might be simpler if you want to handle it locally on the device. When you have written the DFU image to the device you will have two images, one primary image in slot 0 and one secondary image in slot 1. The primary is the current running application, and the secondary is the new DFU image. With boot_request_upgrade() you can mark the image in slot 1, the secondary image, as pending. This means that the device will boot into this image on a reboot. The parameter of boot_request_upgrade() decides if it is a test image or permanent.

int boot_request_upgrade(int permanent)

Parameters:

permanent – Whether the image should be used permanently or only tested once:
BOOT_UPGRADE_TEST=run image once, then confirm or revert.
BOOT_UPGRADE_PERMANENT=run image forever.

Best regards,
Marte

RE: DFU process in Nrf connect SDK for Nrf52840

Sarvesh — Mon, 07 Aug 2023 15:02:36 GMT

HI Marte, Thanks for reply , It cleared lots of my doubts, but still I have some quires ,

[quote userid="92402" url="~/f/nordic-q-a/102575/dfu-process-in-nrf-connect-sdk-for-nrf52840/440137"]You will get some generated configurations for the bootloader which you can use. In this case, PM_MCUBOOT_SECONDARY_ADDRESS and PM_MCUBOOT_SECONDARY_END_ADDRESS will be the start and end addresses of the secondary partition/bank, [/quote]

As I will get the start and end address from these about two, can I use the APIs from following for writing the image data in flash on given address ?

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/dfu/dfu_multi_image.html

[quote userid="92402" url="~/f/nordic-q-a/102575/dfu-process-in-nrf-connect-sdk-for-nrf52840/440137"]If you mark the new firmware image as a test image or confirmed, then MCUboot should handle this for you so the device automatically boots into the new image on a reboot.[/quote]

And how do I do this, it would be great if you can help me with these

RE: DFU process in Nrf connect SDK for Nrf52840

Marte Myrvold — Mon, 07 Aug 2023 13:47:23 GMT

Hi,

[quote user="Sarvesh"]what should I add in my application code to know where to write the new received firmware file over UART[/quote]

You will get some generated configurations for the bootloader which you can use. In this case, PM_MCUBOOT_SECONDARY_ADDRESS and PM_MCUBOOT_SECONDARY_END_ADDRESS will be the start and end addresses of the secondary partition/bank, so this is where you want to write the image.
One of the unofficial examples I mentioned in my previous response shows how to implement a SMP Client, Bluetooth: Central SMP Client DFU. This is showing DFU over Bluetooth LE, but a lot of the code can be reused for UART. The SMP Server sample mentioned can be used for DFU over serial as well.

The part that is relevant for how and where to store the firmware is in the send_upload2() function here: smp_client_ble/src/main.c#L840.

[quote user="Sarvesh"]And completion of writing , how would I boot from that location[/quote]

If you mark the new firmware image as a test image or confirmed, then MCUboot should handle this for you so the device automatically boots into the new image on a reboot.

Best regards,
Marte

RE: DFU process in Nrf connect SDK for Nrf52840

Sarvesh — Fri, 04 Aug 2023 13:05:00 GMT

Hi Marte, Thanks for reply

I have added this line

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

CONFIG_BOOTLOADER_MCUBOOT=y

in prj.conf file, now I am able to do the BLE DFU that is working fine. But I want to know following

what should I add in my application code to know where to write the new received firmware file over UART
And completion of writing , how would I boot from that location
I have read the sample Bootloader code as well given in nrf connect SDK , but did not understand what it will do

/*
 * Copyright (c) 2018 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 */

#include <zephyr/types.h>
#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>
#include <pm_config.h>
#include <fw_info.h>
#include <fprotect.h>
#include <bl_storage.h>
#include <bl_boot.h>
#include <bl_validation.h>
#include <nrfx_nvmc.h>

#if defined(CONFIG_HW_UNIQUE_KEY_LOAD)
#include <zephyr/init.h>
#include <hw_unique_key.h>

#define HUK_FLAG_OFFSET 0xFFC /* When this word is set, expect HUK to be written. */

int load_huk(void)
{
	if (!hw_unique_key_is_written(HUK_KEYSLOT_KDR)) {
		uint32_t huk_flag_addr = PM_HW_UNIQUE_KEY_PARTITION_ADDRESS + HUK_FLAG_OFFSET;

		if (*(uint32_t *)huk_flag_addr == 0xFFFFFFFF) {
			printk("First boot, expecting app to write HUK.\n");
			nrfx_nvmc_word_write(huk_flag_addr, 0);
			return 0;
		}
		printk("Error: Hardware Unique Key not present.\n");
		k_panic();
		return -1;

	}

	hw_unique_key_load_kdr();

	return 0;
}

SYS_INIT(load_huk, PRE_KERNEL_2, 0);
#endif


static void validate_and_boot(const struct fw_info *fw_info, uint16_t slot)
{
	printk("Attempting to boot slot %d.\r\n", slot);

	if (fw_info == NULL) {
		printk("No fw_info struct found.\r\n");
		return;
	}

	printk("Attempting to boot from address 0x%x.\n\r",
		fw_info->address);

	if (!bl_validate_firmware_local(fw_info->address,
					fw_info)) {
		printk("Failed to validate, permanently invalidating!\n\r");
		fw_info_invalidate(fw_info);
		return;
	}

	printk("Firmware version %d\r\n", fw_info->version);

	uint16_t stored_version;
	int err = get_monotonic_version(&stored_version);

	if (err) {
		printk("Failed to read the monotonic counter!\n\r");
		printk("We assume this is due to the firmware version not being enabled.\n\r");

		/*
		 * Errors in reading the firmware version are assumed to be
		 * due to the firmware version not being enabled. When the
		 * firmware version is disabled, no version checking should
		 * be done. The version is then set to 0 as it is not permitted
		 * in fwinfo and will therefore pass all version checks.
		 */
		stored_version = 0;
	}

	if (fw_info->version > stored_version) {
		int err = set_monotonic_version(fw_info->version, slot);

		if (err) {
			/*
			 * Errors in writing the firmware version are assumed to be
			 * due to the firmware version not being enabled. When the
			 * firmware version is disabled, no version updates should
			 * be done and this case can be ignored.
			 *
			 * The body of this if-statement is intentionally empty.
			 * It is left here solely for documentation purposes,
			 * describing why we ignore the error.
			 */
		}
	}

	bl_boot(fw_info);
}

#define BOOT_SLOT_0 0
#define BOOT_SLOT_1 1

int main(void)
{
	int err = fprotect_area(PM_B0_ADDRESS, PM_B0_SIZE);

	if (err) {
		printk("Failed to protect B0 flash, cancel startup.\n\r");
		return 0;
	}

	uint32_t s0_addr = s0_address_read();
	uint32_t s1_addr = s1_address_read();
	const struct fw_info *s0_info = fw_info_find(s0_addr);
	const struct fw_info *s1_info = fw_info_find(s1_addr);

	if (!s1_info || (s0_info->version >= s1_info->version)) {
		validate_and_boot(s0_info, BOOT_SLOT_0);
		validate_and_boot(s1_info, BOOT_SLOT_1);
	} else {
		validate_and_boot(s1_info, BOOT_SLOT_1);
		validate_and_boot(s0_info, BOOT_SLOT_0);
	}

	printk("No bootable image found. Aborting boot.\n\r");
	return 0;
}

This is main.c file code written there

RE: DFU process in Nrf connect SDK for Nrf52840

Marte Myrvold — Fri, 04 Aug 2023 12:57:50 GMT

Hi,

The process in nRF Connect SDK is different, but a lot of it is done automatically.

To enable bootloader and DFU in your application, you only need to set CONFIG_BOOTLOADER_MCUBOOT=y in your project config file (prj.conf). With this, the bootloader firmware will automatically be built as a child image of your application. It also enabled the partition manager, which creates partitions. Please be aware that if you have a bootloader, you must create your own static partitions, and not use the dynamic partitions.

The DFU image is automatically generated when you build the application, so you do not need to generate settings or merge the hex files.

We have a lot of information about bootloaders, DFU, partition manager, etc. in our documentation, so I recommend that you read through that. I will link to the most relevant ones.

Bootloaders and Device Firmware Updates
Partition Manager
MCUboot documentation
Build and configuration system (mainly the sections about building FOTA images, output build files, and MCUboot output build files).

I also recommend taking a look at the bootloader samples made by a colleague: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples. They are not official samples, so they have not been tested thoroughly and might not be the latest version of nRF Connect SDK, but you will find some very good explanations and samples there.

Best regards,
Marte