We are setting up Outboard Firmware Update. The hub.mode is set to minimum and sync is false , as we want to explicitly trigger a sync on our own schedule. card.dfu is set to on: {"req":"card.dfu","name":"stm32","on":true} , and dfu.status is also on: {"req":"dfu.status","on":true} . The symptoms are that notehub reports Firmware Update Status “Downloading (0%)” and firmware update request has the status “Device handling request”. This persists. We are triggering sync manually every hour with some of our own data that needs to be synchronized. But the notecard does not seem to progress at all with the download of the firmware.
The only solution that makes the update progress is switching hub.mode to continuous which is not desirable in our low power application.
Notecard 6.1.1 has this issue.
The only way out of it that we have found is to poll the backend to see if a DFU is available, and if DFU is available, we switch to periodic mode until the DFU is complete.
@daterdots Our low power application is somewhat similar to yours in that we are in minimum mode, take a reading every hour, sync, then put the esp32 to sleep until time for the next reading.
I was able to get Outboard Firmware Update to work staying in minimum mode, but it takes a long time to complete. I left it running overnight and in the morning, it had completed.
I didn’t like the uncertainty of the timing to complete, so I basically did what you did, i.e. I poll to see if a DFU is waiting, then I switch to continuous mode, complete the DFU. In our code, when the DFU is complete and reboots the hardware, hub.mode is set back to minimum.
It has not impacted our battery life. Outboard DFU is completing in around 20 minutes.
For context, I work with @daterdots on the project.
The way we worked around the problem was, switching to periodic mode, with a longer duty cycle than our own, manually triggered sync. (we have to manually trigger the sync as it has to happen at a specified time of day)
I hope that we are at the correct assumption, that a manual sync request, will reset the periodic timer. This means, that if we trigger a sync every hour, and the period of periodic sync is set to once a day, the periodic sync will not happen unless we stop manually triggering syncs for a day. Unfortunately I don’t seem to be able to find any firm statement about this, in the documentation.
We tried using minimal mode and wait for an update to occur. We were testing with firmware 4.1.1 at the time. We were triggering syncs every hour, but still after two days of running an update was still stuck at 0% download. In minimal mode it seems the update is being started but the download stalls at 0%. I retested this with notecard firmware 6.1.1, but it seems to also have the same problem.
We were considering to solve the issue, by detecting a dfu update and switching to continuous mode. As you suggested @Karl_iWell but, the periodic mode seems to solve the problem for now, without having to implement extra logic in our firmware.
All things considered, I still think there is something off with the minimal mode. I have also not found any notes, about how modes interact with the dfu update system, besides very general things involving continuous mode. Some more details about how it is supposed to work would be nice.
I need to test the Outboard Firmware Update process in minimum mode, so let me get back to you on that.
Regarding your other question, the inbound and outbound periods are aligned to boot time of the Notecard. Even if you perform an explicit hub.sync request in between, the next sync due will be at the next aligned period.
Overnight I was able to confirm that Outboard Firmware Update does not work with the Notecard in minimum mode, even with regular hub.sync requests. At this point the official stance is this process is only supported if the Notecard is in continuous or periodic mode (which yes needs to be documented) and it’s TBD yet whether minimum mode is something we can support due to the nature of that mode.
After thinking through this a bit more, I have a question. Is there a command or a combination of commands that would allow us to reset the Periodic timer? This way, if our firmware for some reason stops triggering the automatic syncs, the periodic timer would kick in and allow us to reset or update the firmware. This would be a good reliability fallback without wasting energy on the extra syncs.
