Problem:
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)
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 Cellular.off() 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?
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.
Hello,
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.
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.
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.
