Flash area error while doing DFU using nRF Connect

RE: Flash area error while doing DFU using nRF Connect

AlejandroM — Tue, 27 May 2025 20:30:35 GMT

This is still an issue in SDK 2.9.0, when you try to do an mcumgr image list or upload any FW, but it does not affect it's functionality.

It is worth mentioning, that in some smaller firmware adding the flash_sim.overlay for the application with low memory consumption gets rid of the message, but in applications that consume more RAM, the message still appears:

GW [15:40:55.824,859] <inf> [mcumgr smp] mcuboot_util: Image index: 0, Swap type: none
GW [15:40:55.825,195] <inf> [mcumgr smp] mcuboot_util: Image index: 1, Swap type: none
GW [15:40:55.825,195] <err> [mcumgr smp] mcumgr_img_grp: Failed to open flash area ID 3: -2
GW [17:16:41.167,358] <inf> [mcumgr smp] mcuboot_util: Image index: 1, Swap type: none
GW [17:16:43.895,568] <inf> [mcumgr smp] mcumgr_img_grp: Erased 0x36000 bytes of image slot
GW [17:16:43.986,389] <inf> [mcumgr smp] mcumgr_img_grp: Erased 0x1000 bytes of image slot trailer

The rest of the update works fine for both App and Net Core, but the error is off-putting.

And even trying to build bigger consumption memory application won't build and fail with:

c:/ncs/toolchains/b620d30767/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: zephyr\zephyr_pre0.elf section `noinit' will not fit in region `RAM'
c:/ncs/toolchains/b620d30767/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `RAM' overflowed by 84764 bytes
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Mon, 12 Aug 2024 12:52:27 GMT

Nothing yet, no

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Thu, 08 Aug 2024 06:49:49 GMT

is there any solution to exclude these workaround from code.?

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Thu, 15 Feb 2024 14:40:16 GMT

[quote user="KjellArne"]We would appreciate a ticket to remove the incorrect error message in a future nrf connect sdk release
[/quote]

I have now created an internal ticket.

RE: Flash area error while doing DFU using nRF Connect

KjellArne Amina — Thu, 15 Feb 2024 10:48:52 GMT

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

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Tue, 13 Feb 2024 14:42:24 GMT

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.

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Tue, 13 Feb 2024 14:17:20 GMT

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!

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Tue, 13 Feb 2024 05:36:52 GMT

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.

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Fri, 09 Feb 2024 16:33:07 GMT

[quote user="KjellArne"]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.[/quote]

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.

RE: Flash area error while doing DFU using nRF Connect

KjellArne Amina — Fri, 09 Feb 2024 08:39:16 GMT

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.

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Fri, 09 Feb 2024 03:22:51 GMT

[quote userid="106736" url="~/f/nordic-q-a/108054/flash-area-error-while-doing-dfu-using-nrf-connect/468117"]Do you see the same error with my sample?[/quote]

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

thanks

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Thu, 08 Feb 2024 16:50:32 GMT

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?

RE: Flash area error while doing DFU using nRF Connect

KjellArne Amina — Thu, 08 Feb 2024 10:34:51 GMT

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 callimg_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

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Wed, 07 Feb 2024 09:12:19 GMT

Hi,

Thanks for the update.

[quote userid="106736" url="~/f/nordic-q-a/108054/flash-area-error-while-doing-dfu-using-nrf-connect/467861"]Do you see the same error if you use "Confirm only"?[/quote]

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

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Wed, 07 Feb 2024 09:02:17 GMT

[quote user="Krishnachandran_a"]We are using "Test and Confirm" mode.[/quote]

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.

[quote user="Krishnachandran_a"]

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;

};

[/quote]

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.

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Wed, 07 Feb 2024 05:01:33 GMT

Hi,

[quote userid="106736" url="~/f/nordic-q-a/108054/flash-area-error-while-doing-dfu-using-nrf-connect/467732"]When you DFU the dfu_application.zip from the mobile app, which mode do you choose?[/quote]

We are using "Test and Confirm" mode.

[quote userid="106736" url="~/f/nordic-q-a/108054/flash-area-error-while-doing-dfu-using-nrf-connect/467732"]This means that you see the same error both with and without pm_static.yml, right?[/quote]

Yes, right.

[quote userid="106736" url="~/f/nordic-q-a/108054/flash-area-error-while-doing-dfu-using-nrf-connect/467732"]Why exactly do you want to add pm_static.yml now?[/quote]

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

[quote userid="106736" url="~/f/nordic-q-a/108054/flash-area-error-while-doing-dfu-using-nrf-connect/467732"]Have you started configuring to use internal flash yet?[/quote]

/ {

chosen {

nordic,pm-ext-flash = &mx25r64;

};

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Tue, 06 Feb 2024 12:01:30 GMT

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

[quote user="Krishnachandran_a"]Additionally, we are employing a pm_static.yml as follows. However, after providing this configuration, we are encountering the same error[/quote]

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.

[quote user="Krishnachandran_a"]Our goal is to perform DFU_OTA using internal flash;[/quote]

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?

[quote user="Geir Strand"] We do believe that this is because mcumgr is trying to read the net core flash, which is not available from the app core.[/quote]

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.

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Tue, 06 Feb 2024 09:19:22 GMT

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

RE: Flash area error while doing DFU using nRF Connect

Geir Strand — Tue, 06 Feb 2024 08:36:44 GMT

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?

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Tue, 06 Feb 2024 07:10:33 GMT

Bulid for nrf5340dk_nrf5340_cpuapp

thanks.

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Tue, 06 Feb 2024 07:07:48 GMT

Do you build for

nrf5340dk_nrf5340_cpuapp,
nrf5340dk_nrf5340_cpuapp_ns

or something else?

RE: Flash area error while doing DFU using nRF Connect

Krishnachandran_a — Mon, 05 Feb 2024 16:30:08 GMT

nRf5340

RE: Flash area error while doing DFU using nRF Connect

Sigurd Hellesvik — Mon, 05 Feb 2024 12:46:39 GMT

Hi,

Which target board do you build for?

Regards,
Sigurd Hellesvik