I noticed that when I flashed my application with a sample code for AdaFruit’s NFC module, it breathes cyan first but within a minute or so switches to breathing green. Any thoughts on how I could troubleshoot and figure out why the cloud connection is disconnected?
The code that is causing me trouble is right here. https://github.com/knspriya80/adafruit-nfc-photon
I flashed another application that just reads analog inputs from sensors and that worked fine and did not cause the cloud connection to be disconnected. Any pointers will be appreciated.
@knspriya, a breathing green LED means that wifi is connected but not cloud (breathing cyan). Without system threading enabled, the Photon requires that the “background” process be allowed to run at least once every 10 secs or the cloud connection will be lost. This can be done by allowing loop() to “end” or by calling Particle.process().
If you look at the demo code you are trying to run, you will see some while() statements preventing loop() from exiting. The first waits for Serial.available() while the next waits on !versiondata. You need to add a call to Particle.process() in both those while statements. Give that a shot and let me know how it goes.
Note that in the near future, with system threading fully supported, the wifi and cloud connections will be maintained in the background without the need for user intervention. 
2 Likes
@peekay123, thanks for coming to the rescue, as always :-). I will try that out tomorrow and report back. Interesting, I didn’t need this modification when I tried the same code a couple of months back earlier. The only thing that has changed is that I now have the Photon on a PCB with additional NFC Circuitry.
As a side question, does the particle web IDE ever force a firmware update on the Photon? I did not change the firmware and would like to verify that its the same version with which it was shipped. Is there a CLI where I can explore these things further?
Never mind, looked through the forums and looks like a firmware update was done automatically when I flashed the build using the WebIDE. Now comes the question as to what changes were done that requires user calling Particle.process() now. :-).
@knspriya, in your code you called SPARK_WLAN_Loop() which is the “old” Particle.process(). This function has been deprecated in the new firmware. HOWEVER, note that in your code, SPARK_WLAN_SETUP is not defined so SPARK_WLAN_Loop() is never called!
No changes were made in the 0.4.6 firmware that require you to call Particle.process() more often. Rather, we detect when particle process hasn’t been called and change the LED color to reflect that, since the cloud will have already disconnected the device by that point.
If your app does eventually resume then the cloud will automatically connect again.
So look for code that is blocking loop. Alternatively, add SYSTEM_THREAD(ENABLED) to the top of your sketch to enable multithreading.
1 Like
And this is the answer to a similar issue I am currently seeing in the generic Adafruit_PN532 library Ive been working on .
Now I suspect thast as I can connect to the Photon via USB via Particle-CLI I can just flash it with another .bin downloaded from the cloud and then it will reconnect.
Just to confirm that I resolved the cause of my own issue in the Adafruit_pn532 readmifareClassic example it turns out that the code to check for Serial Availability was constantly failing. So I commented it out.
// this is not useful feature to loop around …
while(!Serial.available()) {
#ifdef SPARK_WLAN_SETUP
SPARK_WLAN_Loop(); // Open serial terminal and Press ENTER.
#endif
Serial.println("Serial was not available\n");
}
Effectively this code never completed so the process never responded on the serial; despite printing out that Serial was available;
Somewhere between making better use of Particle.process and reducing loops which can run infinitely I got myself out of a hole in which I could not get the photon online.
So I am leaving this lesson learned here just in case anyone else stumbles upon the issue in the future and wonders what I did next.
This is a useful construct during debugging to ensure you really catch all serial output, but sure enough for production use it should be commented out 
This waits for the user (debugging person) to hit any key in serial monitor to indicate: "Now I'm paying attention, go on ..."
Good point; I’ll add my comments and I pulled up the debug by picking up the serial.println in the loop then deciding to comment it out to keep the code falling forward.
This was exactly my problems. I thought my devices were bricked but saviour “particle flash --usb tinker” from the particle-cli and all back.
2 Likes
Since this thread has been brought to the surface again, I’ll add my breathing green tip sheet:
Particle Breathing Green Tips
Breathing green mode can be confusing to new Particle programmers but fortunately it’s usually easy to recover from.
I can’t flash my Photon anymore
Breathing green means that Wi-Fi is on, but you’re not connected to the Particle cloud. Because of this, you cannot flash your Photon from the cloud. That includes Particle Build (Web IDE), Particle Dev (Atom IDE) and Particle CLI cloud-based flashing commands.
Fortunately, you can usually get around this by entering safe mode, breathing magenta.
Hold down RESET and SETUP (or MODE), release RESET and continue to hold down SETUP/MODE until the Photon/Electron blinks magenta, then release SETUP/MODE. The device will then go through the normal sequence of colors: blinking green, blinking cyan, fast blinking cyan, then breathing magenta. Once breathing magenta, you should be able to OTA flash again.
But to get rid of the breathing green, you’ll probably need to make some changes to your code.
Do not unclaim your device
This rarely if ever fixes anything, and it sometimes can make things much worse. Resist the urge to do this. It never fixes a blinking green problem.
Cause 1: Blocking the loop
In this simple program, you’ll breathe cyan, then about 10 seconds later, you’ll go to blinking green. Why? You’ve blocked the loop from returning, and in the default threading and system mode, that stops the cloud from being processed, which causes breathing green.
Don’t do this:
void setup() {
}
void loop() {
// Don't do this: preventing loop from returning will cause breathing green
while(true) {
}
}
Of course your code probably has a more subtle bug than that. For example, if you have a function that’s called from setup or loop that never returns, that can cause problems.
Some libraries that deal with sensor hardware might behave strangely when the hardware is not available, which could cause a call to block forever as well.
Solution 1: Add some Particle.process() calls
One way to solve this is to sprinkle Particle.process() calls in code that blocks. You might do something like this:
void waitForSwitch() {
while(digitalRead(D7) == HIGH) {
// Without the following line, you'd go into breathing green
Particle.process();
}
}
In general it’s better to structure your code so it always returns from loop(), but if that’s not a viable solution, you can sprinkle some Particle.process() calls in your code.
Solution 2: Enable SYSTEM_THREAD
The other solution is to use SYSTEM_THREAD mode.
SYSTEM_THREAD(ENABLED);
You insert this at the top of your source file. What it does is run the cloud processing in a separate system thread, so if you block your loop, the cloud will still be serviced and you will stay in breathing cyan instead of going to breathing green.
The only thing to be careful is that when you do this, your loop code will run before connected to the cloud. One solution is to add this in your setup() code, before you do any Particle.publish calls:
waitUntil(Particle.connected);
You might also do something like this in loop():
if (Particle.connected()) {
Particle.publish("myEvent", PRIVATE);
}
Side note: Wi-Fi only mode
While all of the causes above were unintentionally causing breathing green, you can also do it on purpose. Using the SEMI_AUTOMATIC or MANUAL system mode and only bringing up Wi-Fi and not the cloud will cause intentional breathing green. You would do this if you’re sending data to a local server and not using the cloud at all, for example.
2 Likes
Good day
I am currently having a similar problem with my photon. Its breathing green and when i try to enter safe mode using the solution 1 its blinking orange (part yellow part red). I am new to particle and an a novice programmer. I had done few simple projects with the arduino uno but nothing involving SPI or I2C communications. i have no idea how to restore the operation of the microcontroller. i have been sitting with this problem for 2 hours after trying to upload the following code to the photon:
//Portable Weather Station: BME280
#include <Wire.h>
#include <SPI.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>
#define BME_SCK A3
#define BME_MISO A4
#define BME_MOSI A5
#define BME_CS A2
#define SEALEVELPRESSURE_HPA (1013.25)
//Adafruit_BME280 bme; // I2C
Adafruit_BME280 bme(BME_CS); // hardware SPI
//Adafruit_BME280 bme(BME_CS, BME_MOSI, BME_MISO, BME_SCK);
void setup() {
Serial.begin(9600);
Serial.println(F("BME280 test"));
// if (!bme.begin(0x76)) {
if (!bme.begin()) {
Serial.println("Could not find a valid BME280 sensor, check wiring!");
while (1);
}
}
void loop() {
Serial.print("Temperature = ");
Serial.print(bme.readTemperature());
Serial.println(" *C");
Serial.print("Pressure = ");
Serial.print(bme.readPressure() / 100.0F);
Serial.println(" hPa");
Serial.print("Approx. Altitude = ");
Serial.print(bme.readAltitude(SEALEVELPRESSURE_HPA));
Serial.println(" m");
Serial.print("Humidity = ");
Serial.print(bme.readHumidity());
Serial.println(" %");
Serial.println();
delay(2000);
}
This is code from the adafruit BME280 library which i amended to make it applicable to the photon using the particle dev. Please help.