So to start off the new year I was writing a script to automatically set up multiple devices via the particle CLI tool. This script will do the following:
Put the device into DFU (i.e. particle usb dfu)
Update the device’s OS (i.e. particle update)
Put the device back into DFU (i.e. particle usb dfu)
Flash a target binary or tinker if no binary is provided (i.e. particle flash --usb <.bin>)
This script seems to work perfectly fine a few Boron devices I tested with. However, upon running the script of brand NEW Boron devices, it seems that the script fails to even detect particle devices. It was only after a doing the following manually that the CLI commands work:
Press mode and reset buttons to put the device into DFU
particle update to newest deviceOS (currently 1.4.4.)
This leads me to believe that the particle cli commands do not work with the deviceOS that the Borons are on out of the box. Can anyone confirm this?
If this is indeed the case, then I have the following questions:
What is the best way to set up particles new out of the box in bulk (i.e. update them to a desired deviceOS and flash the correct firmware.bin). I need to do this for all gen3 devices (i.e. Argon, Xenon and Boron). Maybe someone from the particle manufacturing team can anwser this?
If the CLI commands are not supported out of the box, does particle have any plans to update the out of the box deviceOS version so that it does?
USB control reports (used for particle usb ... commands) was only introduced some time after first release.
You can use the magic baudrate 14400 to put the device into DFU Mode tho’
On Windows you’d need to scan for the COM port your device connects to and then run mode COMx 14400.
@ScruffR here you mentioned COMx on windws but how would I do this on linux. On linux I realized that plugging in a fresh device doesnt add another ACM port under /dev/. Plugging devices on newer deviceOS adds ACM1, ACM2, ACM3 etc... which allows me to use the 14400 baud rate trick. Any ideas?
@ScruffR I've also tried this on a windows machine. Similar to linux older deviceOS doesn not seem to appear when I connect or when I do a scan. The scan is done using the "mode" command on CMD or PowerShell. Any suggestions to detect the COM/ACM ports for older device OSes?
I was also referred to manufacturing scripts by particle GitHub - particle-iot/solutions-manufacturing . Quick look shows that they too use the 14400 baudrate trick to trigger DFU mode. However, it seems they used stty commands to force the baudrate. This looks a bit weird to me since 14400 isnt a redefined/common baud rate and from the post How to change baud rate to 14400 on Linux? this shouldn't work. Even if the stty command works, I think the issue of detecting which ACM port still exists.
I'll probably look into this script in detail this week to see if they do anything special.
I also found this post Factory flashing using Workbench by @rickkas7 which describes excatly what I want to achieve. Here he mentions the use of SWD/JTAG which I guess I could try if I can't figure the USB issue out.
You can use particle serial monitor to let CLI scan for the device or you look in Device Manager which port the OS assigned to it.
If the device is not recognised by Windows you probably have some driver issues.
which Windows version?
what state is the device in while scanning?
any idea what device OS version is on the device? some device OS versions didn't internally call Serial.begin() which requires that trick to work.
When I plug in an updated particle (e.g. deviceOS 1.4.4):
PS C:\Users\XXX> mode
Status for device COM7:
-----------------------
Baud: 9600
Parity: None
Data Bits: 0
Stop Bits: 1
Timeout: OFF
XON/XOFF: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: OFF
RTS circuit: ON
Status for device CON:
----------------------
Lines: 3000
Columns: 134
Keyboard rate: 31
Keyboard delay: 1
Code page: 850
I also pulled up device manager side by side my windows terminal and the COM port ond devie manager matches that displayed by the windows mode command. If your uncomfortable with this command, lets just go with device manager to reduce variables.
I've tried that. But both particle serial monitor and device manager do not show COM ports being added when I plug in a particle on an older device version. Without triggering/adding a COM port (or ACM port on linux) I am unsure how to get the 14400 baud rate to work. Unless I am missing something here.
My goal is to basically do a following:
Buy a few trays of particles
Plug them in into a powered USB hub fresh out of the trays (this means that the particles will be running whatever deviceOS they come with from the factory, you mentioned IIRC pre 0.8.0-rc27 since particle-cli USB commands do not work yet)
Run a script to update the deviceOS so a desired version for all the plugged in particles without manual intervention. Currently I am manually toggling the device into DFU mode via Mode/Reset buttons which is not scalable for large quantities.
Flash the desired firmware.bin
The particle CLI tool was newly installed this week (v2.0.1) and I had to run the stand alone driver installer in New Windows Drivers and general availability of mesh and USB CLI commands to get the CLI usb commands to work. The device seems to be recognized and the CLI commands work on newer device OS (i.e. I am able to run all particle usb commands, serial monitor etc..). So this seems to be fine for me.
My windows environment is Windows 10 Pro, x64, version 1909.
The device out of trays are in listening mode since their fresh from the trays. They are probably running thinker. These are brand new devices which I just pulled out from a tray of 50. They are completely not updated and not flashed in anyway.
With regards to the deviceOS, I am actually not too sure. Currently it is whatever deviceOS particle provides from the factory out of the box for its trays. I can contact particle support if need be to find this deviceOS version number or if you know how let me know I can try to find out. I know particle identify does the job but on these older deviceOS, the CLi commands dont seem to work =( .
The 14400 baud trick seems to work perfectly as long as a COM/ACM port is triggered and I can trigger serial monitor or some other form of starting serial (i.e. putty/screen/miniterm). Triggering the port to appear is where I am stuck on. Again, newer deviceOS models seem to work no problem.
I wouldn't think that devices bought now would come with a pre-release device OS installed, but maybe @marekparticle can provide some insight what versions are currently preinstalled.
Duh
When I tried mode with my Photon connected and it didn't come up with the COM port I wrongly assumed mode wouldn't do that, but I didn't realise that my selfpowered USB hub was not plugged into my computer (and I didn't check via DevMgr either)
You may need to show hidden devices in device manager in windows and delete all the com ports not currently in use. Windows sometime stops re-using ports and keeps adding new ones
The main point for this discussion lies in the ambiguity of which features will be present on an out-the-box device in order to streamline the setup process when you don't want to go through the mobile setup.
With Gen3 there were/are device OS versions that didn't provide a way to put the device into DFU Mode other than via the MODE button.
Then at some point the magic baud rate trick was reintroduced (after some friendly nudges from the Elite members).
Then at some even later point USB control requests were introduced (particle usb ...)
But when you buy devices from various sources you'll never know which you'll get and whether your setup scheme you came up in your PoC will also work on the new badge.
AFAICT the only sure to work approach for all Gen3 iterations would be via JTAG/SWD - which may be off-putting to some creators of middle size badges.
It would be good to have a guaranteed higher (than JTAG/SWD) level feature set out-the-box.
You have nailed and summarized what I want perfectly.
Another option is to just wait out until particle updates their device's out of box deviceOS versions. If I could get confirmation on when or if this is happening (someone from particle?), depending on the timeline it may be an option to just suck it up for now and wait it out instead of spending time solving a problem that eventually wont be there.
@ScruffR I've not touched JTAG/SWD at all but I'll put it on my list to take a look at. I'll need to buy the cables and connectors. But so far, USB has been great at solving everything so far. Would a good place to start be the link below?
I too have done something similar before which lead to go on a wild goose chase on why my devices werent detected. Partly the reason why my particle CLI + drivers are up to date now =)
I will try this later today. I am unsure if this will fix the issue since:
This shows the same characteristics on linux where ACM ports do not show up
Particles with newer deviceOS show up upon plug in, same computer, same usb port, no reboots needed or anything.
Just an update here, cracked opened some new Argons and Xenon units (yes I know mesh is dead). USB commands work on all of them just fine. It seems that out of all the 3rd Gen units, only the Boron 2g/3g units are flashed on an older deviceOS model that usb CLI commands do not work on.
@marekparticle do you know if particle intends to update the factory deviceOS in which devices are shipped?
Good morning @slacker89! We have been manufacturing Argons/Xenon on serial-capable >1.1.1 since thie summer - however, existing stock Argons/Xenons from earlier MFG dates are likely still working their way through distribution and retailers.
@marekparticle thanks. I guess after all this, I will stick with manually toggling devices to DFU via buttons and wait until particle runs through their stock with old factory devices. I shall not spend time solving a problem which has already been solved and will eventually make its way to me (hopefully soon). Its 2020 now so hopefully all their stock from last summer have been sold out =)
