[SOLVED] Bluz GW Cloud permission issues -- cannot claim, rename or anything else


Ok, you seemed to have flashed the DK firmware to the gateway, that would explain why it doesn’t work!

The firmware and BLE stacks for the two are very different, one operates in peripheral mode and he other is central mode. Flashing the DK firmware onto the gateway won’t work.

You shouldn’t have to flash the keys, they are stored on the external SPI flash which is why you can’t find them internally.

What did you want to do? Why were you trying to reprogram the gateway?


It had stopped functioning, I think after flashing over the Build IDE, so I was hoping to get it back in the saddle. Am I outaluck or is there some steps I can take at this point?


What you want to do is flash over the gateway firmware. Are you building locally? If so, change your PLATFORM flag to bluz-gw, or if you are using PLATFORM_ID then change it to 269.

Do this in both the modules/ and bootloader/ folders. Then flash them to the device same way you did before, but change the SoftDevice hex file from s110 to s120.

That should recover the gateway to work in firmware.


Thanks I’ll give it a whirl. Just to be clear, I should declare APP=bluz_gateway (as well as PLATFORM=bluz-gw) when I compile from modules?


Yes, that is correct.

In general, you shouldn’t need to reprogram the boards with a JTAG programmer. If there is an issue with them, there are ways to recover it without fully reprogramming the internal flash. That can easily cause more issues as you end up erasing everything and are then just working with a bare-metal nrf51822.

You can of course do this if you want to, it just shouldn’t ever be a necessary step.


Following your guidance the P1 gateway is working fine now. Thanks a million!
Now gotta see if I can be as successful with the bluzdk


So for the DK, I assume you have followed a similar procedure of flashing new firmware to it with the JLink adapter?

The command you had sent me before should work just fine. If you have flashed it before, I would suggest a fresh build and flash of all four parts, hopefully that gets you back to a workin spot.

It is possible that the SPI flash was damaged or corrupted, but that would have required flashing bad systems or bootloader parts. Even if this did happen, we can recover the device, so just let me know.


This is what I tried with the errant bluzdk:
cd modules
make clean PLATFORM=bluz APP=bluz3test PARTICLE_DEVELOP=1 LTO=n
make all PLATFORM=bluz APP=bluz3test PARTICLE_DEVELOP=1 LTO=n
then copied all the hex files (system-part1, bluz3test {user app}, s110_softdevice) to the adalink folder
cd bootloader
make clean PLATFORM=bluz APP=bootloader PARTICLE_DEVELOP=1 LTO=n
make all PLATFORM=bluz APP=bootloader PARTICLE_DEVELOP=1 LTO=n
and copied bootloader.hex to the adalink folder and ran
python -m adalink.main nrf51822 --programmer jlink --wipe --program-hex system-part1.hex --program-hex bluz3test.hex --program-hex s110_softdevice.hex --program-hex bootloader.hex
which appeared to flash fine
the bluzdk starts off slow green then one blue blink then fast green. I power cycled the bluzdk and it went to slow green blink. I ran the bluz gateway android app and the bluz shows up as b1e2ffff… again and can’t be claimed. BTW, when I click connect in the app, the bluz starts blinking green at 2hz. Any notion what is to be done now?


The DK, if left for long enough, should Hangry color from blinking green when you try to connect. So it should start blinking green slowly, when you connect it should ha he to rapid green. If you leave it this way for 50 seconds, it should change to either cyan or magenta. Which does it change to?


clicking connect sometimes causes a quick one flash of blue then rapid green (2hz) then return to slow green (0.5 hz), where it stays at least for many minutes. Never cyan or magenta or red or orange


Did you make any changes to the system firmware?

If you flash a simpler user app, like tinker or even a blank one, do you see the same behavior?

The fact that it goes back to slow green makes me think it is actually rebooting, not that it is having issues connecting. It should always go to a different color if connection fails. That, or the gateway is disconnecting it.

If you connect through the bluz gateway, do you see the same “no other color” behavior?


I’m building on firmware-2.0.50-beta.2 and I made no changes to the firmware code
With the P1 gateway I get slow green, then one blue flash, then rapid green
When I adalink again but with the blinky app I get the same result witht the RGB. The D7 will blink while the rgb is slow then freezes on when the rgb goes to rapid green
then when I check the android app it’s still b1e2ffff… and error claiming device
Also in case it’s relevant, the BTN button seems to have lost functionality. Pressing reset stop the execution (no blinks) but pressing BTN and holding and then pressing rst does not enter bootloader mode (no magenta, no yellow)


It’s probably that the devices UICR register was erased when you used the --wipe option in the adalink command. The UICR register tells the system where to load the bootloader. It should point to the start of the bootloader, which is 0x3c000.

That is relatively easy to fix, it requires building the bootloader with an extra line. The reason we don’t do this by default is because of how the gcc compiler creates binary files. It would fill in all space between addresses 0x3c000 and 0x10001014 which makes the binary file 256MB!

Still, that wouldn’t cause the issue you are seeing. It still sounds like the device is rebooting and not having issues with connections. What gcc version are you using to compile? I assume you are on the latest ‘develop’ branch of code?

Could you possibly add some code to the setup() function to blink the LED on D7? This would prove/disprove my theory, if the LED blinks when trying to connect when the green blinking slows back down, it would prove that the device is rebooting during connection. This could be helpful to find the root cause.


gcc version 5.3.1 20160307 (release) [ARM/embedded-5-branch revision 234589] (GNU Tools for ARM Embedded Processors)
firmware-2.0.50-beta.2 (not develop)


I haven’t tested at all with gcc 5.3.1, I know the Particle folks are moving to it but we still use gcc 4.9.3. This is the version I recommend you use: https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update

Try a full clean/rebuild with that version and let me know if that helps. That could certainly cause the behavior you are describing


I added the following to setup:

for (int i = 0; i < 100; i++)
  if (ledOn) {
      digitalWrite(D7, LOW);
  } else {
      digitalWrite(D7, HIGH);
  ledOn = !ledOn;


and the rapid setup flashing of D7 did NOT appear with android app connect attempts, but when I close the android app and wait 30 seconds to a minute the slow (loop()) D7 blinky comes back. The rapid D7 blinky one would see with reboot did not occur.
I have another machine with 4.9.3 on it and will try that later tonight if possible



I used the 4.9.3 gcc version to compile and then flashed with adalink/jlink to the bluzdk and this yielded the same behavior. When the android app connects the D7 blink stops and the the id again comes up as b1e2ffff…
I can give up on this bluzdk without any regret :slight_smile: if it’s time has come and gone… although it is an interesting puzzle.


There is still a way to recover the board, we just need to re-run the factory programmer script.

This is available to anyone who wants it, but we don’t make it public so as to avoid issues and confusion. @bpr if you send me your GitHub username (privately if you would like) then I will grant you access.


Hi @eric ,
thank you very much for your support!

I have a ST-Link/v2 and a J-Link shield but I have never used them :slight_smile:


Thanks. If you can send me your GitHub username ( me if you would like to keep it private), I can get you setup with the recovery method.