OTA DFU Update Happens On Every Power Cycle


I have been successful in performing OTA host firmware updates, however it appears that the notecard is downloading and installing the latest firmware in Notehub to the host mcu on every power cycle, even though it is already installed. This is not ideal for me.

I only want the host to do an OTA firmware update when I explicitly push one, and not every time the device powers up. Is there a way to do this?

Thank you!

Hi Taylor,

That sounds frustrating. Can you provide us with some more information?

  • In Notehub, what “Environment Variables” are associated with the device?
  • When you say “power cycle”, do you mean the Notecard, the host or both?

Are you able to invite support to your project?

Once we have some more information, I’m sure we can figure this out.


1 Like


Here is a list of the device environment variables:

And I think it happens when it is the notecard doing a power cycle because when I press reset on the Swan with the notecarrier still powered via USB, this does not happen.

No problem – I just invited support to my project!

Thank you Zak!!!

1 Like

Thank you for sharing all the information!

The environment variables look to be in order, so now I have a couple of questions about the firmware.

Our expectation is that the Notecard should remember the environment variable settings, and will not retry the DFU unless they were to change. However, if the Notecard’s filesystem was cleared for any reason, then it would no longer have knowledge of the prior DFU and would attempt to repeat the DFU.

As an example, the Notecard’s filesystem is cleared during a card.restore. Does your firmware issue a card.restore or do anything to reset the host or the Notecard?

Also, are you using Outboard DFU (ISP) or standard DFU (IAP)?

1 Like

I do not have any explicit card.restore requests in my firmware and I don’t have anything that puts my host to sleep, either.

I am pretty sure I am doing outboard DFU (ISP) (frankly I am unsure of the difference between those two – please excuse my lack of knowledge there). I followed this tutorial: Notecard Outboard Firmware Update - Blues Developers

This is a snippet of code enabling DFU updates in my setup function:

  req = notecard.newRequest("card.dfu");  // Enable OTA mcu firmware updates
  if (req != NULL) {
    JAddStringToObject(req, "name", "stm32");
    JAddBoolToObject(req, "on", true);

I also have functions in my firmware that pull the environment variables but not sure how relevant that is.

This is all good stuff!

The DFU code looks fine. If that’s all your are doing for DFU, then you are definitely performing ODFU (standard DFU is very code intensive).

Which APIs are you using to manipulation or poll the environment variables? Perhaps that will offer a clue as to what you’re seeing.

Here is the firmware snippet polling the environment variables:

int getSensorInterval() {
  // sensorIntervalSeconds = sensorIntervalSeconds;
  J *req = notecard.newRequest("env.get");
  if (req != NULL) {
    JAddStringToObject(req, "name", "sample_rate");
    J *rsp = notecard.requestAndResponse(req);
    int sample_rateEnvVar = atoi(JGetString(rsp, "text"));
    if (sample_rateEnvVar > 0) {
      sensorIntervalSeconds = sample_rateEnvVar;
  return sensorIntervalSeconds;

Is notecard.deleteResponse(rsp) clearing the filesystem?

Also, from Ubidots, I have a webhook trigger that posts the following payload to my device environment variable URL when the sample rate is changed by the end user:

{"environment_variables":{"sample_rate":"[Last Value]"}}

I have seen this too, although I haven’t investigated much.
Sometimes clicking stop update in notehub stops it looping.
But I’ve also connected to the notecarrier with USB and the browser terminal on dev.blues, then issued


while we are debugging ODFU issues, any chance of some love from Blues on this issue? Outboard DFU issue - error: esp: erasing flash failed - #12 by calcut

1 Like

Interesting that you’ve seen this too – thank you for sharing!

Perhaps there is some sort of code snippet that could be written to check for dfu.status and depending on what “mode” is, it could then do the update?


Thank you for your diligence! You have discovered a regression in the firmware. We have a fix, and it will be released very soon with the next LTS release of the firmware.

We appreciate the clear framing of the question and detailed information you provided. It helped us reproduce and track down the bug very quickly.

As a temporary workaround, you can manually delete the environment variables _fw and _fw_retry from the device to prevent the behavior.


1 Like

Very cool! Thank you! :slight_smile:


I want to confirm we are also experiencing this issue, and await the LTS release ASAP.

Manually deleting _fw and _fw_retry from a larger device fleet is problematic.


1 Like