What happens if I have a fleet `_fw` environment variable and then later add an identical device `_fw` variable?

Uncategorized
1

For weird reasons, I have a bunch of devices in a fleet that have the following fleet env vars:

_fw        = V1_3_3$20260923000412.binpack
_fw_retry  = 1790660860

I was updating host firmware using the fleet env var, but I ran into a problem: some small number of devices in the fleet already had a device env var for _fw that preempted my fleet env var.

The easiest way for me to resolve this problem is to just set the _fw device-level env vars for all the devices in the fleet. I would do this using the Notehub UI – I would request a host ODFU for every device in the fleet (using the Select All and then Update buttons).

My question is: if a device is already running _fw = V1_3_3$20260923000412.binpack because it took it from the fleet environment variables, when the device level _fw is set to the same firmware version will the Notecard ODFU the host again, or is the Notecard smart enough to know that the host is already running the requested host firmware version?

Why this matters: our device is extremely energy constrained. ODFU is really expensive for us energy-wise, so I want to make sure I don’t spend that energy on a redundant host ODFU.

2

Hi @daterdots,

There is some nuance here to understand:

  1. If the _fw AND _fw_retry are the same, (or _fwc/_fwc_retry), no one will even notice that there was a difference, regardless of whether it came from device or fleet.
  2. For Notecard firmware, if the _fw is the same but _fw_retry is different, the Notecard will check the MD5 of what it’s already running, and it will be optimized out. No impact.
  3. For Host firmware, if the _fw is the same but _fw_retry is different, in no case will it be re-downloaded, but it will change from “completed” back to “ready” state, which means that…

…for Inboard (IAP) DFU, the host will see that it has become ‘ready’ again and it is responsible for checking MD5 to see if it needs to ‘pull’ it from the Notecard again. If it’s the same it is up to the host to just set it back to ‘completed’.

…for Outboard DFU, the Notecard re-burns the firmware onto the host mcu and restarts it, and marks it ‘completed’.

Thanks,
Rob

3

@RobLauer I did a check on this, and it seems like in the case of the same _fw but different _fw_retry the Notecard still spent a bunch of energy downloading the image of the host firmware off of the Notehub. Does that seem right to you?

4

Hi @daterdots,

I think may have overstated it when I said “in no case”.

When _fw stays the same and only _fw_retry changes, Notecard skips the download if it still has a valid cached copy of that exact fw image from the last download. If it does, it goes straight to “ready”. If not, it downloads the whole thing again.

Even when a previously downloaded version is used, the Notecard doesn’t know the host is already running that image, so it re-flashes the host. It also triggers syncs to report “ready” and then “completed.” On Notecard models that don’t have onboard flash for DFU images (meaning the “green” Notecards), the cached image is kept on the modem, so the re-flash also powers up the modem to read it back. If you were measuring current draw, that can look a lot like a download.

I’d check that device’s health log in Notehub (_health.qo) around the time of the update. A fresh download will log something like DFU host firmware download started from.... When the a cached fw image is used the log goes will say DFU host firmware ready: successfully downloaded, followed by the regular outboard fw update entries.

Thanks,
Rob