[SOLVED] Lots of problems flashing code to Bluz DK


I’m having a lot of difficulty getting code to successfully flash to the bluz DK. I’m using a gateway board plus 3 Bluz DK (picture attached). I’m also using the gateway app running on a Motorola G4 (not pictured).

There seem to be a number of problems:

  1. The software gateway drops the connection to the bluz DK after a few seconds. With three of them, this means that I can almost never keep three connections going at once. I have tried connecting only one DK at a time but this seems to make no difference to the reliability.
  2. The hardware gateway doesn’t seem to allow me to flash successfully at all. I don’t think I’ve ever flashed a DK while it’s been connected via the gateway.

The DK boards are attached to power boards and running off a CR2032 coin cell. Is this likely to affect my ability to update the software?

Some more (random) information that may be of use:

The bluz DKs have identity:

  1. b1e2484e6d6502debb296…
  2. b1e24764dc238158cbae9…
  3. b1e24827728688c77cfa19…

One is older than the other two, which are recent. The photon on the gateway board is recent, and has ID 2f0022000851353531343431

I’m sure this level of flakiness can’t be right, but I can’t work out what it is I’m doing wrong. I’m using the online particle IDE to compile and flash. Please advise.


I should have added that I’m putting the DKs into “safe” mode with the two button reset sequence before trying to flash them. You can’t see from the picture, but the DK boards are blinking magenta (slow blink).


Is your gateway shield running the latest code? Not the Photon, but the gateway shield nrf51? You can check by going here: http://console.bluz.io/. If you don’t have the latest, you will see a big Update button to get the latest.

If you shut off two devices and connect only one, and don’t try to flash code to it, are you saying it disconnects? What happens to the RGB LED on the bluz DK? Does it go from green to cyan? Once it reaches blinking cyan slowly, what happens next?


Okay, the gateway did require an update, which seems to have completed. I’ll try re-flashing now and report what happens…


I re-flashed the gateway photon with the standard bluz gateway code, and --when it was breathing cyan-- tried to update the Bluz DK which are flashing magenta (after two button reset, one flash per second approx). The flash operation simply times out. I tried again with the software gateway on my phone. It still drops the connections frequently, and the flash did not succeed there either.

I’m going to set-up the gateways again from the tutorial example, and proceed from there. I have no trouble in flashing Photons from the web IDE.


Something new now. I set-up the gateway per the tutorial, and that all went fine, until the last stage when I transferred the Photon to the gateway. It did not breathe cyan and did not bring the gateway on line. Instead it is flashing blue (definitely blue, not cyan), about two-three times per second which, according to Particle’s documentation is “listening mode”.

So I used the particle app to reset the wifi credentials, and the gateway’s now breathing cyan. Since then I’ve successfully re-flashed one DK (out of about six attempts), using the software gateway. No luck whatsoever with the hardware gateway board.


Are you watching the Particle Dashboard when this happens? What events do you see?

You should use the bluz app to get all bluz updated to the proper version first. Updating through the hardware gateway is slow, and if you did a factory reset first, that means the cloud will probably update the system firmware which can take 5-10 minutes with the hardware gateway.

When you say the update times out, what do you mean by that? What was the RGB LED on bluz doing? Or did you see a timeout in the Particle dashboard?


By the bluz app I take it you mean the software version of the gateway that runs as an Android app? I have been using that, but was wondering whether the hardware gateway would have been a better choice. By time-out, I mean that the particle web IDE shows a “timed out” message some time after telling it to flash. I am seeing flash failures on the dashboard, but perhaps all these processes take much longer than I’m expecting…


The Web IDE isn’t the most reliable way of checking if an update works, I would definitely look at the dashboard and watch the events. You should see an event that says OTA Update Started when it works and Success when it successfully completes.

And yes, updates take much longer on bluz. System software updates with the app can take 1-2 minutes. With the hardware gateway, it can take 5-10 minutes. Factory resets will always require new system firmware, so every time you do one, you need to wait the above times.

BLE is just much slower, data rate wise, then WiFi. It is the tradeoff for it being so low powered. 95% of the time it doesn’t matter much since it is mostly used with small data payloads. But for OTA updates, it definitely is a noticeable difference.


Okay, thanks for the information Eric. I’ll try again with more patience! Does the update process survive the gateway dropping the connection, as that seems to happen often – certainly more often than every 5 or so minutes?


No, if the connection is dropped, the update would be interrupted. The connection really shouldn’t be dropping often, however. We have customers that have had these running months on end without drops.

When you say the connection drops, do you mean the RGB LED on bluz goes from cyan to green? How are you determining the connection dropped?

A few other questions:

  • How far away is the gateway from bluz?
  • Is there any large interference source (baby monitor, cordless phone, WiFi Access Point, etc) near any of the devices?
  • What code is running on bluz?
  • Are you sure the batteries on bluz are ok? We have seen a LOT of counterfeit batteries that come with little or no charge on them (I bought a 10-pack of CR2032’s on Amazon one time and they were all dead in the packaging). Can you measure them with a mutimeter?
  • Are you trying to connect with the app and gateway at the same time?
  • Is the Photon reliable connected to a WiFi back-end? Is there any issue with the WiFi or is it far away?
  • What is the LED on D7 of the gateway shield doing? Is it always blinking slowly? Or does it start to blink quickly sometimes after the first connection?


The connection between the smartphone running the software gateway and the bluz DKs is the one that’s dropping. I’m struggling to maintain a connection for a few minutes, never mind months!

To your other questions:
-The gateway is about two feet away from the Bluz DKs.
-There is a cordless mouse, and of course the laptop. No cordless phones, baby monitors, or wifi access points.
-The code is a modified version of the LED-BLINK code that sends a custom data message (“Hi” or some such).
-I replaced the batteries today; they’re Maxell brand and seem to be fine.
-The Photon seems reliable. The backend is a Draytek router that are very well thought of in the UK. It works
reliably with all our other applications. I have 3 Photons here and their performance with wifi is all about the same.
-LED D7 always blinks slowly (from memory). I shall pay it more attention now you’ve brought it to my attention.

It seems to me that OTA updating makes far more sense for the Photon with its wifi connection than it does for Bluz with BLE – you said as much in one of your replies to me. It’s perfectly possible for me to update the Bluz modules through a hard (wired) connection if I knew how to do that. Presumably I need a programming board and a JTAG programmer. Could you give me some details of the setup you use, or alternatively another that you know works. I have no previous experience of programming stuff via the JTAG port, so be gentle with your explanation!

edited to add:

I replaced the cordless mouse with a wired one, and kept the smartphone plugged into the charger. Both these things seem to have helped the reliability of OTA updates somewhat. I was struggling with an SOS code after OTA completed, but found from this forum that the problem was my use of Particle.deviceID which was being called too soon. Once I removed that, all was fine and I now have some Bluz DKs working as intended!


Glad to hear things have improved!

OTA updates can work quite quickly when only updating the user app, that should take only 10-15 seconds. The system firmware is much larger, so moving between versions of system firmware is what can take time. But switching system versions happens infrequently, you are updating just the user app most of the time, so OTA updates over BLE should be just fine.

You can read more about how our firmware works, and how to load it, here: http://docs.bluz.io/tutorials/updates/. There is a way to lot it over UART without a JTAG programmer. Or you could use a JTAG programmer if you like, but it can be a bit more complex.

What version of Android is the Moto G4 running? We can’t test with every Android handset out there, so it may be some strange behavior there. We try to stay up to date with getting some new handsets, or having our community try them out, so I will add this to our list to test with.

The wireless mouse could cause interference, though it should have been mostly mitigated by the BLE protocol. Could have caused some issues though, especially if it was close.

Certainly let me know if you continue to have problems or if things settle down, we are here to help!


Hey foo, would you have a breadboard lying around? if so, why not power the bluz DK from a more stable power source (5V) and then avoid any battery issues?
You may save the batteries while developing your project as well :slight_smile:

Regarding the gateway connection:
one thing that confused me A LOT at the beginning was that the bluz DK can only connect to one gateway, be it the bluz GW app on your phone or the bluz GW board.
All to say that I had to power off the bluz GW board so the bluz DK was “free” to connect to my phone (it would only see my phone) and then I would update the firmware on a stable connection.

Hope it helps!


Hi Gustavo,

I do have a breadboard, and that’s a very good idea – I’ll do that. I had realised that the Bluz can only connect to one gateway, so turn the hardware gateway off when using the Android app, and vice versa.

I’m now getting the Bluz DKs programmed more reliably and, by watching the Particle console as Eric recommended, I now know when the flash programming has completed. My problem now is that I have a call to Udp.sendPacket in the gateway code and it doesn’t seem to work. The same code works okay on a Photon (non-gateway), but fails when running with the gateway. Still working on that…



The Photon can only open so many socket connections at a time, it is limited to 5. So if you have three bluz DK connected, the limit is reached (one for the Photon, one for the nrf51 gateway, and one for each of the connected bluz boards.)

You can turn off the nrf51 gateway connection, that should give you an extra socket connection. To do that, you can use the same trick we use for an Electron here: http://docs.bluz.io/tutorials/local_communication/#electron-use

Just note, you won’t be able to OTA update the gateway shield itself with this set. You would have to turn off that setting to get updates working again.


Good point, Eric. I’ve updated the code but sadly the sendPacket still doesn’t work. Perhaps you could cast an experienced eye over it – I’ve attached it to this post. It’s a lightly modified version of your original gateway code – apologies for it looking a bit hacked at now. :slight_smile:

Google drive: https://drive.google.com/open?id=0BwJ_7Dsr3RVzN2Vwc3lHbVI4dXc

edited to add:

The error returned is -26. Offhand, any idea what that corresponds to – or alternatively, where I should look for it in the code-base?


Sorry for the delay. I am not sure what that code means.

So if you simply remove the gateway calls, or comment them out, does the code work? That could be something to try. Sometimes when copy+pasting code from one app to another I will miss a line and that can cause issues.

The gateway really should not interfere with opening a UDP socket, except as I mentioned that it will take up all available sockets so you can’t connect everything and still have it work.


Hi Eric,

I suppose I was hoping you’d spot something blindingly obvious that I’d done wrong! Without the gateway calls, the code works, although I’ve not been through it, commenting out line by line, which I’ll do now. What I did do was convert from UDP to TCP, just in case the error was confined to UDP operation. It isn’t – TCP doesn’t work either.


I can give this a shot as well, I don’t see anything obviously wrong. Let me get back to you a bit later with that I find.