DFU from external flash using SPI NOR

RE: DFU from external flash using SPI NOR

embeddedER — Sat, 04 Jun 2022 00:06:40 GMT

Thanks, Simon!

RE: DFU from external flash using SPI NOR

Simon — Fri, 03 Jun 2022 14:09:09 GMT

Take a look at this PR https://github.com/nrfconnect/sdk-mcuboot/pull/200, which I think is related to you issue. The fix for this issue is merged into NCS v2.0.0.

You can see how the function boot_write_magic() has changed:

NCS v1.8.0: https://github.com/nrfconnect/sdk-mcuboot/blob/v1.7.99-ncs4/boot/bootutil/src/bootutil_public.c#L316-L332

NCS v2.0.0: https://github.com/nrfconnect/sdk-mcuboot/blob/v1.9.99-ncs1/boot/bootutil/src/bootutil_public.c#L326-L361

Best regards,

Simon

RE: DFU from external flash using SPI NOR

embeddedER — Wed, 01 Jun 2022 04:34:54 GMT

Hi Simon,

Did you get more insights on this problem? I've an exactly the same issue and I see the same error:

info.it_magic(0x0) != IMAGE_TLV_INFO_MAGIC (0x6907)

I am using Winbond flash and nrf52832 with ncs version 1.8.0.

So, after downloading the image, it fails to validate the image and then doesn't switch to the new firmware. Anything that I need to take care of with ncs v1.8.0?

TIA!

RE: DFU from external flash using SPI NOR

Simon — Mon, 12 Apr 2021 08:16:59 GMT

No, I was just wondering if it was present (added as a child image). I'm happy you found a working solution. I think I have to do some testing myself to see exactly when/how the PM partitions/dts applies or not.

RE: DFU from external flash using SPI NOR

dhump3 — Fri, 09 Apr 2021 23:21:26 GMT

Yes, I see that folder. Anything in here I should be looking for?

RE: DFU from external flash using SPI NOR

Simon — Fri, 09 Apr 2021 08:39:25 GMT

Hmm.. That's interesting. I thought that the Partition Manager decided the partitions (and DTS partitions would get ignored) when your application included child-images, like mcuboot. As stated in the PM documentation:

"The Partition Manager is activated for all multi-image builds, regardless of which build strategy is used for the child image."

Apparently this is not the case for you. Maybe my understanding is wrong, or there have been some updates to NCS how this is handled.

To make it clear, you do see the folder <sample>/build/zephyr/mcuboot in your application?

RE: DFU from external flash using SPI NOR

dhump3 — Wed, 07 Apr 2021 17:41:36 GMT

Hi,

Its been a while but my teammate has finally gotten both ble dfu and usb dfu working on the smp_svr sample. We were under the impression that we didn't have to configure the board file at all because the partition manager is supposed to take care of everything. I guess this was a mistake as when we made the following changes to our board file, the DFU just started working.

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0xC000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x35000>;
		};
	};
};

&mx25r32 {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;
        
        slot1_partition: partition@0 {
            label = "image-1";
            reg = <0x00000000 0x000073000>;
        };
        scratch_partition: partition@73000 {
            label = "image-scratch";
            reg = <0x000073000 0x000073000>;
        };
    };
};

We didn't have to make any of the changes discussed earlier in the thread and we're basically working from a fresh zephyr install. We did update to NCS v1.5.0 where I was previously testing on NCS v.1.4.0.

RE: DFU from external flash using SPI NOR

Simon — Thu, 28 Jan 2021 19:41:31 GMT

devzone.nordicsemi.com/.../1588.peripheral_5F00_uart_5F00_spi_5F00_nor_5F00_dfu.zip

RE: DFU from external flash using SPI NOR

Simon — Thu, 28 Jan 2021 19:40:14 GMT

There was quite much work required to get your sample to run on the nrf52840dk, so I just modified my simplifed sample to use spi_nor instead of nrf_qspi_nor, and I was actually able to make it work. I successfully performed a dfu using external flash and spi_nor.

I'll upload the sample here. Try modifying it to work with your external flash and your particular board. I think this is what you need to change:

mcuboot_conf and prj.conf: "MX25R64" to "MX25R32"
Change the name of the overlay file (nrf52840dk_nrf52840.overlay) to your board name
Change mx25r64 with mx25r32 in the overlay file

There might be more you have to change that I'm not aware of.

Also remember to change mcuboot.c as described earlier in this ticket.

Build the application two times, after the first build, flash it to the chip. Then change the text

"Application version 1.0.0\n" to v2.0.0, build it again and transfer the file app_update.bin to the phone.

Then download nRF Connect Device Manager, and transfer the .bin file

You need to bond with the device (open Termite to see logging/instructions) in order to perform the update.

If you're not able to make this work, I'll get ahold of an nRF52833 and and external flash and try to make it work with that.

devzone.nordicsemi.com/.../5807.peripheral_5F00_uart_5F00_spi_5F00_nor_5F00_dfu.zip

RE: DFU from external flash using SPI NOR

Simon — Thu, 28 Jan 2021 08:20:05 GMT

I got the project, and will try to reproduce.

RE: DFU from external flash using SPI NOR

Simon — Wed, 27 Jan 2021 11:13:37 GMT

I've sent you a privat message here on DevZone, check that out on how to share the project privately.

RE: DFU from external flash using SPI NOR

dhump3 — Tue, 26 Jan 2021 18:47:29 GMT

Is there a way I can send the application privately?

RE: DFU from external flash using SPI NOR

Simon — Tue, 26 Jan 2021 08:08:08 GMT

Could you send over your application in a zipped file? Then I could modify it to work with the nRF52840 and the mx25r64 and try to reproduce the issue.

RE: DFU from external flash using SPI NOR

dhump3 — Tue, 26 Jan 2021 00:28:46 GMT

I have added the log statement and made changes to spi_nor_write(). Unfortunately, I have not seen any change in the bootloader output:

[00:00:00.253,570] <inf> mcuboot: Starting bootloader
[00:00:00.254,241] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.254,241] <inf> mcuboot: Boot source: none
[00:00:00.254,791] <inf> mcuboot: Swap type: test
[00:00:00.254,791] <inf> mcuboot: Header is valid!
[00:00:00.254,791] <inf> mcuboot: Inside bootutil_img_validate()
[00:00:00.880,889] <inf> mcuboot: offset 300292 | image size: 299780 | header size 512
[00:00:00.954,650] <inf> mcuboot: bootutil_img_validate() successful!
[00:00:00.954,650] <inf> mcuboot: Inisde boot_perform_update()
[00:00:21.496,856] <inf> mcuboot: Inisde boot_perform_update() completed with status 0
[00:00:21.497,009] <inf> mcuboot: Header is valid!
[00:00:21.497,009] <inf> mcuboot: Inside bootutil_img_validate()
[00:00:21.736,511] <inf> mcuboot: offset 300292 | image size: 299780 | header size 512
[00:00:21.736,541] <err> mcuboot: tlv magic is wrong! expected 6907 but got 0
[00:00:21.736,541] <err> mcuboot: bootutil_tlv_iter_begin failed with error -1
[00:00:21.736,541] <err> mcuboot: Failed to validate the image!
[00:00:21.736,541] <err> mcuboot: Image in the primary slot is not valid!
[00:00:21.736,541] <err> mcuboot: Unable to find bootable image

Note that the image size is so large because I am testing with the custom application I am building. The offset seems to be the image size + the header size. Here are the code changes I made to the spi_nor driver. I added this function:

static inline int spi_nor_write_sub_word(const struct device *dev, off_t addr,
                                         const void *src, size_t slen)
{
    uint8_t __aligned(4) buf[4];
    int ret;
    ret = spi_nor_cmd_addr_read(dev, SPI_NOR_CMD_READ, addr, buf,
                                sizeof(buf));
    spi_nor_wait_until_ready(dev);
    if (ret >= 0) {
        memcpy(buf, src, slen);
        spi_nor_cmd_write(dev, SPI_NOR_CMD_WREN);
        ret = spi_nor_cmd_addr_write(dev, SPI_NOR_CMD_PP, addr, buf,
                                     sizeof(buf));
    }
    return ret;
}

And then in spi_nor_write() I edited lines 498 - 499 to be:

if (to_write < 4U) {
    ret = spi_nor_write_sub_word(dev, addr, src, to_write);
} else {
    spi_nor_cmd_write(dev, SPI_NOR_CMD_WREN);
    ret = spi_nor_cmd_addr_write(dev, SPI_NOR_CMD_PP, addr,
                                 src, to_write);
}

I will continue digging to see whats going on with the tlv magic.

RE: DFU from external flash using SPI NOR

Simon — Mon, 25 Jan 2021 13:13:49 GMT

I've talked to a developer internally and got some insight. I think the reason for this issue is that the write alignment in the spi_nor driver is not set to 4 bytes. As you can see in Zephyr issue 26729, it is not possible to write to the mx25r64 if the minimum write size is less than 4, I believe it's the same with your mx25r32. The qpsi_nor driver has been modified to take this into account. The two links below points to the code that will handle writes smaller than 4 bytes:

If you look inside write_sub_word(), it will handle cases where less than 4 bytes is written to flash. E.g. if you write 2 bytes, then you need to read out 4 bytes and store it into a buffer, put your 2 bytes into the same buffer, before writing all the 4 bytes into the flash. This is to preserve unchanged data.

Could you try to modify spi_nor_write() to do the same?

Please ask if anything is unclear.

Best regards,

Simon

RE: DFU from external flash using SPI NOR

Simon — Sun, 24 Jan 2021 09:56:26 GMT

I can see that boot_validate_slot() is called several times from different places, but if I've concluded correctly the call from context_boot_go() is the one that is leading to this error. This means that the update is already done, and the image previously located in the secondary slot (external flash), now residing in the primary slot is being validated.

I am not sure why it can't find IMAGE_TLV_PROT_INFO_MAGIC. I'll talk to a developer on Monday.

Maybe you could try to print out the offset, it should be equal to the size of the binary (app_update.bin) if I understand it correctly

bootutil_tlv_iter_begin(..){
 ..
 ..
 off_ = BOOT_TLV_OFF(hdr);
 //Add the line below
 printk("offset %d | image size: %d | header size: %d \n", off_, hdr->ih_img_size, hdr->ih_hdr_size);
    if (flash_area_read(fap, off_, &info, sizeof(info))) {
        return -1;
    }

    if (info.it_magic == IMAGE_TLV_PROT_INFO_MAGIC) {
    ..

Best regards,

Simon

RE: DFU from external flash using SPI NOR

dhump3 — Thu, 21 Jan 2021 19:51:28 GMT

I added more logging and have determined the issue is with the tlv magic. I added a log statement there to see what the difference is.

[00:00:22.004,516] <err> mcuboot: tlv magic is wrong! expected 0x6907 but got 0x0000

RE: DFU from external flash using SPI NOR

Simon — Thu, 21 Jan 2021 19:17:13 GMT

Try to add some unique logging before each return statement inside bootutil_tlv_iter_begin() to figure out exactly where it fails. E.g. printk("bootutil_tlv_iter_begin() no 1\n"), printk("bootutil_tlv_iter_begin() no 2\n") and so on.

RE: DFU from external flash using SPI NOR

dhump3 — Wed, 20 Jan 2021 21:05:10 GMT

Hi Simon,

For some reason I there was no reply button so am just replying to my original question. I have been able to add log statements and read the flash out. I will go through each step I have done.

I start by flashing an image of version 0.1.0 normally. I then use the command mcumgr image upload -e my_image.bin to upload an image of version 0.2.0. After this I ran a mcumgr image list and get the following output:

Images:
 image=0 slot=0
    version: 0.1.0
    bootable: true
    flags: active confirmed
    hash: f225666061fb89f3b354c0a68024125f754ba19bc04bff8de96d3272fe2e8fe4
 image=0 slot=1
    version: 0.2.0
    bootable: true
    flags: 
    hash: 9b79b38d0ef3d0aef9540ca3544714abcfe5949c7c980fea1d8246fa48ded321

This seems to be working properly. I then reset the device without testing the image in order to read the image_1 flash area on boot using the following code:

flash_area_open(FLASH_AREA_ID(image_1), &fap);
uint32_t data = 0;
flash_area_read(fap, 0, &data, sizeof(data));
LOG_INF("IMAGE-1 Magic = 0x%08X", data);
flash_area_close(fap);

This gives me the following log output

[00:00:01.796,783] <inf> app: IMAGE-1 Magic = 0x96f3b83d

I believe it is reversed because I stored it in a uint32_t rather than reading into a uint8_t buffer, so the magic seems fine. I then proceed and run the command mcumgr image test 9b79b38d0ef3d0aef9540ca3544714abcfe5949c7c980fea1d8246fa48ded321. This gives me the expected output of:

Images:
 image=0 slot=0
    version: 0.1.0
    bootable: true
    flags: active confirmed
    hash: f225666061fb89f3b354c0a68024125f754ba19bc04bff8de96d3272fe2e8fe4
 image=0 slot=1
    version: 0.2.0
    bootable: true
    flags: pending
    hash: 9b79b38d0ef3d0aef9540ca3544714abcfe5949c7c980fea1d8246fa48ded321

I then reset the device once again and the bootloader does the swap and fails as usual. Here is the output with some extra logging I added:

[00:00:00.253,601] <inf> mcuboot: Starting bootloader
[00:00:00.254,333] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.254,333] <inf> mcuboot: Boot source: none
[00:00:00.254,974] <inf> mcuboot: Swap type: test
[00:00:00.254,974] <inf> mcuboot: Header is valid!
[00:00:00.254,974] <inf> mcuboot: Inside bootutil_img_validate()
[00:00:01.040,039] <inf> mcuboot: bootutil_img_validate() successful!
[00:00:01.040,069] <inf> mcuboot: Inisde boot_perform_update()
[00:00:21.213,592] <inf> mcuboot: Header is valid!
[00:00:21.213,592] <inf> mcuboot: Inside bootutil_img_validate()
[00:00:21.537,841] <err> mcuboot: bootutil_tlv_iter_begin failed with error -1
[00:00:21.537,841] <err> mcuboot: Failed to validate the image!
[00:00:21.537,872] <err> mcuboot: Image in the primary slot is not valid!
[00:00:21.537,872] <err> mcuboot: Unable to find bootable image

Each "Header is valid!" is printed after the function boot_is_header_valid() completes successfully. I determined that the failure is occurring in the function boot_img_validate() after the swap occurs, which can be seen in the logs. I added logs inside of that function to determine where its failing and it seems to be failing here. The function bootutil_tlv_iter_begin() returns -1 in numerous different cases, I can add more logging there to try to narrow it down if that helps.

After this failure to validate the image, I have to flash a new image normally. I flash an image of version 0.3.0 and then run mcumgr image list and get this output:

Images:
 image=0 slot=0
    version: 0.3.0
    bootable: true
    flags: active confirmed
    hash: cc631d7dc18337d07b7c17e72f8d1e08f8a9beceab361fa46bb84075cc77fd34
 image=0 slot=1
    version: 0.2.0
    bootable: true
    flags: 
    hash: 9b79b38d0ef3d0aef9540ca3544714abcfe5949c7c980fea1d8246fa48ded321

The 0.2.0 image is still there. Also the output for the magic remains unchanged.

RE: DFU from external flash using SPI NOR

Simon — Tue, 19 Jan 2021 20:10:42 GMT

It would be intereresting to see why the validation fails. Try to add some logging inside boot_is_header_valid() and boot_image_check() to figure out where and why it fails.
Could you also try to add BOOT_LOG_INF("Inside boot_perform_update()"); in boot_perform_update()? To see if it performs the image swap before or after you get the error "Image in the primary slot is not valid!". I guess the swap happens before the error, and the validation of the new image fails.
Are you able to read the content of the flash after you've transferred the image to the external flash, and before resetting the chip (before the swap happens)? This might be hard to achieve if you're transferring the image over a mobile app, as it will reset automatically after the transfer is complete. However if you use the mcumgr command line tool with macOS or Linux (not supported on Windows), it should be fine, since you're issuing the reset command manually. I'm not familiar with dfu-util but it might work with that tool as well. Try reading out the 4 first bytes, where the magic number should be stored. It should be equal to 0x 3d b8 f3 96. If you don't know how to read out the flash, please tell me and I can look into how to go about it. You could also try to read it out after the swap has happened.

Best regards,

Simon

RE: DFU from external flash using SPI NOR

Simon — Mon, 18 Jan 2021 13:11:02 GMT

Hello dhump3, I'll take over this case. I'll put off some time tomorrow and see if I can get to the bottom of your issue.

Best regards,

Simon

RE: DFU from external flash using SPI NOR

dhump3 — Thu, 14 Jan 2021 19:54:46 GMT

Update: I have gone back to mcumgr to try and get more information on the images. I first flash an image of version 0.2.0 and then I get this output when I run mcumgr image list:

Images:
 image=0 slot=0
    version: 0.2.0
    bootable: true
    flags: active confirmed
    hash: 1a55d38e4c3fff9c68e13274b534664a06e976726b7081812d2698b21fb4105e

I then upload an image of version 0.3.0 to the secondary slot of the device and get this output:

Images:
 image=0 slot=0
    version: 0.2.0
    bootable: true
    flags: active confirmed
    hash: 1a55d38e4c3fff9c68e13274b534664a06e976726b7081812d2698b21fb4105e
  image=0 slot=1
    version: 0.3.0
    bootable: true
    flags: 
    hash: adf638ddfb17699d45d2b4fe6c340db5ab4f7504655f3a728982d087cd345dd8

I then test the new image and get the following output from the bootloader:

*** Booting Zephyr OS build v2.4.0-ncs1  **
[00:00:00.253,601] <inf> mcuboot: Starting bootloader
[00:00:00.254,364] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.254,364] <inf> mcuboot: Boot source: none
[00:00:00.255,004] <inf> mcuboot: Swap type: test
[00:00:22.608,764] <err> mcuboot: Image in the primary slot is not valid!
[00:00:22.608,764] <err> mcuboot: Unable to find bootable image

At this point the device is pretty much bricked, so I just end up flashing the version 0.3.0 image via nrfjprog to device. I decided to re run the image list command to see what was going on and get this:

Images:
 image=0 slot=0
    version: 0.3.0
    bootable: true
    flags: active confirmed
    hash: adf638ddfb17699d45d2b4fe6c340db5ab4f7504655f3a728982d087cd345dd8
 image=0 slot=1
    version: 0.2.0
    bootable: true
    flags:
    hash: 2ef9a81cbe11a728a774bedb3ffeb7c66a01b8823693a82b166fa66cf1d26c74

It seems it actually did try to swap the images as image 0.2.0 is now in slot 1. However the hash is completely different which must mean something went wrong in the swapping of the images. Just to see what happens, I then test the slot 1 image (0.2.0) and get this output from the bootloader:

*** Booting Zephyr OS build v2.4.0-ncs1  **
[00:00:00.253,631] <inf> mcuboot: Starting bootloader
[00:00:00.254,394] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.254,394] <inf> mcuboot: Boot source: none
[00:00:00.255,035] <inf> mcuboot: Swap type: test
[00:00:09.016,571] <err> mcuboot: Image in the secondary slot is not valid!

Mcuboot recognizes the secondary image is invalid, deletes it and then it boots up the primary slot. Running image list now gives me:

Images:
 image=0 slot=0
    version: 0.3.0
    bootable: true
    flags: active confirmed
    hash: adf638ddfb17699d45d2b4fe6c340db5ab4f7504655f3a728982d087cd345dd8
Split status: N/A (0)

I'm not entirely sure whats going on here but hopefully this extra detail can help narrow down the issue.

RE: DFU from external flash using SPI NOR

Vidar Berg — Thu, 14 Jan 2021 16:11:06 GMT

Hi,

I only tested with BLE using the nRF connect android app, so I will try set up a test with dfu-util as well to see if I run into the same issue. But I can't promise that I will get time for that tomorrow, it might have to wait til next week.

[quote user="dhump3"]I did verify that everything was still working when I do not use external flash.[/quote]

This helps narrow it down, thanks.

RE: DFU from external flash using SPI NOR

dhump3 — Wed, 13 Jan 2021 20:54:36 GMT

Hi, I had to work on something else for a bit so I apologize for the delayed response. I have picked this up again and made the changes in your above post to the file zephyr/subsys/dfu/boot/mcuboot.c. I did not see any change and something is still going wrong in the bootloader. For some reason, I am also not getting log output in the bootloader, so I don't have much to show here. Going to try to get that working so I can give more information.

I did verify that everything was still working when I do not use external flash. Note, I am following the sample and not using mcumgr to do the dfu but rather dfu-util using the command dfu-util --alt 0 --download build/zephyr/app_update.bin. The example says to use --alt 1 but for some reason that does not work for me.

RE: DFU from external flash using SPI NOR

Vidar Berg — Sat, 09 Jan 2021 19:06:10 GMT

Update: The app failed to write the 16-byte MAGIC number because the byte array was kept in FLASH memory, and the SPI EasyDMA can only access data in RAM. I belive this is what caused the update to fail for me.

The original byte array declaration in mcuboot.c with the 'const' qualifier which causes it to only be placed in FLASH:

static const uint32_t boot_img_magic[4] = {
	0xf395c277,
	0x7fefd260,
	0x0f505235,
	0x8079b62c,
};

And here is after I removed 'const' to get it loaded to RAM:

static uint32_t boot_img_magic[4] = {
	0xf395c277,
	0x7fefd260,
	0x0f505235,
	0x8079b62c,
};

Please try to include this fix and see if you get the same result.