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]

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;

    };

};

[Sigurd Hellesvik]

Krishnachandran_a said:

We are using "Test and Confirm" mode.

I suspect that the error you get are related to the operations done by this.
Do you see the same error if you use "Confirm only"? Since Simultaneous multi-image DFU does not support reverting, it is no need to use "test" either way.

Krishnachandran_a said:

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;

    };

};

I suggest that you eliminate this error with external flash first, and then move on to internal flash.

I know we have a custom sample (zip file) for internal flash FOTA for the nRF5340 somewhere, I just need to find it first. I think it should be in a public ticket somewhere.

[Krishnachandran_a]

Hi, 

Thanks for the update.

Sigurd Hellesvik said:

Do you see the same error if you use "Confirm only"?

Tried both methods, and in both methods we are getting the same error.

[KjellArne Amina]

I had a private post but was asked to continue the discussion here.

We see the same behavior, the error prints both with "Test & Confirm" as well as "Confirm Only". The update is successful.

We were suspicious that the DFU process tried to query the active net core slot. This was because a call to boot_read_bank_header() with the PM_mcuboot_primary_1_ID slot (slot 1 for our device) gives the same return code, but it seems to be unrelated.

I looked for the source of the error message and it seems to be an unintended consequence of handling the state of the device.

img_mgmt_state_write()   in img_mgmt_state.c
    - Seems like the function tries to fetch the current image state
    as a respons to the img_mgmt_state_write() smp command/function call

img_mgmt_state_read()    in img_mgmt_state.c
    - Iterates through the first updatable_imgage_number*2 slots, so 4
    for our device

img_mgmt_read_info()     in img_mgmt.c

img_mgmt_erased_val()    in zephyr_img_mgmt.c
    - Prints the error message


We are using nRF Connect SDK 2.4.1

Best regards
Kjell Arne

[Sigurd Hellesvik]

I am trying to reproduce this, with v2.4.2, the nRF5340DK and my Simultaneous DFU for app and net core of nRF5340 sample.

I get the following log from the application core:

: 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 v3.3.99-ncs1-1 ***
Change this to see it change.
Bluetooth initialized
Advertising successfully started
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: 0x152cc 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: 0x304ac 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 nRF Connect SDK v2.5.0 ***
BBB this to see it change.
Bluetooth initialized
Advertising successfully started

In which I can not see the error you see.

That means something is different here. I think finding the difference might help us figure out what is happening.

Can you see any differences?
Do you see the same error with my sample?
Do you use custom hardware?

[Krishnachandran_a]

Sigurd Hellesvik said:

Do you see the same error with my sample?

Yes,  Could you please enable Log and try. ie. CONFIG_LOG=y in project config file.

thanks

[KjellArne Amina]

Hi Sigurd,
I have not had a chance to run the sample yet, but have a comment. It seems the log in your post is from power on. The error message shows itself, at least in our case, when uploading a new image. Note that the DFU completes successfully, but we get some support cases and confusion from users.

We see the same behavior with nRF Connect, nRF Connect Device Manager and mynewt-mcumgr-cli

Thanks for the sample, it's always a good idea to eliminate what we can.

[Sigurd Hellesvik]

KjellArne Amina said:

I have not had a chance to run the sample yet, but have a comment. It seems the log in your post is from power on. The error message shows itself, at least in our case, when uploading a new image. Note that the DFU completes successfully, but we get some support cases and confusion from users.

Krish has got the difference. I just have not enabled logging in my application, so the mcumgr module does not complain visibly.

Then I will see the same I suspect.

I will do that next week and look into what this is.

Note: Since DFU still works this is not my top priority, but I will do it.

[Krishnachandran_a]

Hi,

Regards for the update. In this case, we still have one more question. Specifically, the following workaround is present in the overlay file.

/ {
    chosen {
        nordic,pm-ext-flash = &mx25r64;
    };
};

When compiling without this, we encounter compilation errors. The code for the nRF5340DK is functioning properly with this. Consequently, will you kindly provide some light on this?

I am grateful for your support. Regards in advance.