Boron Breathing White after 5 min


5 minutes (approximately) after reboot the BORON goes into breathing white.
Boron remains in breathing white mode until reset button is pressed or power is reset

What I need help with:
Looking for suggestions as to why firmware drops outs of connected mode (breathing cyan) to disconnected mode (breathing white) and will not reconnect using either method:
Method 1: Automatic [SYSTEM_MODE(AUTOMATIC)]
Method 2: Manual [SYSTEM_MODE(MANUAL) + application issue Cellular.on(), Cellular.connect(), and Particle.connect() commands)

Background Data:
Firmware 0.8-r27
Power up. OTA update. Reboot with application. all work correctly.
I have a serial command line interface built into application.
Application continues to operate allowing me to issue commands to the BORON via PUTTY to USB
I have (4) 18650 batteries supplying power to unit in addition to the USB connection.
Diagnostics utility shows 4 bars signal strength with a 325ms roundtrip time

Expected Results:
Breathing CYAN mode, application allows me to publish events to cloud.
Application verifies that Particle.connected(), Cellular.ready(), and Cellular.connecting() are all TRUE
Breathing WHITE mode, application will not publish events to cloud
Application verifies that Particle.connected(), Cellular.ready(), and Cellular.connecting() are all FALSE

Unexpected results:
Issue Cellular.on() has no effect
Issue Cellular.connect() has no effect
Issue Particle.connect() has no effect
Changing system mode between AUTOMATIC, SEMI_AUTOMATIC, MANUAL has no effect
(I prepared 3 different compiled versions to test operational differences)

Thank you for your help.

That in deed is odd.

However, if you are not using SYSTEM_THREAD(ENANLED) you need to regularly call Particle.process() in SYSTEM_MODE(MANUAL).

Additional questions:

  • Are you using a Boron LTE or Boron 2G/3G?
  • Are you using the Particle or a 3rd party SIM?
  • How are you supplying the battery power to the device?
  • Can you share your test code?

Good morning,


  • Calling Particle.Process(); inside loop()
  • Boron LTE
  • Built in Particle SIM
  • (4) 18650 batteries (10,400mHr @ 3.7v)

Application code too big to share via this forum. (Compiler output says 25% / 30% memory space used (approximately))

Would need to email to you for review.

To reiterate the primary issue is that unit goes into breathing white mode, but issuing Cellular.on(), Cellular.connect(), and Particle.connect(), does not restart the cell and cloud connection.

Let’s assume that my application is causing the behavior. I’m not calling or Particle.disconnect()
Therefore, what application (behavior? Size? Loop update time?) would cause the firmware to drop the cell connection and not allow a manual restart?

Thank you for your reply

Are you able to replicate the issue with a minimal test code?

Don’t quote me on that and I’m not sure if a connection to your issue exists, but I think to faintly remember hearing something about an issue with the LTE ublox module that’s currently under investigation but due to it’s difficult replicability keeps slipping through the fingers.
Hence, if you had a reliable minimal test case that might help pinning it down, that would be greatly appreciated.

Here is the compiler output:
Output of arm-none-eabi-size:

text data bss dec hex
27556 184 6032 33772 83

In a nutshell:
Flash used 27740 / 110592 25.1 %
RAM used 6216 / 20480 30.4 %

From the web console:

This is a screenshot of the serial command interface of my application still running
with breathing white status, but non-responsive to Cellular and Particle function calls.

I have not downloaded a tinker application to see if the problem goes away because I am assuming that the problem will go away when I do.Ergo: nothing has been revealed as to the source of the problem. I have started by assuming that my application is causing this issue, but I would like some help determining what actions of my application would cause this firmware behavior.

Thank you again for any insight you can provide to resolve this.

Test results on 07-FEB-2019
Manually inserted Particle.process(); inside of loop() and set SYSTEM_MODE(AUTOMATIC);
Did not drop out.

Prior testing did not run Particle.process() with SYSTEM_MODE(AUTOMATIC);
Documentation specifically states that Particle.process(); is not required to be called in AUTOMATIC.
Only ran Particle.process() in SEMI_AUTOMATIC and MANUAL modes

Found other locations within the support forum that documented issues with SEMI_AUTOMATIC and MANUAL system modes, in addition to the SLEEP() mode function call not working.

I will consider this issue resolved on my end and wait for future update fixes to see if SEMI_AUTOMATIC and MANUAL modes work as documented.

Final Comment on this thread for others reviewing later.
This is my guess as to what the problem was, but it is just a guess to be confirmed by Particle team.

The documentation states that the in SYSTEM_MODE(AUTOMATIC) that the operating system performs the Particle.process() automatically during any delay of 1 second or after loop() is called.

My application has no delay() instructions in it, meaning that the loop() function repeats continuously without any delay long enough for the OS to automatically run the Particle.process().

Therefore, in the AUTOMATIC mode, I need to manually insert a call to Particle.process(); inside the loop() function.

It isn’t as long you are regularly (every few milliseconds) dropping out of loop()

That’s only the case without SYSTEM_THREAD(ENABLED).

Thank you for the clarification

I’m open to discussing alternative explanations for the observed behaviors.t

AFAICT this should not happen and I have no alternative explanation, so it all comes down to your specific code which may well have found an “exotic” combination of instructions to “exploit” a yet undiscovered bug.

So without seeing the actual code, not much I could think of.

@mstanley may have some idea who to hook you up with to discuss this further.

Hey Scruff, thanks for the ping.

In regards to the Boron dropping out and having difficulty reconnecting, this is a concern we have identified with some of our LTE devices and I believe we may have made some headway on the cause. I do not know of all the details or timetables for releases in regards to LTE issues, but I believe @BDub would be able to provide more insight on this.

These issues may lead to complications in some of the Cellular commands not behaving as expected. It is also possible some of the cellular commands may not be fully implemented yet. I believe @avtolstoy would be able to give more details on which commands are and are not implemented. He may also be able to shed some light on the unexpected SYSTEM_MODE behavior.