Disconnected Firmware / deviceOS update device - is this possible?

Firmware
1

This is something that I thought would exist but, I cannot find any examples on the forum.

I would like to build / buy a device that I could send to a park with poor cellular coverage. This device would connect to the Boron via USB and perform a DFU update of the deviceOS and firmware just as I might using an OTA update. I am open to ideas such as long as they meet these three requirements:

  1. Park Ranger proof - has to be very easy as these are busy professionals
  2. No connectivity required - Areas have poor coverage even with high-gain antennae don’t want to make the Ranger wait up to 11 minutes watching “flashing green”
  3. Fixed function or remotely configurable - Don’t want to ask folks to type command prompts

Some ideas to explore:

  • The Chrome / DFU USB utility - could I put it on a cheap Chromebook? Would it work disconnected?
  • Some way to package the JTAG programmer with the Hex file for a device?
  • Using a Particle device?

Any ideas appreciated.

Thanks, Chip

1 Like
2

Interesting… Yeah I could see this need existing. I do not know too much detail about the options you discussed but something I’ve thought about similar to this was options for OTA updates (or updates in general) with non-Particle devices.

In my early days, and now with my young 9 year old son, I’ve played with various Adafruit devices and jumped between Circuit Python and the regular Arduino IDE. Although it seems like an amateur approach, one nice thing I liked about the Circuit Python (and Micro Python I believe) is when plugged into a computer it behaves as a USB flash drive. So theoretically you could send a customer the code as a file, they just plug the device into any computer with a USB port, the computer recognizes it as a standard USB drive without needing any special drivers or software, they simply drag and drop the file to the device and the device runs the new firmware. It’s a method that seems possible. I’ve debated with non-particle devices that don’t have OTA capability if am I better off with Circuit Python for this reason alone. I’m not at a point of needing to make that decision yet so for now it’s just an idea. This workflow for a non-tech customer seems feasible though.

I will be curious to hear what you find out. The Chrome/DFU USB Utility is especially interesting as it wouldn’t require any additional software except a Chrome Browser.

3

great question, as usual, Chip.

Option 1: Raspberry Pi + Particle CLI

Could a Raspberry Pi be used here?
If one can install the Particle CLI in it, you could potentially use a script that runs when the rasp pi boots and calls the CLI to flash the firmware.
Very Park Ranger friendly:

  1. connect via usb to the boron
  2. power up
  3. wait a minute and/or observe the boron go yellow then back to online mode breathing cyan

Option 2: Raspberry Pi + NEOPO

@nrobinson2000 will be in better position to confirm if you could use neopo for this as an alternative to the Particle CLI.

EDIT:

Option 3: Do they have laptops?

If they do, an Electron app that wraps chrome or the Particle CLI can

Those are some options I can think of today :bulb:

Cheers!
Gustavo.

1 Like
4

I think a Raspberry Pi would be the most suitable platform for this project given the size, power consumption, and OS support.

Installing neopo on a Raspberry Pi quickly gives you the needed toolchains for building and flashing Particle firmware as well as reliably installing particle-cli.

Configuring a script to run at boot could be achieved by creating a systemd unit.

There are many ways to create the script, but I would suggest using Python so you can make use of the gpiozero library so you could include buttons for operator control (connect boron via usb, push button to flash) and perhaps a RGB LED for additional status information.

By using Python you can use all of neopo’s functionality from a python interface, or you could just use the convenient neopo.particle wrapper to run specific particle-cli commands.

For storing the firmware on the Pi you could either clone your project repo on the Pi (assuming you’re using version control for your project), or just copy your source code onto the Pi.

If you want something more advanced, you could create an additional FAT32 partition on the Pi’s microSD card where you could just drag and drop the latest precompiled deviceOS and application binaries for the boron and use those directly in the script. (You would probably want to add an entry to /etc/fstab on the Pi to automatically mount the partition on boot.)

@chipmc, creating this device for updating isolated Particle devices in the field sounds like a very fun challenge. If you have any questions about neopo or Raspberry Pi I’d be glad to help.

2 Likes
5

@jgskarda ,

Interesting on Circuit Python, I know this language has made some significant inroads in embedded devices. I have a handful of devices that are in “disconnected” operations mode and, when I was deciding how to architect them, I looked at other options - why use Particle when you are not going to connect after all.

I stuck with Particle for these disconnected units for three reasons:

  1. My hope is that someday, they will be able to connect (Verizon!). One day, you may be able to press a button (no, really I have a button for this) and the device will connect and transition to connected operations using an OTA update.
  2. I love the Particle library system and was not sure about the drivers / quality in the open source world.
  3. I could keep much of my code-base the same.

That said, as time goes on, paying the Particle bill when I am not connecting seems to be wasteful. Perhaps Circuit Python is worth a look.

Thanks, Chip

1 Like
6

@gusgonnet ,

Thank you for your response. I do have options 1 and 2 open to me and plan to explore both. Especially like the idea of something like this:

As for Option 3, alas these are state employees with state laptops. I have a batch uploader app for Ubidots that has bee in review for months with no sign of being approved soon. Government rules preclude me putting unapproved software on their laptops.

Chip

7

@nrobinson2000 ,

Wow, this sounds like a great solution!

So, to be clear, I could take my project repo from Github (I use Particle Workbench today) and neopo could compile and update my Boron? Libraries and everything? This sounds like a great solution. Using the deviceOS and compiled binaries sounds like a great option too. I have a couple Pis laying around, so I will do some playing and - I am sure - ask you for some help.

Thank you!

Chip

8

Yup.

cd my_project
neopo libs
neopo configure boron 3.1.0
neopo flash
3 Likes
9

Hey Chip,

I was thinking of something smaller, like this:

image
image1298Ă—1211 64.4 KB

amazon

There might not even be a need for a display, just a bare rasp pi (even/maybe a rasp pi zero can be used here?) with a battery and a usb cable. Connect, power up, count to 20 and enjoy.

4 Likes
10

I have one of those running Windows 10 and it cost me about $100 or so. You could have it boot to autorun a simple GUI to flash an image to an attached Particle device via DFU. Even a cheap Pi ZeroW could do the same with minimal display and button(s).

3 Likes
11

That said, as time goes on, paying the Particle bill when I am not connecting seems to be wasteful. Perhaps Circuit Python is worth a look.

Yeah to be clear... I am only considering the CircuitPython approach for devices that are non-particle devices by design. For your particular use case, it seems clear decision to make them all Borons. These are potential end node devices. These would not connect to Cellular but rather talk to the closest Boron. I was considering making them Boron's for the sole purpose of OTA updates but at $5 for the MCU vs $60 for a Boron, it just was hard to cost justify. That plus supply chain issues with Boron's it just isn't feasible. With non-particle devices, then the question comes how would a customer update the firmware on an end node if/when necessary. Using CircuitPython that behaves as a flash drive for that scenario was one consideration. I liked it as it didn't require any hardware to ship/send them.

That said, I am curious to see where you end up as I wonder if a similar approach could be used for Arduino IDE programmed devices IF I went that route over Circuit Python for end node devices.

  • Nice way to try and future proof the hardware. I included some DIP switches in my PCB for future proofing where I can to allow "configure options" like this. Didn't use any yet but had similar thoughts.

Are you able to de-activate the SIM and un claim the device so the devices don't count against your 100/block? Might be hard to keep track of but I think that's doable. That way your hardware can be identical but your not paying additional monthly costs for devices that don't connect.

12

I have also been looking for a simple solution for a long time. A remote customer, a service function, a critical situation needs a fast response. In an increasingly cloud based world, maintaining a "PC tool chain" in a remote location is a no-go for us.

I was recommended Segger J-Flash standalone devices, but for us they are too expensive to not get back again, and a quick look indicated a ton of details to get right. Instead of just loading a hex file you already have to the device, and the user having one button to press.

A particle debugger with drag and drop, is the closest thing I have found, but it still needs a PC at the other end.

Perhaps a particle debugger firmware variant can be made to, flash an already dragged and dropped hex file, at the press of a button connected to the port on the device it self. It could be cheap, simple, standalone, quick and easy and would only need a protective case, maybe 3D printet, and one of the many USB power supplies the world is flooded with already.

1 Like
13

@thrmttnw,

Yes, using the debugger and the HEX flle generator is the solution Particle developed for contract manufacturers and the like. My only concern - and please tell me what you think - is the connector. I worry that the debugger connector is not “consumer grade” enough for my users. What do you think?

Chip

14

Good point - likely not suitable for non-technical people.

15

@rickkas7 can the Web USB tool be made to run offline?

1 Like
16

@chipmc is a tablet a viable option for you?

If the usb port on a tablet can be used to program a Particle device with an app, this could be one option too.
But, we would need to ask around (Rickkas7 comes to mind, but not invoking his superpowers yet, so not mentioning him) for that USB port on a tablet.
Cheers

1 Like
17

@gusgonnet,

Yes, a little pricey but it is an option. I would assume it would have to be an Android tablet (Apple would never allow such things) and we would need some confirmation on the Chrome USB reset.

That said, if it would work on an Android tablet, it would also work on an Android phone.

Going to to some work on this on Friday so thank you get giving me another path to explore.

Chip

18

yeah, I was thinking of an Amazon Fire or other very cheap tablet here.
Good luck with the experiments this friday, then.
Gustavo.

19

You can use a cheap Android tablet to program a device over USB as long as:

  • The hardware supports USB OTG (on-the-go)
  • It can run the Chrome browser (version 89 or newer)

The Device Restore over USB works using this technique.

I also think the Raspberry Pi option is good. I’ll be releasing some code soon that allows mass programming of devices over USB using a node.js-based server. All you have to do is plug the device into USB and it will start programming. This could be adapted for offline reprogramming easily.

6 Likes
20

@rickkas7 ,

This is great news. Thank you for chiming in here.

And just to be clear, that Android tablet would not need any internet connection to do this? I assume we would need to somehow pre-stage the compiled binaries that the DFU utility would then access.

Chip