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?
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!
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)?
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:
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:
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
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.