Dfu.status missing body containing length

1

Hi,
I am working on a host device firmware update. To download the firmware to the host, I have been using the “length” keyword in the body, and it was working well. However, after experimenting with outbound firmware updates or related settings, I no longer receive the body of the message when I use “dfu.status”. On the other hand, “dfu.get” still returns the host firmware as the payload. How can I resolve this issue or reset my device to restore its previous functionality?

2

Hi @Thareeq and sorry for the delay in getting back to you.

If the length argument is absent, that means the length is likely 0. Are you seeing anything else in the response (like a crc value for instance)?

3

Hi Rob - Might be related… last week, e.g. 1/7/2026 my dfu started failing ( esp32s3 ). I figured I broke it while doing some code cleanup but after going back to my know good code dfu was still not happening. Then about 1/9 things seemed to start working again. I’m still pouring through my logs and notes but what stood out was that the notehub got to ready state , which implies the code is now on the notecard.

Looking at the host mcu side esp32s3 I saw that the length was 0 and thus no download.

Notecard fw: 9.2.3.17324

Thoughts ?

1 Like
4

Hi @gomario2,

Are you seeing anything else in the body element of the dfu.status request?

Rob

5

Hi @RobLauer,
I had a similar issue on one of my devices where after triggering DFU from notehub the dfu.status just switched from
{"status":"successful firmware update","mode":"completed","on":true}
to
{"status":"successfully downloaded","mode":"ready","on":true}
but as you can see the body field is missing and I am not sure what would be the reason.
I am working with Notecard WBEXN with FW version 11.1.1.17494.

Renato

6

Hi @Renato,

I’m curious if you supplied any version, notes, and/or metadata for this host firmware update in Notehub? Either way, is the DFU able to complete successfully for this device?

Rob

7

Thank you for the quick response @RobLauer,

The FW image that was triggered to be applied during DFU has all the necessary fields filled out:

  • Source
  • Notes
  • Metadata
  • MD5 Checksum
  • Version

The DFU was already successfully applied to the device with the same FW version and then on second apply it failed with the issue I described. So the DFU was not continued from the host firmware because it didn’t get the valid body field in the dfu.status response. Because the next step is to read the image with dfu.get, but without image length the end size to read is unknown.

I tried to replicate this issue on a different device with the same HW and FW versions, but I wasn’t able to and everything seemed to work fine.

Renato

8

Thanks @Renato.

Did the Notecard reboot (power cycle, reset, etc.) between the first successful host DFU and the second attempt?

9

@RobLauer
Yes, at least 2 days passed and Notecard was rebooted multiple times between the first successful host DFU and the second attempt.

I tested again with Notecard power-cycle after successful update and I was able to replicate the error. If I am using Notecard incorrectly, what is your suggested way to handle this issue?

Renato

10

Hi @Renato,

Thanks for the additional info. It looks like neither of us are seeing things and this may indeed be a bug in the Notecard firmware. Our firmware engineers are looking into this now.

Rob

11

Just want to +1 this issue. I am running notecard-9.3.1.17434 and I get the same response. No body or length info. I’m using the Note Carrier F v1.3 with an Adafruit ESP32 Huzzah board attached.

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

{
 "status": "successfully downloaded",
 "mode": "ready",
 "on": true
}