Cannot Factory Rest Bluz


#1

After flashing code, my Bluz just kept flashing green but never connecting to the cloud like it did before.

I did a factory reset, everything looked like the steps described. The Bluz app says the board is connected, but Particle devices shows device with a flashing blue dot. The Bluz board keeps flashing yellow (I think) but nothing happens.

Is it bricked?


#2

Just wanted to add to the above that the board is either flashing yellow or a light green. Again, BluZ ios app shows board as connected. Particle devices shows board with a flashing blue dot.


#3


#4

OK, after trying lots of things, I got the board to flash a “true” green.

On power up, the board flashes green. It can also be seen in the Bluz app.

When I press connect, it shows as connected however it keeps flashing green and never hooks up.


#5

I tried flashing a different code and now I can see the board again and it is flashing cyan.

Why would a different code prevent it from hooking up?

My experience so far with Bluz has been negative. I may not know what I am doing but this board comes across as being half backed. For example, it does not support pulseIn and yet gives no compile errors …

I am really hoping this board will work but it looks like it is too much trouble. I am tempted to forget about it and just use a Redbear Duo but I do not know if it is any better!

Sorry for the frustration!


#6

Device ID: b1e2498099ac7bcc040efe56


#7

When you do a factory reset, the board is in Safe Mode, which means it will blink and stay yellow. Even when the device is online, it will blink yellow. So you can see the status of a Safe Mode device online, and if the Particle cloud tells you it is online, it probably is.

The code can certainly affect the connectivity of a board. With the Photon, there is a way to run code in different threads, but that isn’t possible really with bluz as the hardware has less resources. So all code is run single threaded. If your user code blocks the system firmware from running (infinite loop, etc) then the board can’t connect.

As for pulseIn, there are just some functions we don’t support yet, due to issues with the underlying architecture of the nrf51822 or other reasons. As I mentioned, the pulseIn can be affected by the radio, as it runs interrupts at the highest level which can affect the timing of the pulseIn function. There wasn’t a great way to resolve that issue with bluz, so we left it unimplemented. While I agree that the code shouldn’t compile and should present a user-friendly error, there is usually a good reason for those choices.

I am sorry for your frustrations, but bluz isn’t a Photon, and it wasn’t meant to be. There are always going to be things that bluz can’t do compared to a Photon, and there are things a Photon can’t do compared to bluz (try running a Photon on a coin cell battery, it won’t even start). Different boards have different strengths and weaknesses, they should be chosen for any project base on those.

Bluz will continue to improve as we update to newer versions of the Particle firmware and add more features ourselves. But the underlying hardware is restrained by a much smaller processor and much less RAM than the Photon, so there are limits of what we can do (until bluz2!). So please let us know if you run into issues, we can help and we try to make the transition as simple as possible from a Photon to bluz, but it is generally a good mindset to not think of them as completely interchangeable.


#8

Thank you Eric. I appreciate the detailed response and know that these things are not easy to do. Please forgive my frustration. I will look forward to getting my application to work.


#9

Hello @eric:

The Bluz board is rather sensitive to the code running on it and I often end up having to factory reset it.

If this is the only way to recover, what is the correct sequence to do so? I have read the docs and I am doing the following correctly (consistently) which is getting it to flashing yellow …

Now what happens next? Do I first flash the code that was working before? What about selecting the target firmware? I think I am not doing those steps correctly leading to a lot of time wasted and potentially bricking the board …

Thanks.


#10

There is a beta bootloader that we have that allows you to enter safe mode without a factory reset. It just wipes out the user app but leaves the system firmware intact. You can see details about it here: Beta Bootloader Testers Wanted

You are following the correct sequence. Safe Mode just means the board isn’t running any user code, but it is working just fine. So you can flash the code again that you are trying to work with. It may be good to review your code and make sure it isn’t blocking anywhere, but other than that you can keep trying new changes.


#11

Thank you @eric. This is good news.