Bluz with no lights


I have this problem occurring sometimes after flashing a new program. The Bluz LED does not light up. Everything gives the indication of a dead board until I reset the firmware. I usually then flash a simple sketch, upgrade the firmware then flash my program again. This is time consuming and cumbersome. Is there a less draconian way of getting the board back when this happens?

I tried a simple press on one of the two buttons on the board and this does “wake up” the board.

Also, System.reset() causes the LED light to disappear. Sometimes, even a power disconnect does not solve the problem. Waiting a little after disconnecting power sometimes works but is not practical in remote installations.

What is potentially causing this behavior? BTW, sometimes I also get 8 flashing red light sequences after an SOS. I did look it up (System tried to enter an invalid state) but not sure what it means?

Thanks in advance.


We do have a way to force the board to enter safe mode, much like the Photon. This doesn’t require a full system reset, it only wipes out the user app and then allows you to reflash your code on top. The system firmware always stays in place, so you should have an easier time reflashing new code.

This feature was never made generally available, but it is something i can give you access to if you would like. It is quite easy to upgrade a board and then you will have it forever on that specific board.

The SOS code of 8 is generally when the system tried to do something that isn’t allowed. For example, if it is trying to use some functionality with BLE that isn’t allowed given the current state. Does this happen with specific code?


Thanks @eric. Please let me know how I can use safe mode.

The flashing red (I think) is heavily dependent on where the CallBack code is located. The firmware apparently likes to see it as early as possible after starting.

You did not tell me though why the strange behavior of no LED and why System.reset() sometimes does not restart the board. Is there a better way?



I added you to the Beta group, so you can now view this post for instructions on how to load the bootloader:

I am not sure I understand the other two issues, are you using coe to turn off the LED? As for System.reset(), that should always reset the device. Can you outline what you are doing, and why you suspect this isn’t happening?


Thanks @eric for adding me to the group.


No, what I meant to say is that sometimes the LED (on its own) stops showing any light until I press the reset button to cause the board to restart.

On the last issue, what I meant was that executing


sometimes does not cause the board to restart. Is there a better way to simulate pressing the reset button? This is very important in my applications because changing some Particle variables OTA requires the board to restart.


The LED should not turn off unless the user code specifically does so, or the board is no longer powered on. There is a system software timer that maintains the LED and also does other system specific items (like reset the watchdog timer). So unless that software timer is being interrupted (which user code should not be able to do) it should be working. Are you using any RGB commands?

As for system reset, it should always result in a soft reset. Are you certain the line of code is always being reached? How are you verifying the board isn’t resetting?


Thanks @eric.

  1. I am definitely not using and RGB commands (did not even know they existed …).

  2. I am sure System.reset is reached because the LED changes color but the board can never be reached again by the phone unless the reset button is physically pressed or power is recycled.


There are probably a lot of possibilities here depending on user code. Can you narrow down the problem to the minimal amount of code to reproduce it and post it here?


Thanks @eric but once I reduce the code, the problem disappears! It only happens with a sketch that is big enough.