Trying to do DFU on nRF5340 development kit with external flash MX66L1G

[Radhika-eaton]

Build environment is the nRF SDK Connect for VS Code extension with ncs 2.3.0.

I am trying to accomplish DFU over UART with mcumgr serial console in which primary slot will in internal flash of the development kit and secondary slot is in external flash MX66L1G. I am using static configuration for partition region using partition manager. The sample on which I am working is ncs\v2.3.0\zephyr\samples\subsys\mgmt\mcumgr\smp_svr 

Here is my pm_static.yml file and prj.conf 

EMPTY_0:
  address: 0xf000
  end_address: 0x11000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0x2000
app:
  address: 0x11200
  end_address: 0x101000
  region: flash_primary
  size: 0xefe00
mcuboot:
  address: 0x0
  end_address: 0xf000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xf000
mcuboot_pad:
  address: 0x11000
  end_address: 0x11200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary_app:
  address: 0x11200
  end_address: 0x101000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xefe00
  span: *id002
mcuboot_primary:
  address: 0x11000
  end_address: 0x101000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0xf0000
  span: *id001
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xf0000
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xf0000
mcuboot_secondary_app:
  address: 0x0
  end_address: 0xefe00
  orig_span: &id003
  - app
  region: external_flash
  size: 0xefe00
  span: *id003
EMPTY_1:
  address: 0xf0000
  end_address: 0x8000000
  region: external_flash
  size: 0x7f10000
sram_primary:
  address: 0x20000000
  end_address: 0x20020000
  region: sram_primary
  size: 0x20000

# Enable the shell mcumgr transport.
CONFIG_SHELL=y
CONFIG_SHELL_BACKEND_SERIAL=y
CONFIG_MCUMGR_SMP_SHELL=y

# mcumgr-cli application doesn't accepts log in the channel it uses
CONFIG_SHELL_LOG_BACKEND=n

# Enable shell commands.
CONFIG_MCUMGR_CMD_SHELL_MGMT=y

#Enable MCUboot
CONFIG_BOOTLOADER_MCUBOOT=y

# Enable mcumgr.
CONFIG_MCUMGR=y

#Enable flash operations.
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FPROTECT=y

# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y

# Enable logging
CONFIG_LOG=y
CONFIG_MCUBOOT_UTIL_LOG_LEVEL_DBG=y

# Disable debug logging
CONFIG_LOG_MAX_LEVEL=4

# DRivers enabled 
CONFIG_SPI=y

#Place MCUboot secondary in external flash
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

CONFIG_NORDIC_QSPI_NOR=y

# Ensure an MCUboot-compatible binary is generated.
CONFIG_IMG_ERASE_PROGRESSIVELY=y

CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

I have also created mcuboot.conf and mcuboot.overlay

/* Step 3.5 - Configure button and LED for Serial Recovery */

/{
  aliases {
		mcuboot-button0 = &button1;
		mcuboot-led0 = &led1;
    };
};

These are the errors which I am facing while flashing the mcuboot

I am taking reference for DFU over UART from this link of Dev Academy Exercise 1 - DFU over UART - Nordic Developer Academy (nordicsemi.com)

Overlay file for the hardware nrf5340dk_nrf5340dk_cpuapp.overlay

 

Please help me figure out what is missing in this whole configuration and why am I getting these errors and warnings.

[Menon]

Hello,

It seems there might be an issue with image versioning. Could you please let me know how you are configuring the image version in both the application and the bootloader?

Kind regards,

Abhijith

[Radhika-eaton]

Hi,

I am configuring the image version with a config in the prj.conf

CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--version=1.0.0"

It seems like there is an issue with the mcumgr commands compatibility with ncs 2.3.0, because now if I am trying to upload the secondary image in the external flash, image upload is not taking place.

PS C:\ncs\v2.3.0\nrf\tests\modules\mcuboot\external_flash> mcumgr image list --conntype serial --connstring "COM13,baud=115200"
Images:
 image=0 slot=0
    version: 2.0.0
    bootable: true
    flags: active confirmed
    hash: 2dfa0f4e6324f9dc8682cc81fc97bf013ca5396574c26e1669350daad8543ca6
Split status: N/A (0)
PS C:\ncs\v2.3.0\nrf\tests\modules\mcuboot\external_flash> mcumgr -c testDK image upload build_2/zephyr/app_update.bin
 0 B / 63.76 KiB [------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------]   0.00%

I also verified the working of external flash with the nrf sample sdk-nrf/tests/modules/mcuboot/external_flash at main · nrfconnect/sdk-nrf (github.com)

The results were successful

*** Booting Zephyr OS build fcaa60a99fa9 ***
Running TESTSUITE test_mcuboot_external_flash
===================================================================
START - test_external_flash
 PASS - test_external_flash in 0.001 seconds
===================================================================
TESTSUITE test_mcuboot_external_flash succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL

[Radhika-eaton]

Hi, could you please prioritize this ticket? It’s crucial for my project. If you have any questions, don’t hesitate to ask.

[Menon]

Hello,

Sorry for the late response. It's the summer vacation period here in Norway, and the increased workload has caused the delay

While reviewing the prj.config, I noticed that you have enabled serial recovery in the MCUboot configuration. However, from your thread, it seems you are only looking for serial DFU, correct? Please confirm this. The guide I pointed you to works with the newer version of the nRF Connect SDK, but your version is a bit older, which might cause some configuration differences. If possible, I recommend updating your application to the latest version.

The "bootable status false" message indicates that the device will not boot from this image, and "unavailable hash" suggests that the hash of the image in slot 0 is not available. This could be due to an issue with how the image was created, signed, or uploaded. I suspect this issue might be due to improper signing of the image. Are you properly using the image signing with Imgtool? Please refer to the section on Image Signing for guidance.

Also, check the mcumgr configurations you have enabled in the prj.config. I recommend comparing your application with this sample, as it is more relatable to your SDK version. Additionally, check the repository for some bootloader samples with external flash.

Radhika-eaton said:

could you please prioritize this ticket?

I won’t be able to prioritize the ticket, but I will try to respond as soon as possible.

Kind regards,

Abhijith

[Radhika-eaton]

I am trying to achieve the DFU over serial recovery mode where the secondary slot is in external flash. Though I am ok with either method. Now when I tried the sample example of spi flash on the latest ncs version ncs\v2.3.0\zephyr\samples\drivers\spi_flash it says 

*** Booting Zephyr OS build v3.2.99-ncs2 ***
flash_dev->name: MX66L1G
flash_dev->config: 0x73e8
flash_dev->driver_api: 0x7438
flash_dev->status: 536871396
flash_dev->data: 0x20000090
device_is_ready: MX66L1G
device_is_ready: initialized=1, init_res=19
Device initialization failed: No such device
MX66L1G: device not ready.

nRF Connect is giving me the signed image using key based signing MCUBoot bootloader key file: C:/ncs/v2.3.0/bootloader/mcuboot/root-rsa-2048.pem

Note: MX25R64 external flash is working but the other custom external flash MX66L1G is not working with the same configuration.

Please help me resolve the situation.

spi_flash.7z

[Menon]

Hello Radhi,

Thank you confirming the details. 

Radhika-eaton said:

Device initialization failed: No such device
MX66L1G: device not ready.

Double-check the physical connections to ensure the QSPI lines (CLK, CS, DQ0, DQ1, DQ2, DQ3) are correctly connected between the nRF5340 and the MX66L1G. The JEDEC ID in the overlay file should match the actual JEDEC ID of the MX66L1G flash chip. The JEDEC ID provided is [c2 20 1b]. Ensure that this is correct. You might need to refer to the MX66L1G datasheet to verify the JEDEC ID.

I am not sure, but have you cross-checked the sfdp-bfp values inside the overlay with the data sheet of MX66L1G?

Kind Regards,

Abhijith

[Radhika-eaton]

Hi Abhijith,

I will check the physical connections with the help of logic analyzer. The JEDEC ID in the overlay file are correct confirmed from the datasheet. 

I am unable to cross-check the sfdp-bfp values inside the overlay file from the datasheet, can you please guide me in this on how to create and identify these values from the flash parameter table.

MX66L1G45G.PDF

Thank you so much.

Regards,
Radhika