Flash area error while doing DFU using nRF Connect

[Krishnachandran_a]

Dear support team,

I am getting an error while performing DFU using nRF Connect.

[00:02:39.702,697] <inf> mcuboot_util: Swap type: none
[00:02:39.702,972] <err> mcumgr_img_grp: Failed to open flash area ID 1: -2

My SDK version is 2.4.2, I need to do DFU using BLE simultaneously, for that i tried to modify Example mcuboot_smp_ble_simultaneous , but without modifying anything, while performing DFU by compiling this code i am getting this error, Even after getting this error new imaged is flashed successfully after DFU. i don't know the reason. my complete serial log is attached bellow. 

D: RDSR 40 QE 1 need 1: no-change
I: Starting bootloader
I: Swap type: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build 28a3fca7da5c ***
Change this to see it change.
[00:00:00.030,853] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.030,883] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.030,914] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
[00:00:00.032,623] <inf> bt_hci_core: Identity: C5:DB:0C:FE:67:B3 (random)
[00:00:00.032,653] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x2077, manufacturer 0x0059
[00:00:00.032,653] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x2077
Bluetooth initialized
Advertising successfully started
[00:02:39.702,697] <inf> mcuboot_util: Swap type: none
[00:02:39.702,972] <err> mcumgr_img_grp: Failed to open flash area ID 1: -2
[00:02:39.978,576] <inf> mcuboot_util: Swap type: none
D: RDSR 40 QE 1 need 1: no-change
I: Starting bootloader
I: Swap type: perm
I: Swap type: perm
I: Image upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Copying the secondary slot to the primary slot: 0x1af50 bytes
D: writing magic; fa_id=4 off=0xf3ff0 (0xffff0)
D: erasing secondary header
D: erasing secondary trailer
I: Image upgrade secondary slot -> primary slot
I: Erasing the primary slot
I: Copying the secondary slot to the primary slot: 0x2e8d4 bytes
D: writing magic; fa_id=1 off=0x3fff0 (0x3fff0)
I: Turned on network core
I: Turned off network core
D: erasing secondary header
D: erasing secondary trailer
I: Bootloader chainload address offset: 0xc000
ÿ*** Booting Zephyr OS build 28a3fca7da5c ***
Krishnachandran_Test....
[00:00:00.030,883] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.030,914] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.030,944] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 224.11902 Build 2231721665
[00:00:00.032,653] <inf> bt_hci_core: Identity: C5:DB:0C:FE:67:B3 (random)
[00:00:00.032,684] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x2077, manufacturer 0x0059
[00:00:00.032,684] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x2077
Bluetooth initialized
Advertising successfully started

If any idea regarding this, please help. Thanks in advance.

[Sigurd Hellesvik]

Hi,

Which target board do you build for?

Regards,
Sigurd Hellesvik

[Krishnachandran_a]

nRf5340

[Sigurd Hellesvik]

Do you build for

nrf5340dk_nrf5340_cpuapp,
nrf5340dk_nrf5340_cpuapp_ns

or something else?

[Krishnachandran_a]

Bulid for nrf5340dk_nrf5340_cpuapp

thanks.

[Geir Strand]

We have seen this as well. We do believe that this is because mcumgr is trying to read the net core flash, which is not available from the app core. Sigurd Hellesvik - this might be that the development team has forgotten about nRF5340 and dual core?

[Krishnachandran_a]

Update ..1

Our goal is to perform DFU_OTA using internal flash; we prefer not to utilize nrf5340dk. Additionally, we are employing a pm_static.yml as follows. However, after providing this configuration, we are encountering the same error

app:
  address: 0x10200
  end_address: 0x66000
  region: flash_primary
  size: 0x55E00
mcuboot:
  address: 0x0
  end_address: 0x10000
  region: flash_primary
  size: 0x10000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x66000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x56000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x66000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x55E00
  span: *id002
mcuboot_secondary:
  address: 0x66000
  end_address: 0xBC000
  size: 0x56000
mcuboot_secondary_1:
  address: 0xBC000
  end_address: 0xFC000
  size: 0x40000
otp:
  address: 0xff8100
  end_address: 0xff83fc
  region: otp
  size: 0x2fc
pcd_sram:
  address: 0x20000000
  end_address: 0x20002000
  region: sram_primary
  size: 0x2000
ram_flash:
  address: 0x40000
  end_address: 0x40000
  region: ram_flash
  size: 0x0
rpmsg_nrf53_sram:
  address: 0x20070000
  end_address: 0x20080000
  placement:
    before:
    - end
  region: sram_primary
  size: 0x10000
settings_storage:
  address: 0xFC000
  end_address: 0x100000
  region: flash_primary
  size: 0x4000
sram_primary:
  address: 0x20002000
  end_address: 0x20070000
  region: sram_primary
  size: 0x6e000
mcuboot_primary_1:
  address: 0x0
  size: 0x40000
  device: flash_ctrl
  region: ram_flash

[Sigurd Hellesvik]

When you DFU the dfu_application.zip from the mobile app, which mode do you choose?

Krishnachandran_a said:

Additionally, we are employing a pm_static.yml as follows. However, after providing this configuration, we are encountering the same error

This means that you see the same error both with and without pm_static.yml, right?
Why exactly do you want to add pm_static.yml now? I usually recommend not using static partitioning when developing, but waiting to when you are soon ready to release, then test with static partitioning. Static partitioning is after all  mostly used to make sure that partitioning does not change.

Krishnachandran_a said:

Our goal is to perform DFU_OTA using internal flash;

Have you started configuring to use internal flash yet?
Do you see the same error for both internal and external flash configurations?

Hi Geir, thanks for saying you have seen the same. Did you create a devzone ticket when you saw the issue?
Which SDK version did you see the issue for?

Geir Strand said:

We do believe that this is because mcumgr is trying to read the net core flash, which is not available from the app core.

MCUmgr does not know that the slot is in net core flash. Instead, it thinks that the slot is in RAM.  However, it not impossible that might lead to  similar behavior.

[Krishnachandran_a]

Hi, 

Sigurd Hellesvik said:

When you DFU the dfu_application.zip from the mobile app, which mode do you choose?

We are using "Test and Confirm" mode.

Sigurd Hellesvik said:

This means that you see the same error both with and without pm_static.yml, right?

Yes, right.

Sigurd Hellesvik said:

Why exactly do you want to add pm_static.yml now?

Our aim is to perform DFU without using External flash, hence we tried both ie, with and without pm_static.yml

Sigurd Hellesvik said:

Have you started configuring to use internal flash yet?

Actually No.(Custom board we are not using external flash), we didn't  find specific example or configuration to use internal flash. , we tried to remove bellow mentioned code from overlay file. that time we are getting compilation error.  If there is an example tailored for internal flash, we would be grateful for your assistance in sharing it with us.

/ {

    chosen {

        nordic,pm-ext-flash = &mx25r64;

    };

};