Some questions about NCS DFU target library

[db_lw]

Hello,

I've got some questions regarding the use of DFU target library. I get my update data from the UART and like to use a setup with two partitions on my device. Is this generally possible with the library?

The dfu_target_init() function has the img_num argument. does this relate to the partition number?

Do I have to select which partition to use? If yes how would I do this?

If a firmware update was succesful and dfu_target_done(true) and dfu_target_schedule_update(0) are called does the reboot to actually run the new firmware need to be done manually?

Thanks in advance!

[runsiv]

Hi David

Could you tell me a bit regarding your application

Which version of the SDK are you using?

Which device are you using? There are some differences between for example the 52 series and the 53 series hench my question. 

I've got some questions regarding the use of DFU target library. I get my update data from the UART and like to use a setup with two partitions on my device. Is this generally possible with the library?

With two partitions, are you referring to two partitions for the your application where one is the current application and one is for the new one like described here?  If so yes it is possible, you will find an exercise here that walk you through setting it up

The dfu_target_init() function has the img_num argument. does this relate to the partition number?

The img_num reefers to if the image is for the application core or the network core if you have a multi image build. 

If a firmware update was succesful and dfu_target_done(true) and dfu_target_schedule_update(0) are called does the reboot to actually run the new firmware need to be done manually?

If they are successful you should be running the new image after a reboot

Regards

Runar

[db_lw]

Hi Runar,

thanks for your response.

runsiv said:

Which version of the SDK are you using?

nRF Connect SDK v2.0.2

runsiv said:

Which device are you using?

nRF52840

runsiv said:

With two partitions, are you referring to two partitions for the your application where one is the current application and one is for the new one like described here?

Yes, this is what I mean. Two partitions for the application. I already looked into this lesson and found it very helpful but the configuration in the exercise is a bit different than mine. The exercise uses mcumgr protocol and not the DFU target library.

runsiv said:

The img_num reefers to if the image is for the application core or the network core if you have a multi image build. 

Ok, that's good to know.

Is the selection of the right partition to flash the new firmware, done automatically under the hood in the DFU target library or do I have to write this my self?

Best regards
David

[runsiv]

db_lw said:

Is the selection of the right partition to flash the new firmware, done automatically under the hood in the DFU target library or do I have to write this my self?

I'ts the bootloader task to copy it the to correct spot. You can have a look at this sample a coworker of mine made. The image number is set to 0 so the image will be sent to the secondary slot as it should be

Regards

Runardfu_target_test.zip

[db_lw]

Thanks for your reply it was helpful.

[jay]

Hi runsiv, 

I'm also planning to use the dfu_target library for performing OTA updates over cellular, where the firmware chunks are received via UART from a modem.

While reviewing the dfu_target_test.zip example you shared (particularly the main.c file), I noticed that the offset variable is incremented by the chunk size after each write. However, I’d like to better understand:

How does dfu_target_write() internally handle the firmware image address updates?
Does it automatically manage the correct memory offset for the write operation based on previous writes, or is there any explicit address management required from our side?

Appreciate your clarification, as this will help ensure we integrate it correctly with our modem-based delivery flow.

Thanks,
Jay

#include <stdio.h>
#include <dfu/dfu_target_mcuboot.h>

#include <zephyr/logging/log.h>
#define LOG_MODULE_NAME main
LOG_MODULE_REGISTER(LOG_MODULE_NAME);

#define CHUNK_SIZE    156
#define FW_SIZE CHUNK_SIZE * 0x400

__ALIGN(4) static uint8_t fw_image[CHUNK_SIZE];


int main(void)
{
	int err;
	size_t offset = 0;
	__ALIGN(4) uint8_t dfu_buf[(CHUNK_SIZE + 3) & ~3];

	memset(fw_image, 0xAA, sizeof(fw_image));
	
	err = dfu_target_mcuboot_set_buf(dfu_buf, sizeof(dfu_buf));
	LOG_INF("dfu_target_mcuboot_set_buf: %d. Size: %d ", err, sizeof(dfu_buf));
	
	err = dfu_target_init(DFU_TARGET_IMAGE_TYPE_MCUBOOT, 0, FW_SIZE, NULL);
	LOG_INF("dfu_target_init:%d", err);

	do {
		err = dfu_target_write(fw_image, CHUNK_SIZE);
		if (err) {
			LOG_ERR("dfu_target_write() failed. (err %d)", err);
			return 0;
		}
		offset += CHUNK_SIZE;

	} while (offset <= FW_SIZE);

	LOG_INF("Hello World! %s", CONFIG_BOARD);
	return 0;
}