DFU States: completed vs idle and Potential Impact on Device Behavior

Troubleshooting
1

Hi,

I have a question about the difference between the “completed” and “idle” DFU states and whether staying in the “completed” state could cause potential issues with device performance or connectivity.

I have two identical setups, both are pilots in the field, running the same firmware and identical configurations and environment variables. They are Cell + WiFi Notecards, running Notecard firmware version 7.4.2.16888. However, one device frequently goes offline, while the other remains stable. The only difference I’ve found so far is their DFU update status (note: I disabled DFU updates earlier this year to enable serial communication with the Notecard, and I’m not concerned with reenabling DFU functionality at the moment):

  • Device 1: Has been in the “idle” host firmware state and operates without issues.
  • Device 2: Has been in the “completed” host firmware state and has been experiencing frequent connection issues, despite excellent RSSI and successful data uploads when online. A power reset temporarily resolves the issue.

image
image641×122 5.79 KB

This is also outdated firmware that is not running on the mcus. The firmware was updated several times via USB and bootloader mode after this initial OTA DFU experimentation.

So, my main questions are:

  1. Could the completed state negatively affect connectivity, or is it likely something else?
  2. Is there a way to force (ideally remotely) a Notecard stuck in the completed state to transition back to idle?

Thank you so much! Let me know if I should provide any additional details.

All the best,
Taylor

1 Like
2

I think I have the same problem and I posted about it here

1 Like
3

Hi Taylor,

The DFU states of Idle and Completed should not be causing an issue. Both of these are just terminal states for DFU. It is a bit confusing because we never transition from Completed back to Idle

These states won’t negatively affect connectivity.

I’m not sure why there would be connectivity issues but it sounds like we need more information to further debug.

1 Like
4

Hi Scott,

Thank you, that makes sense.

Follow-up to that: How come one device did transition back to Idle, though? What may have led to this? It isn’t important, I am just curious!

Regarding the device connectivity, I am planning to check the Wi-Fi access point settings/logs to see if there are any clues there… The device is within ~15 feet of the access point with a clear line-of-sight, so I am at a loss. I ensured it is a 2.4 GHz only network, too.

5

How come one device did transition back to Idle, though?

That’s a good question, and my best guess right now is that there was some other unrelated change that caused the _env.dbs file to be sent up with the up-to-date Idle status on the device. But it’s important to note that the Notecard considers them to be equally terminal states so I’m not surprised that it sometimes doesn’t update. I think this could be communicated better on our UI

Regarding the device connectivity, it might be helpful to get trace logs. It doesn’t seem like it’s firmware related so I wonder if there’s something we’re missing and the trace logs would help a lot with figuring that out

1 Like
6

I see. This must be done via the in-browser terminal and a USB connection, right?

Unfortunately, my device is in the field and cannot be monitored like that for long periods of time. I am thinking that it may be worth swapping out Notecards at this point to see if it is unique to the Notecard.

Thank you so much!