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

Troubleshooting
1

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:

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

{
 "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

1 Like
3

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}

4

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:

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:

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

…and then again…

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

2 Likes
5

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

2 Likes