NCS DFU Supported External Flash Devices

[Bryan]

OS: Windows

NCS: 2.2.0

We have discovered that we do not have enough internal flash space to support BLE DFU and need to add an external flash to our nRF52833-based design.

The nRF52840 DK board has an external flash (MX25R64) and BLE DFU is shown to work with the bus configured as SPI or QSPI.

 https://devzone.nordicsemi.com/f/nordic-q-a/82430/ncs-external-flash-ota-change-qspi-to-spi/345238

Our board is very small, so the MX25R64 is simply too physically large, so we are looking at the Gigadevices GD25WD40E/20E.  It is tiny at 1.2x1.2mm and supports SPI bus.

https://www.mouser.com/datasheet/2/870/gd25wd40e_gd25wd20e_datasheet_rev1_1_20221019-3081635.pdf

We have no way of verifying this device without doing another version of the board.  That is a big risk.

1.  Is there a specific memory layout of the flash for NCS DFU to work?  For example, the Gigadevices part's memory layout looks like:

2. Is there a specific list of SPI/QSPI flash devices that work with NCS DFU?

[Kenneth]

Hello,

I found 4 other cases with similar error message, I am linking it here it in case it can be of help?
MCUBoot runtime error: "Cannot upgrade: not a compatible amount of sectors" with external flash on nrf9160 
MCUBoot, Zephyr, and static partition manager 
MCUBoot fails to load if using CMake Overlay Config 
Device Firmware Update (DFU) with MCUBoot bootloader showing Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small? 

Wild guess, can you try:
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y 

Kenneth

[Bryan]

Kenneth,

I keep getting shifted onto other tasks.  Sorry for the delay.

CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y  was not the root cause.

I ported the https://github.com/nrfconnect/sdk-zephyr/tree/main/tests/drivers/flash project to the nRF52833DK with the external SPI NOR Flash wired to it and got it working.

*** Booting Zephyr OS build v3.2.99-ncs1 ***
Running TESTSUITE flash_driver
===================================================================
START - test_read_unaligned_address
PASS - test_read_unaligned_address in 0.047 seconds
===================================================================
TESTSUITE flash_driver succeeded

------ TESTSUITE SUMMARY START ------

SUITE PASS - 100.00% [flash_driver]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.047 seconds
- PASS - [flash_driver.test_read_unaligned_address] duration = 0.047 seconds

------ TESTSUITE SUMMARY END ------

===================================================================
PROJECT EXECUTION SUCCESSFUL

I can confirm it is working by simply lifting the power pin to the SPI NOR Flash.

E: Device id ff ff ff does not match config 9d 60 14
*** Booting Zephyr OS build v3.2.99-ncs1 ***
Running TESTSUITE flash_driver
===================================================================

Assertion failed at ../src/main.c:59: flash_driver_setup: device_is_ready(flash_dev) is false

START - test_read_unaligned_address
FAIL - test_read_unaligned_address in 0.001 seconds
===================================================================
TESTSUITE flash_driver failed.

------ TESTSUITE SUMMARY START ------

SUITE FAIL - 0.00% [flash_driver]: pass = 0, fail = 1, skip = 0, total = 1 duration = 0.001 seconds
- FAIL - [flash_driver.test_read_unaligned_address] duration = 0.001 seconds

------ TESTSUITE SUMMARY END ------

===========================

I now have the nRF52833DK with external SPI NOR flash working, too.  The key was to use the exact same nrf52833dk_nrf52833.overlay file from the flash test above in /boards and /child_image/mcuboot/boards.

The only difference between what works and what caused issues is the first five lines in the overlay file.

from the flash test that works

/ {
    aliases {
       spi-flash0 = &is25lp080d;
    };
};

what I was trying to use, which was based on the nRF52840DK external flash overlay file.
/ {
    chosen {
       nordic,pm-ext-flash = &is25lp080d;
    };
};

Kenneth - Two final questions.

1.  I am not understanding what it hated about nordic,pm-ext-flash = &is25lp080d; This is the exact syntax used in the hello_world_dfu_840DK_ext_flash project overlay files.

2.  I used spi-flash0 in the flash test because it was the exact same syntax as /boards/nrf52840dk_mx25l51245g.overlay

I honestly didn't expect it to work in the DFU project.  It seems that spi-flash0 is standard label in Zephyr to define a external spi flash device.  It is used in a lot of zephyr/boards/*.dts files.  Am I understanding this correctly?

I have attached all three of the projects for everyone's reference.

hello_world_dfu_840DK_ext_flash.zip

6153.flash.ziphello_world_dfu_833DK_ext_flash.zip

[Kenneth]

Hello,

You should use both alias and chosen, ref:

/ { 	
	aliases 
	{ spi-flash0 = &is25lp080d; }; 
	chosen 
	{ nordic,pm-ext-flash = &is25lp080d; }; 
};

Looks like nRF52840DK already have the spi-flash0 defined in the board file:
https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts#L129

Well spotted this was the problem!

Kenneth

[Bryan]

Kenneth,

Once again I was switched off this and onto something else.  I never got to test adding "chosen".  Without "chosen" it is still using internal flash.

I have upgraded to the latest NCS 2.3.0.  I am back to getting this output when it boots.

*** Booting Zephyr OS build v3.2.99-ncs2 ***
I: Starting bootloader
W: Cannot upgrade: not a compatible amount of sectors
I: Bootloader chainload address offset: 0xf000
*** Booting Zephyr OS build v3.2.99-ncs2 ***
Hello World 1! nrf52833dk_nrf52833

Since it had been awhile, I reconfirmed that the  https://github.com/nrfconnect/sdk-zephyr/tree/main/tests/drivers/flash test still works.  

from the file ncs\v2.3.0\bootloader\mcuboot\boot\bootutil\src\swap_move.c

num_sectors_pri = boot_img_num_sectors(state, BOOT_PRIMARY_SLOT);
num_sectors_sec = boot_img_num_sectors(state, BOOT_SECONDARY_SLOT);
if ((num_sectors_pri != num_sectors_sec) &&
(num_sectors_pri != (num_sectors_sec + 1))) {
       BOOT_LOG_WRN("Cannot upgrade: not a compatible amount of sectors");
       return 0;
}

However, if I look at the partition manager report it shows primary and secondary are exactly the same size.

PS C:\Virtuix\nordic\myapps\hello_world_dfu_833DK_ext_flash\build> west build -t partition_manager_report
-- west build: running target partition_manager_report
[1/1] cmd.exe /C "cd /D C:\Virtuix\nordic\myapps\hello_w...ps/hello_world_dfu_833DK_ext_flash/build/partitions.yml"
external_flash (0x100000 - 1024kB):
+-------------------------------------------+
| 0x0: mcuboot_secondary (0x71000 - 452kB) |
| 0x71000: external_flash (0x8f000 - 572kB) |
+-------------------------------------------+

flash_primary (0x80000 - 512kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xf000 - 60kB) |
+---0xf000: mcuboot_primary (0x71000 - 452kB)-----+
| 0xf000: mcuboot_pad (0x200 - 512B) |
+---0xf200: mcuboot_primary_app (0x70e00 - 451kB)-+
| 0xf200: app (0x70e00 - 451kB) |
+-------------------------------------------------+

sram_primary (0x20000 - 128kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x20000 - 128kB) |
+--------------------------------------------+

PS C:\Virtuix\nordic\myapps\hello_world_dfu_833DK_ext_flash\build>

What I am missing?

8463.hello_world_dfu_833DK_ext_flash.zip

[Kenneth]

Hello,

I can see you are getting help in a private case. I suggest you continue there, but please share your findings for anyone experiencing the same that find this public case.

Kenneth

[Bryan]

Kenneth,

My private case is for our custom board that has two spi busses, so it is more complex.  This one is just to get the basic external flash DFU working.

[Bryan]

I just read through Hakon's response to my private case.  Now I see what you mean.  I will test it and update everyone.