Have Boron/Xenon network running in the field. Initialized 2nd Boron connected to cloud, created new mesh network and added one Xenon. No problems. In VS Code, compiled and flash local with firmware 1.2.0-rc.1.1 and same code but device now flashes SOS - Red x 10. Put in DFU mode and reflashed with basic Blink or any other code indicates success, but still flashes red. Cannot put into listening blue mode. Holding Mode button, releasing Setup button results in Magenta->Yellow->White->rapid green which eventually goes back to red SOS sequence. Tried several Particle keys doctor and Particle keys server. Results indicated download success but no change in device behavior. Still flashes red. Suggestions?
Exact same thing happened to me yesterday with a boron. I re-flashed the latest bootloader and everything using the particle swd debugger, after which I was able to flash with boron cloud debug code, and now I just get:
deviceID=(removed but it was here and correct)
manufacturer=
model=
firmware version=
ordering code=
IMEI=
IMSI=
ICCID=
0000117150 [app] INFO: enabling trace logging
attempting to connect to the cellular network...
0000138303 [hal] ERROR: No response from NCP
0000138303 [hal] ERROR: No response from NCP
0000170553 [hal] ERROR: No response from NCP
0000170553 [hal] ERROR: No response from NCP
0000202803 [hal] ERROR: No response from NCP
0000202803 [hal] ERROR: No response from NCP
On a different (brand new) boron, I flashed tinker with 1.2.1-rc.1 and it connects to the cloud and then immediately starts blinking magenta and publishes spark/flash/status that it is updating (although I'm not sure why, it isn't part of any product) and reporting odd vitals like "-39kB of 32kB RAM used", and then eventually goes to safe mode and needs to be reflashed with an older deviceOS version to function again. The newer device remains recoverable, however I cant seem to get the old one going again. Unfortunately no suggestions, but you're not the only one!
Hi all,
We are aware of the SOS issue when upgrading Gen 3 devices (Argon, Boron, Xenon) devices from 0.9.0 or older directly to 1.2.1-rc.1.
We implemented a workaround in the cloud by forcing devices to update to Device OS 1.1.0 before going to 1.2.1-rc.1 when flashing through the Cloud.
If you have a device in a bad state, manually flash system part 1.2.1-rc.1 to your device to get it working again.
-
Download the correct system part for your device
Argon system part 1.2.1-rc.1
Boron system part 1.2.1-rc.1
Xenon system part 1.2.1-rc.1 -
From Workbench, run command
Particle: Launch CLIor open the terminal if you have the Particle CLI installed. -
Put your device in DFU mode by holding MODE and RESET, releasing RESET and holding MODE until it blinks yellow. It should then continue blinking yellow.
-
Flash 1.2.1-rc.1 to finish the update (edit the file name for your device)
particle flash --usb boron-system-part1@1.2.1-rc.1.bin
If your device also is in an offline state, you will need to flash the bootloader manually:
-
Download the correct bootloader for your device
Argon bootloader 1.2.1-rc.1
Boron bootloader 1.2.1-rc.1
Xenon bootloader 1.2.1-rc.1 -
From Workbench, run command
Particle: Launch CLIor open the terminal if you have the Particle CLI installed. -
Put your device in Listening mode by holding MODE for > 3 seconds until it blinks dark blue. It should then continue blinking dark blue.
-
Flash 1.2.1-rc.1 bootloader (with the --serial option) to finish the update (edit the file name for your device)
particle flash --serial boron-bootloader@1.2.1-rc.1.bin --yes
6 Likes
Thank you, this seems to have fixed most of the isses, however I am still getting [hal] ERROR: No response from NCP when running the boron cellular debugger, is it safe to assume this is an unrelated hardware issue?
@jvanier I had this issue and now my device is stuck in listening mode. Can I please get clear instructions on how to clear listening mode? I have tried device doctor and issue persists. Please Thank you.
I have a client that needs their Boron to work. We have purchased several to put in the field, but I need to get these working before I can put those in the field. Please help.
Hi @DREAM
On Gen 3, Listening mode can occur for a couple of reasons.
All gen 3 devices have a flag that tell them setup is done. This can be reset on full device resets. This is normally flipped by the mobile application when performing setup, but will not get flipped from CLI setup.
If your device is in this state, your best bet is to follow the CLI instructions for Marking Setup Done as noted in the CLI setup section.
Either flashing the temporary application once or following the CLI instructions using dfu-util should kick the device out of safe mode.
As an additional point (which does not apply to your Boron, but anyone who is seeing this on the Argon). If an Argon has no wi-fi credentials, it will also fall back into listening mode. For the Argon, it is important to both set the setup flag as done and provide at least one set of wifi credentials to your device.
New guy here, sorry for being dumb. What does it mean to "manually flash system part 1.2.1-rc.1?" Is this done from CLI via USB? Is 1.2.1-rc.1 the most current as of Dec 17? Or is this done via Particle Debugger? If Particle Debugger then what S/W is used? Thanks very much for any and all help in advance?
Exactly that, but we are now at 1.4.4
Is this done via the USB charge connector or via the Particle Debugger? Thanks very much
I moved this “double-post” here as it is already answered above - please don’t double post.
Boron flashing red and offline, cant get to listen mode, managed to get in DFU mode but "Particle Doctor" fails. "Particle update" works but still flashing red.
C:\Users\richardbl\boron>particle doctor
The Device Doctor will put your device back into a healthy state
It will:
- Upgrade system firmware
- Flash the default Tinker app
- Reset the device and server keys
- Clear the Wi-Fi settings
The Doctor will operate on your Boron connected over USB
You'll be asked to put your device in DFU mode several times to reset different settings.
Flashing the Device Doctor app
This app allows changing more settings on your device
Put the device in DFU mode
Tap RESET/RST while holding MODE/SETUP until the device blinks yellow.
? Select Continue when ready Continue
The Doctor didn't complete successfully. Error writing firmware: file does not exist and no known app found.
Please visit our community forums for help with this error:
https://community.particle.io/
C:\Users\richardbl\boron>dir
Volume in drive C is Windows
Volume Serial Number is 002A-984C
Directory of C:\Users\richardbl\boron
17-Dec-2019 10:01 AM .
17-Dec-2019 10:01 AM ..
17-Dec-2019 09:59 AM 41,916 boron-bootloader@1.4.4.bin
17-Dec-2019 09:59 AM 667,444 boron-system-part1@1.4.4.bin
17-Dec-2019 09:59 AM 11,692 boron-tinker@1.4.4.bin
3 File(s) 721,052 bytes
2 Dir(s) 129,545,330,688 bytes free
C:\Users\richardbl\boron>
C:\Users\richardbl\boron>particle update
Your device is ready for a system update.
This process should take about 30 seconds. Here it goes!
! System firmware update successfully completed!
Your device should now restart automatically.
C:\Users\richardbl\boron>
You may want to run particle flash --usb tinker -v too (before and after particle update -v).
1 Like
That worked, thanks so much!!! Now stuck in listen mode. 
Now what?
I used the iPhone app to reclaim it and the cloud then recognized as its old self, but its orphaned its Xenon. Need to make the Boron a gateway for the Xenon again. Can this be done via CLI?
particle mesh --help should get you unstuck.
Can a Boron that was the gateway for a mesh network be once again configured as such without using the iPhone app? Can it be done via CLI? If so how?
My boron was the gateway for a mesh network then had to be recovered from red flashing SOS. From listening mode I added it back with the iPHone app making it part of the orignal network…but the Xenon cant see it and its not a gateway here --> https://console.particle.io/networks/sevaomada
And again, the same question in another thread - hence I moved that here too 
I have a new Boron which had 1.4.4 OS. on it. I needed to downgrade back to 1.2.1 OS.
I started to go thru the serial CLI process and got the 1.2.1 bootloader on the device, then started the boron-system-part1@1.2.1.bin installed. Once that ended I went into the SOS 10 red flashes and now can’t seem to recover from that.
It’s stuck in the red flashing mode. I can get to the DFU mode (yellow flashing) but not sure what the next step is to get back to the listening mode.
Can you advise what I should do next… to put 1.4.4 OS back on the Boron or if possible keep 1.2.1 OS on it.
Thanks
I’m getting the SOS 10 blink now too, but no matter what the reset or holding combinations of mode and reset wont stop the red blinking… Whilst holding both mode and reset it will hold a while LED, but the second I release, it is back to red SOS…
On 1.5.4 rc1…
Happened after the Boron powered off from a low battery and when re-charged am now red blinky-blinky… 
1 Like
The same thing is now happening to me with a very new Boron v1.10 I was testing, which uses Device OS V3.1.0. It is now all the sudden in a permanent 10 blink SOS red state with no connectivity over terminal possible, neither serial, nor usb, nor dfu mode, nor start-listening. How does it happen that a Boron just randomly dies? If it was a power/surge event during my testing, why isn’t the whole board simply fried and not booting up? Has anyone else encountered Borons going into irrecoverable 10-blink red flash SOS states?