Determine boot slot/offset from application for custom DFU

[jrhaws]

I am working on enabling MCUboot with direct XIP with revert in NCS v2.5.1.  Right now, I have things pretty well working - I can build an initial confirmed image and boot it (slot 0), then build "update" images and load them using my existing custom DFU application to slot 1. (Documentation on this is here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/device_guides/working_with_nrf/nrf52/developing.html#build-configuration-additions-for-mcuboot-in-the-direct-xip-mode)

I have tested improperly signed images and corrupt images and valid images and in each case it boots to the expected slot.

Now I need to update my custom DFU application to understand which slot I am currently booting from so that I can write into the other slot. So far in my searching I have not found the API to do so.  MCU boot knows this, since it reports to me that it is booting Image 0 from the {primary,secondary} slot.

Once I know which slot I am booting from, I believe I can simply continue using the flash_img_init() API (flash_img_init_id() actually) with the appropriate area_id and I should be golden.

Am I missing something? Are there any changes I would need to make beyond just calling flash_img_init_id()? How can I determine which slot I have booted to from my application?

[jrhaws]

I was just able to confirm with static slot assignments that the flash API does work properly when I simply choose a different slot.

The only question that remains is how can I determine what has booted!

[Sigurd Hellesvik]

Hi,

I understand what you want, and I don't know. So I asked our bootloader developers for help with this.
I will return when I hear back from them. Hopefully tomorrow, but might be next week.

Regards,
Sigurd Hellesvik

[Sigurd Hellesvik]

Our developers had a smart way to do this. Just check which addresses we are running from now. So I wrote this snippet to show how you can do it. I also tested it, and seems like it works on my end. However, I always recommend that you do your own tests.

#include <zephyr/kernel.h>
#include <pm_config.h>


int main(void)
{
	uint32_t current_addr = &main;
	printk("Current addr: %x\n",current_addr);

	if(
			current_addr > PM_MCUBOOT_PRIMARY_ADDRESS
			&& current_addr < PM_MCUBOOT_PRIMARY_END_ADDRESS
	  ) {
		printk("Running from primary slot\n");
	}

	else if(
			current_addr > PM_MCUBOOT_SECONDARY_ADDRESS
			&& current_addr < PM_MCUBOOT_SECONDARY_END_ADDRESS
	       ) {
		printk("Running from secondary slot\n");
	}
	else {
		printk("Something went wrong");
	}

	return 0;
}

Now, when uploading via mcumgr-cli, I do not need to specify slots, so our mcumgr library is doing something to figure this out also, which may or may not be different than this method. However, it is no need to dive into that if the above solution is good enough for you.

[jrhaws]

This works great!  Thanks for the support!