mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Mon, 09 Feb 2026 14:18:34 GMT

Hello,

The DFU error message you’re seeing is not caused by the bootable: false flag. The bootable field is simply a flag in the image state response that indicates whether the image has the bootable flag set. See the section state of images.

If you look at the Academy sample for serial recovery, you’ll also notice that it shows bootable: false for the image in slot 0, and the image is still valid for serial recovery DFU testing.

I still doubt if this could be because of partition manager configuration. The main question is why it fails on only one board while it works on the others.

Kind regards,
Abhijith

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Tue, 03 Feb 2026 20:52:21 GMT

Partway through this troubleshooting, I started using this as an indicator for "Is it good or not?" because it seemed to simplify things:

I do "image list" with mcumgr and look to see if it says the image in slot0 is bootable. Every time, it says false. I understood that as indicative of the problem. But apparently, these images can actually boot despite what it says, because I can hit the reset key after uploading an image and having it say its not bootable, and the firmware comes up. Why is that? I wonder if this has led me down the wrong path with my troubleshooting.

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Fri, 30 Jan 2026 20:02:20 GMT

Thanks Abhijith. Here's what I did and the results:

I took the partition file you attached on your last post and used it for my pm_static.yml, after renaming the old pm_static.yml.
Did a pristine build.
Boot my board in bootloader mode.
Uploaded the newly-generated app_update.bin to the bootloader via serial with mcumgr
Asked for a list of images from mcumgr (mcumgr --conntype serial --connstring "dev=COM6,baud=115200" image list)
It says that the image is not bootable, which is the same as before.

Then I think, "Maybe the problem is the image that was already on there." I re-flashed the board using nrfjprog, before uploading the image to the bootloader again, repeating the steps above. So what I did was upload an image that is the same thing as the existing firmware already running on the board. At the end of this sequence, I checked again, and again it says that the image on the board is not bootable:

This firmware, when flashed to the board, works fine. There is nothing wrong with the firmware itself. But the bin being generated by NCS is refused by the bootloader. It has been pretty consistent about this since I've been using mcumgr to do testing. I just can't figure out what is making this bin invalid.

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Fri, 30 Jan 2026 13:30:23 GMT

Hello,

Yes, that’s correct, an erase or recover operation will also clear the bootloader. Could you please try using the partition manager file below and see if that resolves the issue?

I don’t have the exact board you’re using, so reproducing this issue on my side is a bit difficult. Please give this a try and let me know how it goes. If it doesn’t help, I can try testing it on an nRF52840 DK.

app:
  address: 0xc200
  end_address: 0x0ff000
  region: flash_primary
  size: 0xf2e00


mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
      - mcuboot_primary
  region: flash_primary
  size: 0xc000


mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
      - mcuboot_primary_app
  region: flash_primary
  size: 0x200

mcuboot_primary:
  address: 0xc000
  end_address: 0x0ff000
  region: flash_primary
  size: 0xf3000
  span:
    - mcuboot_pad
    - app

mcuboot_primary_app:
  address: 0xc200
  end_address: 0x0ff000
  region: flash_primary
  size: 0xf2e00
  span:
    - app

sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Kind Regards,

Abhijith

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Thu, 29 Jan 2026 14:58:29 GMT

Thanks Abhijith.

I think that if I perform an erase operation, that will clear all of the onboard flash, right? That includes the bootloader. So after the erase, I wouldn't be able to get it into bootloader mode to accept a DFU. Not sure what is the best move from here.

Scott

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Thu, 29 Jan 2026 14:37:06 GMT

Hello,

I needed to look into another issue, which caused a slight delay in getting back to you.

I reviewed your partition file and don’t see any obvious issues there. As a test, could you please try erasing the flash before performing the DFU and check whether you see the same result? You can try running nrfutil device erase or nrfutil device recover first, and then let me know if it's throwing the same issue.

[quote user="cscase"]Because of schedule demands, I could only do that if there were no other way to resolve this issue and we were pretty confident that would do the trick. If you think that is the case, let me know.[/quote]

Also, if you are close to delivery, I wouldn’t recommend porting at this stage, as moving to sysbuild (introduced in NCS v2.7.0 and later) is a major change and can take a significant amount of time.

Kind Regards,

Abhijith

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Tue, 27 Jan 2026 16:13:25 GMT

Hi,

I was able to get RTT output by using the Segger RTT viewer, as you suggest above. The output from that is in my post above. The RTT log doesn't say much that seems helpful, unfortunately, but the RTT is working now if we need to use it.

You are also correct about sysbuilld - my version of NCS does not use it. I think if I upgrade to a newer SDK I would spend weeks troubleshooting problems and making it work again. That's not a trivial change, right? Or could I upgrade without breaking changes? Because of schedule demands, I could only do that if there were no other way to resolve this issue and we were pretty confident that would do the trick. If you think that is the case, let me know.

I will attach here the pm_static and the child_image/mcuboot.conf, as well as the overlay and prj.confdevzone.nordicsemi.com/.../5857.prj.conf.txt

devzone.nordicsemi.com/.../4452.pm_5F00_static.yml.txt devzone.nordicsemi.com/.../0243.mcuboot.conf

devzone.nordicsemi.com/.../mcuboot.overlay.txt

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Tue, 27 Jan 2026 09:58:16 GMT

Hello,

I am not sure why RTT logs are not working for you. I am attaching a sample with minimal config to enable the RTT logs. Please check the prj.config and sysbuil/mcuboot.confg.

I believe you are not using sysbuild (as you are on NCSv2.6.x), hence check the mcuboot.conf under your child_image/mcuboot.conf folder. I also recommend using the Jlink RTT viewer to see the logs via RTT.

Can you share the pm_static file as well , so that I can take a look? And if possible please update the SDK to latest available, as the SDK you are using is quite old.

devzone.nordicsemi.com/.../OTA_5F00_MCUBOOTLOGS_5F00_RTT.zip

Kind Regards,
Abhijith

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Fri, 23 Jan 2026 14:46:03 GMT

Right, I get that, but I mention it because it lets us know what key is being used for this build.

I found that although there appears to be no way to view it from within nRF Connect, I can see mcuboot's output using the Segger RTT viewer. I uploaded the bin but the log doesn't show any errors. Here's the last bit where it finishes uploading:

00> I: Writing at 0x30a84 until 0x30bd4
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: Writing at 0x30bd4 until 0x30d24
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: Writing at 0x30d24 until 0x30e74
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: Writing at 0x30e74 until 0x30fc4
00> I: RX: 0x0
00> I: TX
00> I: RX: 0x0
00> I: TX
00> I: Erasing range 0x%jx:0x%jx
00> I: Writing at 0x30fc4 until 0x31088
00> I: Erasing range 0x%jx:0x%jx
00> I: RX: 0x0
00> I: TX
00> I: TX

At the end there is where I sent the "image list" command from mcumgr, and the RTT says TX TX.

From my cmd window, here's the mcumgr output where I uploaded the file and then checked to see if the image is bootable:

PS C:\users\scase> mcumgr --conntype serial --connstring "dev=COM6,baud=115200" image upload app_update.bin
 196.13 KiB / 196.13 KiB [======================================================================] 100.00% 788 B/s 4m14s
Done
PS C:\users\scase> mcumgr --conntype serial --connstring "dev=COM6,baud=115200" image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: false
    flags:
    hash: 88c94b0d46cdcc25ebadbdb9a13757fee9ef7604ebbbeca5611ea15730384b17
Split status: N/A (0)
PS C:\users\scase>

One possible reason, I read online, that the image might not be considered valid, would be if it is larger than the available space partitioned for the slot. But this image - in hex format, which is uncompressed I'm pretty sure - is 659 kb. You can see in the pm_static that we have almost a megabyte available for slot0.

How can I determine what causes the image to be considered invalid or non-bootable?

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Fri, 23 Jan 2026 14:04:56 GMT

[quote user="cscase"]I think that because I am trying to flash the same build that is already on the board, that means it must have the same signature for both, right? I see the warning that says "Using the default MCUBoot key, it should not be used for production" whenever I build.[/quote]

That is an expected warning message when using the default key and does not indicate any issue.

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Thu, 22 Jan 2026 22:48:44 GMT

Hi,

I've enabled RTT in the prj.conf for mcuboot. A couple of things: When I added that, I got an error saying that a dependency was missing. It wanted LOG_MODE_MINIMAL, so I added that as well.

When it starts up now, I see this message at the bottom-right of VSCode:

Element with id 504500724 is already registered

(This number is the serial # for my JLink.)

And where previously, I could expand the J-link item under "Connected Devices" and see RTT, I don't see that now. Expanding this item shows nothing nested under it:

When I boot the app as normal, I still see serial output from USB serial. When I start the bootloader, the COM port disappears. In either case, though, I see nothing any more aobut RTT under the programmer in nRF Connect's lower-left pane.

I haven't used RTT and have been using the USB serial for debugging on this project, so I apologize for not having it running more easily here.

Regarding the signatures:

I've been trying something different here and just trying to bootload the exact same image that the board is programmed with. I do the following:

Flash the board with NCS
Manually put it in bootloader mode
Upload the app_update.bin for the same build that I just flashed to the board, directly from \build\zephyr\.

It shows this image as not bootable.

I think that because I am trying to flash the same build that is already on the board, that means it must have the same signature for both, right? I see the warning that says "Using the default MCUBoot key, it should not be used for production" whenever I build.

I was working on this today and I used imgtool to use the private key from the mcuboot source directory to get the public key.

Here's my prj.conf from the child project for reference. You can see where I added the RTT enable options.

CONFIG_PM=n

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

CONFIG_BOOT_SWAP_SAVE_ENCTLV=n
CONFIG_BOOT_ENCRYPT_IMAGE=n

CONFIG_BOOT_UPGRADE_ONLY=n
CONFIG_BOOT_BOOTSTRAP=n

### mbedTLS has its own heap
# CONFIG_HEAP_MEM_POOL_SIZE is not set

### We never want Zephyr's copy of tinycrypt.  If tinycrypt is needed,
### MCUboot has its own copy in tree.
# CONFIG_TINYCRYPT is not set
# CONFIG_TINYCRYPT_ECC_DSA is not set
# CONFIG_TINYCRYPT_SHA256 is not set

CONFIG_FLASH=y
CONFIG_FPROTECT=y

### Various Zephyr boards enable features that we don't want.
# CONFIG_BT is not set
# CONFIG_BT_CTLR is not set
# CONFIG_I2C is not set

CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
### Ensure Zephyr logging changes don't use more resources
CONFIG_LOG_DEFAULT_LEVEL=0
### Use info log level by default
CONFIG_MCUBOOT_LOG_LEVEL_INF=y
### Decrease footprint by ~4 KB in comparison to CBPRINTF_COMPLETE=y
CONFIG_CBPRINTF_NANO=y
### Use the minimal C library to reduce flash usage
CONFIG_MINIMAL_LIBC=y
CONFIG_NRF_RTC_TIMER_USER_CHAN_COUNT=0

### FROM FORUM POST
# Enable Zephyr logging
CONFIG_LOG=y
# Enable RTT as logging backend
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_MODE_MINIMAL=y
CONFIG_LOG_BACKEND_RTT=y
#Disable UART logging backend/console
CONFIG_LOG_BACKEND_UART=n
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Thu, 22 Jan 2026 19:57:19 GMT

Hello,

[quote user="cscase"]How can I get the bootloader logging to an interface where I'll be able to see it? When mcuboot is active, I don't currently have the USB CDC interface. It has uart0, but I don't think I can log to there because that's the interface being used by mcumgr when I'm testing, or by the outboard device providing the new firmware image. What's the best way for me to approach?[/quote]

Could you please try collecting the logs via RTT? You can enable the following configurations in the prj.conf file and then check the logs using J-Link RTT Viewer or VS Code.

Enable Zephyr logging
CONFIG_LOG=y
# Enable RTT as logging backend
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
#Disable UART logging backend/console
CONFIG_LOG_BACKEND_UART=n
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n

It’s a bit strange that the same application works fine on the other two boards but shows an issue on only one board. Could you please verify that this is not caused by a signing key mismatch between MCUboot and the application image?

Kind Regards,

Abhijith

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

cscase — Wed, 21 Jan 2026 18:29:22 GMT

Thanks Abhijith.

How can I get the bootloader logging to an interface where I'll be able to see it? When mcuboot is active, I don't currently have the USB CDC interface. It has uart0, but I don't think I can log to there because that's the interface being used by mcumgr when I'm testing, or by the outboard device providing the new firmware image. What's the best way for me to approach?

To simplify troubleshooting, I just connected to the bootloader directly with mcumgr and uploaded an image. I did a pristine build and pulled the app_update.bin file from \build\zephyr\ and uploaded that to mcuboot. Afterward, I did "image list" and it lists the image in the slot as being not bootable. If I understand correctly, that means mcuboot is saying this is not a valid, workable firmware image. It just doesn't tell me why, or what the problem is with the image. And despite this, if I use nrfjprog to flash this app to a board, it runs just fine.

Scott

RE: mcuboot images intermittently failing to apply -- DFU image is not valid 9(0)

Menon — Tue, 20 Jan 2026 08:22:05 GMT

Hello,

Thank you for explaining this in detail. I see that you have enabled logging; could you please also enable the MCUboot logs by setting CONFIG_MCUBOOT_LOG_LEVEL_INF, and then share the logs here?

Kind Regards,

Abhijith