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

[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.

[Sigurd Hellesvik]

Let's keep this ticket for the "Failed to open flash area ID 1: -2" error specifically.

If you face other build errors, please create a new ticket.
This will help us keep Devzone tidy. Thanks!

[Sigurd Hellesvik]

I ran the example myself now, and I saw the same error: "Failed to open flash area ID 1: -2".

Digging into the error code, the error is that the mcumgr drivers try to open mcuboot_primary_1, which is in simulated RAM-flash. And this can not be opened as such.

When we upload a new image with the app, the upload button will trigger multiple SMP Command being sent to the nRF. Among these is the image state command.
With this, the nRF tries to return information about all images to the phone.
Since the nRF cannot read the RAM-flash, as this is a "trick" we use to update the network core, it will return an error.

This should not interfere in your DFU from what I can see.

[KjellArne Amina]

Hi Sigurd,
Good of you to confirm our suspicions. As we said, the DFU works so it does not block our progress. However, it is generating some support requests for our product, when customers and testers think that there is an issue with the firmware update.

We would appreciate a ticket to remove the incorrect error message in a future nrf connect sdk release

Best regrards
Kjell Arne

[Sigurd Hellesvik]

KjellArne Amina said:

We would appreciate a ticket to remove the incorrect error message in a future nrf connect sdk release

I have now created an internal ticket.