We are entering into the production phase of our project with an Argon mounted to a custom PCB to communicate with wheelchairs. I’m trying to minimize the time it takes the manufacturer to flash the OS and test firmware onto the device.
Currently I have a shell script that runs through CLI commands to flash over USB the needed parts of the OS 1.4.0 then our firmware. This process currently takes a little over 4 minutes per device.
Other than adding another computer, is there a way to flash multiple units at once or can one use JTAG to flash quicker?
I can’t seem to find any recommendations of how to optimize production. Any recommendations from people that have been through this already?
One thing that might shave off some time is to just use particle update to update all of the system modules at one time. For some reason, update seems to run really quickly (as compared to running multiple particle flash commands), and that ensures that everything (Device OS, bootloader, and where applicable softdevice and the NCP) is updated to versions that are guaranteed to work with each other.
The thought occurs to me to run multiple VMs on the same box, each one being pointed at a different virtual DFU port. I have no idea if that’s possible though! But PCs are cheap cheap these days, so what I would do is set up a few $200 Windows boxes, and then use VNC Server/Viewer to run all of them from one of the machines.
That is an interesting idea to have multiple machines running through one viewer machine. I’ll play with that idea some.
The problem I will run into with the particle update command is the test firmware flashed onto the Argon is used to test the peripherals and is built on 1.4.0. When the OS updates past that I don’t believe our firmware will run. Correct me if I’m wrong there.
One of the challenges with using Particle Update is that you’ll get the latest release of Device OS - you cannot set a specific device OS version which of course you will want to do, if you have a rigorous test/release cycle.
I am also trying to find the best way of getting these things programmed on the production line. I’d like to have a device that hold the relevant binaries, and then smashes them onto the device. It would be great if it were trigger automagically from our test fixture.
Your firmware will likely run with the latest firmware as it’s released, but as a product you plan to ship to end customers, you’d probably want to strictly control which DeviceOS and firmware ships with each one. That way you know you’re shipping a known good, tested configuration. The few minutes you spend in manufacturing will save you countless hours in the future on support, RMA, etc. I would not use particle update for a device I am manufacturing for shipment.
I’m only doing low volume pilot runs right now, but I use the method you mentioned in your initial post. It’s worth the peace of mind knowing that an untested OS isn’t the cause of any failures in the field. When I ramp to higher volume I plan to have multiple workstations flashing and running automated testing. I’ll most likely do this using Raspberry Pi Linux machines with a very cheap HDMI display. When I want to ramp even higher I’ll build a semi-custom Raspberry Pi rig with a small OLED display and just a couple of buttons for control.
The particle update command will install the newest production firmware that was current when whatever build of CLI you have was created. Details on what Device OS version is in which CLI version can be found at https://github.com/particle-iot/particle-cli/releases.
If you’ve installed CLI using npm, you can install a particular version of CLI/Device OS like this:
npm install -g particle-cli@v1.43.0 — that contains Device OS 1.2.1
(That does not work with the CLI that is installed with Workbench.)
Regarding Device OS versions vs. what Device OS you targeted your user firmware to: Your firmware should run on what you targeted, and also on any newer version. The “other way around” is not guaranteed or even recommended.