# Outboard DFU woes: "DFU image is not valid 9(0) {odfu-fail}"

**URL:** <https://discuss.blues.com/t/outboard-dfu-woes-dfu-image-is-not-valid-9-0-odfu-fail/3384>\
**Category:** Troubleshooting\
**Created:** [November 18, 2025, 10:45pm UTC](https://discuss.blues.com/t/outboard-dfu-woes-dfu-image-is-not-valid-9-0-odfu-fail/3384 "2025-11-18T22:45:23Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![scase](https://avatars.discourse-cdn.com/v4/letter/s/5daacb/32.png) [@scase](https://discuss.blues.com/u/scase)\
**Post date:** [November 18, 2025, 10:45pm UTC](https://discuss.blues.com/t/outboard-dfu-woes-dfu-image-is-not-valid-9-0-odfu-fail/3384/1 "2025-11-18T22:45:23Z")

</div>

Hi all,

I’m running into troubles using outboard DFU. I have used it successfully up until now, and in fact I can still use it successfully with previous binpacks.

I made an update to our firmware, which runs on an nRF52840 Feather Express, using mcuboot bootloader. Previous firmware releases I can install via this method just fine. And the new firmware works great if I flash it via SWD, but if I try to get Notehub to push the binpack out, it will try for more than an hour, holding the host micro in bootloader mode for most of that time, then eventually fail with the error message:

`“DFU image is not valid 9(0) {odfu-fail}”`

After this failure, the host MCU is left in a non-functional state, its flash corrupted. I can get it working again by asking Notehub to DFU it back to a previous version of the firmware and then power cycling the board.

I recently upgraded Notecard CLI from 1.8.1 to 1.9.1, and I wondered if that might be the source of the trouble, so I produced binpacks with both of them, and comparison shows they are identical, save only the timestamp, so I don’t think it’s the Notecard CLI’s fault.

This is the command I use to generate the binpacks:

`notecard -binpack mcuboot 0x00000000:app_update.bin`

If file size is relevant: The new binpack I’m trying to flash is 185 kb. The previous one (which still works) is 157 kb.

The Notecard has DFU turned on with this command:  
`{`  
`“req”: “card.dfu”,`  
`“name”: “mcuboot”,`  
`“on”: true`  
`}`

Here’s the response to a card.dfu inquiry:

```auto
> {"req":"card.dfu"}

```

```auto
{
 "mode": "aux",
 "name": "mcuboot"
}

```

I can also confirm that the Notecard is able to successfully put the host into bootloader mode, as evidenced by a red LED (and the fact that it is able to corrupt the existing firmware in this attempt).

So, I have a valid hex that runs as intended on the device if I flash it manually. I just can’t get it on there via the DFU mechanism. Yet I CAN flash other files just fine, binpacks that were produced with the same process and CLI command. Does the error message above indicate what is objectionable about the binpack in question? Any ideas?

I’m going to have to think on this one overnight.

Thanks for any ideas or suggestions!

Scott

---

<div class="post-metadata">

**Author:** ![scase](https://avatars.discourse-cdn.com/v4/letter/s/5daacb/32.png) [@scase](https://discuss.blues.com/u/scase)\
**Post date:** [November 19, 2025, 10:38pm UTC](https://discuss.blues.com/t/outboard-dfu-woes-dfu-image-is-not-valid-9-0-odfu-fail/3384/3 "2025-11-19T22:38:49Z")

</div>

I looked at the trace output from the Notecard and I’m not sure this really reveals much more than the error above, but here’s the error surrounding lines:

`S10:02.25 loader: loaded bin 0x0002df00 off 188160 len 00000256 (325/256/69 remaining)`  
`S10:02.25 loader: processing bin off 188160 (325/256/69 remaining)`  
`S10:02.26 loader: writing flash for bin from 0x0002df00 len 0x00000100`  
`S10:03.05 loader: loaded bin 0x0002e000 off 188416 len 00000256 (69/0/69 remaining)`  
`S10:03.05 loader: reading source offset 0x0002e000 len 0x00000045 leaving 0x00000000 remaining`  
`S10:03.09 loader: processing bin off 188416 (69/69/0 remaining)`  
`S10:03.09 loader: writing flash for bin from 0x0002e000 len 0x00000045`  
`S10:03.96 loader: loaded bin 0x0002e045 off 188485 len 00000069 (0/0/0 remaining)`  
`S10:04.11 loader: programming error: DFU image is not valid 9(0)`  
`S10:04.25 _health.qo: outboard DFU of mcuboot firmware: DFU image is not valid 9(0)`  
`S10:04.26 dfu: disabled DFU mode`  
`S10:04.26 sync: wakeup: dfu disabled`  
`S10:04.26 dfu: cannot update host: DFU image is not valid 9(0) {odfu-fail}`  
`S10:04.27 dfu: retry #1`  
`S10:04.27 sync: wakeup: card firmware update error`  
`S10:04.29 usage data: mem:4848 nvm:4816 nvm-area:8192`  
`S10:04.29 sync: connect requested by first sync (DATA)`  
`S10:04.37 ### RESTART (4.92V 28.44C) brown-out & hard reset [17285]`  
`S10:04.38 apn: for ``a.notefile.net`` using apn a-notehub.com.attz`  
`S10:04.38 sync: wireless: domain ``a.notefile.net`` using APN a-notehub.com.attz`  
`S10:04.39 sync: wireless: starting communications {wait-module} {connecting} {transport}`

---

<div class="post-metadata">

**Author:** ![RobLauer](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.blues.com/roblauer/32/1567_2.png) [@RobLauer](https://discuss.blues.com/u/RobLauer)\
**Post date:** [November 20, 2025, 7:49pm UTC](https://discuss.blues.com/t/outboard-dfu-woes-dfu-image-is-not-valid-9-0-odfu-fail/3384/4 "2025-11-20T19:49:49Z")

</div>

Hi @scase,

This _looks_ like an mcuboot issue and not a Notecard issue, so let’s check that first. I don’t have an nRF52840 on me, but I think the first thing we should try is to:

Put the nRF52840 Feather into MCUboot manually, connect over serial, and run:

```auto
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM0,baud=115200" image list

```

You should see at least one image entry with a `slot` field.

If that works, try upload the same `app_update.bin` you used:

```auto
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM0,baud=115200" image upload app_update.bin

```

…and then again…

```auto
mcumgr --conntype=serial --connstring="dev=/dev/ttyACM0,baud=115200" image list

```

If after upload the `image list` output is empty or doesn’t show the new image, that should prove it’s either an mcuboot issue or an issue with the image itself.

Rob

---

<div class="post-metadata">

**Author:** ![scase](https://avatars.discourse-cdn.com/v4/letter/s/5daacb/32.png) [@scase](https://discuss.blues.com/u/scase)\
**Post date:** [November 21, 2025, 4:55pm UTC](https://discuss.blues.com/t/outboard-dfu-woes-dfu-image-is-not-valid-9-0-odfu-fail/3384/5 "2025-11-21T16:55:10Z")

</div>

I think you were spot on here. I believe I found a problem with my mcuboot config that is responsible for the problem. Thanks once again for your help!

Scott