Manufacturing Automation Script for B402 and B523

Firmware Device OS
, ,
1

Hi! we ordered a batch of 200+ BSOM chips from Particle for a project.

We started by claiming/naming them with the Particle App which worked fine but took a long time. We then transitioned to using Particle Workbench to claim the BSOM chips and claim/name/flash firmware, but this also took quite long doing them one at a time and running through multiple CLI commands. We then built a script in Node.js that automatically runs through the commands but encountered some issues, see description below.

Has anyone had to provision a large number of Particle Cellular devices? any recommendations or existing tools I can use or buy?

The note below is from our Developers in Romania. One added complexity is that we are provisioning these devices in NYC then shipping them all over Europe, so the B523 doesn’t connect via cellular until it arrives at a customer’s location in Europe.

Based off this article for setting up Boron units through USB: https://support.particle.io/hc/en-us/articles/360045547634-How-can-I-set-up-my-Argon-or-Boron-via-USB-We wrote a node application that runs basically the commands, from the Boron section from the article in a sequence. We’re currently using “particle-api-js” and “particle-usb” as NPM modules in order mirror the terminal commands from the article. The algorithm works in the following way:

  1. Logs in with “particle-api-js” into particle cloud and receives an auth token
  2. Fetches all USB devices with “particle-usb” module and iterates through the array
  3. Opens the currently iterated devices
  4. Fetches its ICCID (uses the currently iterated device’s API, coming from ‘particle-usb’ module)
  5. Activates the SIM card with that ICCID (uses ‘particle-api-js’)
  6. Leaves listening mode (uses the currently iterated device’s API, coming from ‘particle-usb’ module)
  7. Registers the device on console.particle.io (‘particle-api-js’)
  8. Renames the device on console.particle.io from a spreadsheet we have (‘particle-api-js’)
  9. Enters DFU mode (terminal command: ‘particle usb dfu’)
  10. Runs ‘particle update’ (the terminal command, but it is executed by the currently running Node.js process with a promisified version of exec https://ali-dev.medium.com/how-to-use-promise-with-exec-in-node-js-a39c4d7bbf77)
  11. Enters DFU mode again (if by any reason it somehow exists after the ‘particle update’ command)
  12. Flashes our latest firmware, instead of Tinker (again, a terminal command ‘particle flash --usb our_firmware.bin --force’, but ran from the Node.js process)
  13. Closes the device (‘particle-usb’ module)
  14. Finish setup (‘particle usb setup-done’ ran with Node)All steps are promise-based in order to use async/await features from JS.Even though the algorithm works sequentially, we also added ‘promise-retry’ module in order for the algorithm
    to retry a step if by some reason it did not:
  • run
  • failed
  • timed out
  • had to wait for the board to connect to internet The questions:
  • There are times when one step just hangs and the developer has to do a full reset
  • the setup process works for one unit at a time, and it takes somewhere between 80 seconds - 4 minutes. Could we parallelize this or does the USB method support concurrent device setup?
  • there’s a --force flag there, when flashing our firmware, it seems that when I set it up in Romania it works without the flag but for B402 device it needs that --force flag otherwise it gets this error: Error running Flash latest firmware :x: because: Error writing firmware: Incorrect platform id (expected 23, parsed 25), use --force to override
    , retrying…
  • Is there a difference between registering a USA device vs European one?
  • Is there a way we could optimize this even further
1 Like
2

You should never use the --force flag. If your firmware flash fails without it, there’s a different problem that needs to be fixed first.

In this case, it’s because the B402 SoM requires a user firmware binary compiled for platform “bsom” and B523 requires a user firmware binary targeting the platform “b5som.” They’re different because they have different modem manufacturers (u-blox and Quectel, respectively). Flashing the wrong platform binary will probably cause the device to go into DFU mode, or SOS fault.

1 Like