Watchdog for ODFU when disabled?

1

Hello!

TL;DR: Does notecard have a means to automatically re-enable outboard updates after a watchdog timeout?

Our project uses Outboard firmware updates. At present (during the development phase), updates are always enabled. However, for production devices in the field, we would like the firmware to disable ODFU at times when the firmware must remain running, as stopping firmware during those times would lead to a poor user experience, since it would interrupt the user’s ongoing interaction with the device.

I figured we could issue a card.dfu request with off: true to disable ODFU updates during those times, and then issue another card.dfu request with on: true to enable them again when it’s safe to update firmware.

Thinking about reliability and availability, if the firmware were unable to re-enable ODFU, the device would no longer be able to be updated.

If I recall correctly, with IAP (inboard) updates, Notecard will exit host DFU mode after a timeout, so that the app must periodically assert it still wants Notecard to be in host DFU mode (via hub.set, mode:dfu). Is there a similar mechanism for outboard updates? If not, could it be added as a feature request?

Thanks!

1 Like
2

Hi @devElert,

This is a great idea - no such mechanism exists today, but our firmware team will look into adding such a feature in an upcoming firmware release!

Thanks,
Rob

3

@RobLauer That’s great to hear! If you don’t mind, I’d like to make few suggestions:

  1. It would be great for our use case if the the timeout could be part of the card.dfu request (say, via a minutes field), which is when Notecard would automatically enable ODFU if it is disabled and another card.dfu, off: true, minutes:X request hasn’t been received before the timeout. This would allow ODFU to be set according to the particular scenario the app is in. In our case, sometimes a 15 minute timeout is appropriate, while in others a 1-2 hour timeout would be preferable.

  2. From a safety perspective, having an upper cap for the minutes value to some reasonable upper limit, say 24 hours, would mitigate the chance of the application sending in a bogus value. (Admittedly, that seems unlikely, since most would hard-code this value in the request, but it acts as an additional layer of safety.)

Just suggestions. If the timeout ends up being a fixed value, we could work with that too.

2 Likes
4

I just discovered this reserved environment variable _fw_download_always_enabled - this is great to see that there is a backdoor to re-enabling ODFU should firmware disable it, as well as other variables to restart notecard or the host after a period of inactivity.

This isn’t as much of a turn-key solution like the DFU watchdog would be, and would require some effort to get working. Our backend service would have to detect when notecard is still operative (say, via notehub session events) while also seeing that the host has been inactive for a period due to the lack of application events (to data.qo) before then using the Notehub API to set this environment variable, and then clear it once the host is back online.

2 Likes