Custom DFU processes from user application including Assets - BLE idea

Firmware Device OS
, ,
1

There are several locations where we have Borons and Muon devices installed that are unable to connect to the local cellular network. We have tried antenna repositioning, etc but we consistently have about 10% of our fleet offline persistently.

Each of our devices is installed in a location where it communicates via BLE to an Android smart phone on-site. The Android smart phones at these sites all have no problem connecting (they have local SIM cards, better reception, etc).

We have a proof-of-concept working where we can get these android devices to relay webhooks from the particle devices directly to our server when cellular network in not available. That works fine.

My question is regarding how to manage firmware updates on these devices. If they cannot connect to the Particle Cloud, then they can’t download OTA updates to begin with. This means that we can only flash these devices using either a USB cable (not good - these devices are in remote African villages hundreds of kms away), or else implement a system where the Android device is able to cache a binary file (plus asset binaries for coprocessors) to send to the Particle Device over BLE.

My idea is that I could get my app to do this:

  • Wait for Android phone to pair with Particle device
  • Download new app from Android device into the OTA changeover section of Particle device flash memory via BLE
  • Verify new app (check CRC against one reported by Android)
  • Apply new app (I presume this is accomplished through some kind of Particle Device OS bootloader magic?)
  • After new app launches, reconnect to the android device via BLE and download coprocessor assets to app changeover region
  • Launch app (for real this time, with assets in place)

Basically duplicating the OTA cellular process used by Particle OS when downloading an OTA update, except using BLE instead…

@rickkas7 I think you have investigate similar ideas previously, can you provide an opinion or recommendation on a path forward here?

2

If you only plan on upgrading the application binary, not Device OS, bootloader, etc. it's relatively easy, at least in theory. It's very difficult, probably impossible, to be able to upgrade Device OS because your firmware won't load until upgrade is complete, but you won't be able to load more parts until you download them using your firmware. There isn't enough flash space to download everything at once.

Basically, there's a specific region of flash that you download the new application binary to. This is where it's loaded during OTA, but you could using your custom BLE protocol to get the parts and store them there. Once all of the chunks are successfully downloaded, you set another flag in the DCT and reboot, and if the binary is valid it will boot into the new user firmware.

3

Another possible solution is to flash from a mobile app using BLE. The protocol to do this should still be in Device OS and it should work when the device is in provisioning mode. It's how the old Particle mobile apps worked. That method can be used to flash both user firmware and Device OS. However, the mobile-side protocol is complex and requires both the device serial number and the mobile secret from the device to authenticate and encrypt the session over BLE. The mobile secret in the data matrix code on the label, and is also stored in the cloud.