We have a fleet of about 90 WBNAN Notecards, using our custom PCBs with ESP32-S3 host microcontrollers. Our design does not include the wiring for a Notecard-managed host firmware update, so we are using In-Application Programming.
This was working fine until recently, when we shipped some units that were several versions behind our latest host firmware version. When those units came online, a few of them have stopped sending our normal hourly data. We find these are now “stuck” on an earlier host firmware version, but they keep trying to update unsuccessfully.
I can add details such as our code and the Notehub reports if you like, but my first question is this: Say I upload a new host firmware version A to Notehub, then request an update for device D – but device D is on our shelf, not online. Then I upload a newer host firmware version B to Notehub, again requesting an update to device D. When device D finally comes online, what will happen?
Does it start downloading version A? Or does it skip A and download version B? From my logs I suspect it started downloading version A but before that version was pulled over to the ESP32 with our IAP code, the version B started downloading and corrupted the download on the Notecard. Is this a possible explanation?
Hey @mark_pdx,
To answer this part:
Say I upload a new host firmware version A to Notehub, then request an update for device D – but device D is on our shelf, not online. Then I upload a newer host firmware version B to Notehub, again requesting an update to device D. When device D finally comes online, what will happen?
Does it start downloading version A? Or does it skip A and download version B? From my logs I suspect it started downloading version A but before that version was pulled over to the ESP32 with our IAP code, the version B started downloading and corrupted the download on the Notecard. Is this a possible explanation?
In this scenario, Device D should download version B when it comes online.
When you request a host firmware update in Notehub, under the hood Notehub sets a _fw environment variable with the name of the binary for Notecard to download. If you request two firmware updates in a row, Notehub will just update your device’s _fw to the new version, and—as long as your Notecard hasn’t performed an inbound synchronization in the interim—your Notecard should only download the second version as well.
That being said, clearly something isn’t working right in your fleet. Maybe to start could you share the errors you’re getting in Notehub for the devices that aren’t updating successfully?
TJ
Hi TJ,
There were no errors reported by Notehub, only what appears to be an incorrect sequence of events, and the fact that my app version did not update. Here are the entries in Notehub for one of the problematic devices:
2025-07-16 04:39:42 PM: boot (brown-out & hard reset [17004])
2025-07-15 12:30:54 AM: DFU host firmware completed: successful firmware update
2025-07-15 12:30:51 AM: DFU host firmware download started from from HelloCell.ino$20250714164118.bin
2025-07-14 12:37:59 AM: DFU host firmware ready: successfully downloaded
2025-07-14 12:30:48 AM: DFU host firmware download started from from HelloCell.ino$20250713215501.bin
2025-07-13 12:48:12 AM: DFU host firmware completed: update successful
2025-07-12 12:36:37 AM: DFU host firmware ready: successfully downloaded
2025-07-12 12:30:52 AM: DFU host firmware download started from from HelloCell.ino$20250704035126.bin
In case those lines are getting truncated, here’s a paraphrased list of the key lines, in forward chronological order:
1: 2025-07-14 12:30:48 AM: DFU host firmware download started (V:20250713…)
2: 2025-07-14 12:37:59 AM: DFU host firmware ready: successfully downloaded
3: 2025-07-15 12:30:51 AM: DFU host firmware download started (V:20250714…)
4: 2025-07-15 12:30:54 AM: DFU host firmware completed: successful firmware update
So, Line 1, just after midnight on July 14, a host firmware download started. No progress reports seen.
Then, Line 2, 7 minutes later, it the download was successfully completed.
Then, Line 3, just after midnight on July 15, a new, later host version download started.
Then, Line 4, JUST 3 SECONDS LATER, a successful firmware update is reported. But my internal app log indicated the length of the file was zero, and the version attribute was missing, so it errored out.
I think my IAP code used DFU.GET to fetch the 20250713 downloaded firmware at that time, but newer firmware came in during that process. Does this make any sense?
Hey @mark_pdx,
Based on your firmware, is it expected that you would download a binary on 2025-07-14 12:37:59 AM, and then for that firmware to not get installed immediately? Like you said, the download starts at 2025-07-14 12:30:48 AM and finishes on 2025-07-14 12:37:59 AM (7 minutes later), but no update happens.
That’s the first thing that strikes me as odd.
The log messages from the next day are certainly odd though too. To look into this further I probably need to see the code you’re using to drive this to see if anything jumps out at me. (Feel free to DM if you don’t want to drop it here.)
TJ