Particle Photon Error Please Try Running Setup Again After Resetting

Status LED - Xenon

You are viewing the Status LED and Device Modes for the Xenon. To view the documentation for other devices, use the blue device selector below the Particle logo on the left side of the page.

Standard Modes

These modes are the typical behaviors you will see from your device on a regular basis. They are the light patterns of a healthy device.

Here's the typical pattern of after power up.

Connected

When it is breathing cyan, your device is happily connected to the Internet. When it is in this mode, you can call functions and flash code.

OTA Firmware Update

If your device is blinking magenta (red and blue at the same time), it is currently loading an app or updating its firmware. This state is triggered by a firmware update or by flashing code from the Web IDE, CLI, or Workbench. You might see this mode when you connect your device to the cloud for the first time.

Note that, if you enter this mode by holding MODE on boot, blinking magenta indicates that letting go of the MODE button will enter safe mode to connect to the cloud and not run application firmware.

Looking For Internet

Connecting to the Cloud

When the device is in the process of connecting to the cloud, it will rapidly blink cyan. You often see this mode when you first connect your device to a network, after it has just blinked green.

Listening Mode

When your device is in Listening Mode, it is waiting for you to configure your mesh network, or is waiting for configuration by USB serial.

Normally, when you've successfully configured your Gen 3 device using the mobile apps for iOS or Android, the setup complete flag is set and you will exit Listening Mode.

If you have reset your configuration or have set up using USB, you may need to manually set the configuration done flag using these instructions to use the particle usb setup-done command.

To put your device in Listening Mode, hold the MODE button for three seconds, until the RGB LED begins blinking blue.

You can also use particle usb start-listening to enter listening mode.

Network Reset (fast blinking blue)

To erase the stored network settings on your device, hold the MODE button blinks dark blue, then continue to hold it down for about ten seconds longer, until the RGB LED blinks blue rapidly, then release.

For all Gen 3 devices it will clear the mesh settings and the setup complete flag, so the device will go back into setup mode (listening mode)
For the Argon it will also clear Wi-Fi settings.
For the Boron, it will also clear the cellular APN and SIM selection.
For Ethernet, it will also clear the using Ethernet flag.

If your device is breathing white, the mesh module is off. You might see this mode if:

You have set your module to MANUAL or SEMI_AUTOMATIC in your user firmware
You have called Cellular.off() or WiFi.off() in your user firmware

Safe Mode

Safe mode, breathing magenta (red and blue at the same time), connects the device to the cloud, but does not run any application firmware. This mode is one of the most useful for development or for troubleshooting. If something goes wrong with the app you loaded onto your device, you can set your device to Safe Mode. This runs the Device OS but doesn't execute any application code, which can be useful if the application code contains bugs that stop the device from connecting to the cloud.

The device indicates that it is in Safe Mode with the LED breathing magenta.

To put your device in Safe Mode:

Hold down BOTH buttons
Release only the RESET button, while holding down the MODE button.
Wait for the LED to start blinking magenta
Release the MODE button

Before entering safe mode, the device will proceed through the normal steps of connecting to the cloud; blinking green, blinking cyan, and fast blinking cyan. If you're unable to connect to the cloud, you won't actually end up with breathing magenta, but execution of application firmware will still be blocked - so you are in a "sort-of safe mode" (e.g. to enter "Safe Listening Mode").

The device will itself automatically enter safe mode if there is no application code flashed to the device or when the application is not valid.

You can also use the particle usb safe-mode command to enter safe mode.

DFU Mode (Device Firmware Upgrade)

If you wish to program your device with a custom firmware via USB, you'll need to use this mode. This mode triggers the on-board bootloader that accepts firmware binary files via dfu-util

Installation tutorial can be found here.

And a usage guide here.

To enter DFU Mode:

Hold down BOTH buttons
Release only the RESET button, while holding down the MODE button.
Wait for the LED to start flashing yellow (it will flash magenta first)
Release the MODE button

The device now is in the DFU mode.

DFU mode requires device drivers under Windows. These should automatically be installed by the Particle CLI installer, but if you think you are having driver issues, there are additional DFU troubleshooting tips here.

Some users have reported issues with dfu-util on a USB3 ports (typically the blue ones). Use a USB2 port if the USB3 port doesn't work.

You can also use the particle usb dfu command to enter DFU mode.

Firmware Reset

Gen 3 devices can store a backup copy of any desired user firmware in flash memory at address 0x80200000, separate from user flash memory which is located at 0x000D4000. This backup copy of firmware can be restored to user memory with a button sequence that is only available when the backup copy flash memory contains a valid firmware image.

To program your device with a backup copy of user firmware via USB, you'll need to put it in DFU Mode and run a command like one of the following:

Argon:

          dfu-util -d 2b04:d00c -a 2 -s 0x80200000 -D tinker-0.8.0-rc.25-argon.bin

Boron:

          dfu-util -d 2b04:d00d -a 2 -s 0x80200000 -D tinker-0.8.0-rc.25-boron.bin

Xenon:

          dfu-util -d 2b04:d00e -a 2 -s 0x80200000 -D tinker-0.8.0-rc.25-xenon.bin

You don't have to flash tinker, of course, that's just an example. Note that the d00c, d00d, or d00e varies depending on the type of device which is why there are three different commands.

To factory reset the user firmware after flashing valid firmware using the previous step:

Hold down the MODE button and tap RESET. The status LED will blink:

Magenta (red and blue at the same time, safe mode)
Yellow (DFU mode)
Fast blinking yellow (restore factory firmware)

Be sure to release the mode button as soon as you get to fast blinking yellow, otherwise you'll go one step farther and clear all of your settings as well.

Factory Reset

Gen 3 (Argon, Boron) devices from the factory somewhat ironically do not have a factory user firmware backup image installed. Thus it's best if you pre-install one using the steps above first.

To factory reset, hold down the MODE button and tap RESET. The status LED will blink:

Magenta (red and blue at the same time, safe mode)
Yellow (DFU mode)
Fast blinking yellow (restore factory firmware)
Fast blinking white (factory reset)

This will:

Restore the factory backup user firmware (if present)
Clear mesh credentials (1.5.2 and earlier)
Boron: Clear any saved APN and default to internal SIM
Argon: Clear Wi-Fi credentials
Ethernet: Clear the using Ethernet flag
Clear the setup complete flag, to force setup mode again

Troubleshooting Modes

These modes let you know about more atypical issues your device might be exhibiting. Use this section to troubleshoot strange colors you might see from your device.

Cloud Not Connected

When your device is connected to mesh but not to the cloud, it will be breathing green.

More information

I can't flash my device anymore

Breathing green means that mesh is on, but you're not connected to the Particle cloud. Because of this, you cannot flash your device from the cloud. That includes the Particle Web IDE, Particle Workbench, and Particle CLI cloud-based flashing commands.

Fortunately, you can usually get around this by entering safe mode, breathing magenta.

Hold down RESET and MODE, release RESET and continue to hold down MODE until the device blinks magenta, then release 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.

Cause 1: Blocking the loop

In this simple program, you'll breathe cyan, then about 10 seconds later, you'll go to breathing 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); }

Rainbows/Nyan

Using the Signal option in the Web IDE, or the particle cloud nyan CLI command, you can have a device's status LED display a rainbow pattern. This is handy if you have multiple devices nearby and are not sure which one is which.

Red Blink Basic Errors

Blinking red indicates various errors.

While connecting to the Cloud, the RGB LED will be blinking cyan followed by:

1 orange blink: Decryption error.
2 orange blinks: Could not reach the internet.
3 orange blinks: Connected to the internet, but could not reach the Particle Device Cloud. This sometimes is seen as yellow or red and indicates bad server keys.
1 magenta blink: Authentication error.
1 red blink: Generic handshake error. The device could have the wrong keys or has just encountered a generic error in the handshake process.

Repair instructions

Most keys related issues can be resolved using the Particle CLI.

Put the device into Listening mode (blinking blue) by holding down MODE until it blinks blue. Then issue the CLI command:

            particle identify

Save the Device ID; you'll need it later.

Then put the device in DFU mode by holding down both the RESET and MODE buttons, releasing RESET and continuing to hold down MODE until it blinks yellow and issue the commands below, in order.

            particle keys server particle keys doctor YOUR_DEVICE_ID

If you get this error under Windows:

            'openssl' is not recognized as an internal or external command, operable program or batch file.

it may work if you do:

            cd c:\OpenSSL-Win32\bin particle keys doctor YOUR_DEVICE_ID

There are additional tips for a missing openssl error on this page, including tips for macOS (OS X) and Linux.

Red Flash SOS

Is your device blinking red? Oh no!

A pattern of more than 10 red blinks is caused by the firmware crashing. The pattern is 3 short blinks, 3 long blinks, 3 short blinks (SOS pattern), followed by a number of blinks that depend on the error, then the SOS pattern again.

Enter safe mode, tweak your firmware and try again!

You can also reset your device to a known state by following these instructions.

There are a number of other red blink codes that may be expressed after the SOS blinks:

Hard fault
Non-maskable interrupt fault
Memory Manager fault
Bus fault
Usage fault
Invalid length
Exit
Out of heap memory
SPI over-run
Assertion failure
Invalid case
Pure virtual call
Stack overflow
Heap error

The two most common ones are:

Hard Fault (1 blink between 2 SOS patterns)

Some causes of hard fault include:

Using an invalid pointer.
Memory corruption caused by freeing memory twice, overwriting the end of a block of memory, etc.
Making Wire (I2C) calls without calling Wire.begin().

Exit (7 blinks between 2 SOS patterns)

This occurs if the standard C function abort() is called. In a Unix program, this would be used to abruptly stop the process. Device OS itself does not use this function, but the SOS can happen if user firmware calls abort() or _exit(). Since Particle devices only effectively support a single process, the user firmware, the effect is an SOS+7 and reboot. This could also happen if a library used abort().

Out of heap memory (8 blinks between 2 SOS patterns)

If your device crashes repeatedly with an SOS code, first try recovering with Safe Mode and flashing Tinker with the CLI to see if it was something recently added in your user application.

          particle flash <mydevice> tinker

Some tips for reducing the memory used by your firmware can be found here.

Assertion failure (10 blinks between 2 SOS patterns)

Assertion failure is triggered when a test for something that should never occur occurs, and there is no solution other than to SOS and restart.

Code might do this if the internal state is invalid and not what is expected, for example. Or something that should never happen and is non-recoverable, for example if the system thread cannot be created.

At the moment, all of the AssertionFailures are in things related to threads and the system thread, but that's just because those are the only things that have been instrumented with an AssertionFailure panic.

Stack overflow (13 blinks between 2 SOS patterns)

Stack overflow occurs when you try to store too much data on the stack. The size is quite limited, and storing large temporary objects on the stack can cause problems.

Main loop thread: 6144 bytes
Software timer callbacks: 1024 bytes

Heap error (14 blinks between 2 SOS patterns)

SOS+14 signifies:

Semaphore lock timeout
Since 0.8.0 60 seconds expired while trying to acquire a semaphore lock, likely due to dynamic memory allocation
Since 1.2.0 Other heap-related error, such as allocating memory from an ISR

Prior to 1.2.0, attempting to allocate memory from an interrupt service routine would sometimes work, and sometimes corrupt the heap causing the software to crash sometime later, while doing something completely different. Since this is very difficult to debug, now a SOS+14 is thrown immediately.

Some locations that are interrupt service routines:

ISRs attached using attachInterrupt
System event button handlers (just button_status, button_click, and button_final_click handlers, not all system events)
SPI transaction callbacks
SparkIntervalTimer library timer callbacks

Things you should not do from an ISR:

Any memory allocation or free: new, delete, malloc, free, strdup, etc.
Any Particle class function like Particle.publish, Particle.subscribe, etc.
Most API functions, with the exception of pinSetFast, pinResetFast, and analogRead.
delay or other functions that block
Log.info, Log.error, etc.
sprintf, Serial.printlnf, etc. with a %f (float) value.

Solid colors

Solid colors are rare. There only expected situation is:

Solid magenta if you are loading code in ymodem serial mode.

In most cases, solid colors are the side effect of a bug. If code crashes or infinitely loops with interrupts disabled, it's possible that the LED animation will stop. The color of the LED is the color it last was before failure. So for example, it could be solid cyan if it was previously breathing cyan, or solid red if it was trying to output an SOS pattern.

No status LED

If you power up your device and the status LED never comes on, you could have a missing or corrupted bootloader.

Unplug the USB (and battery, if you are using one)
Hold down the SETUP button while plugging in the USB power

If you still see no change in the status LED you probably have a missing or corrupted bootloader.

This can be corrected using a JTAG/SWD programmer if you have one. Otherwise, you should contact support.

boyleficese1965.blogspot.com

Source: https://docs.particle.io/troubleshooting/led/xenon/