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


#1

Hello

This was all working before. But now, for reasons unknown to me – although I did re-flash the NRF51 module on my Gateway Shield (most recently with gateway_firmware_4-17-16) – and the Gateway Shield does appear to be operating correctly – I am now unable to claim or do anything else with my Bluz Gateway Shield module.

For example[s] …

$ particle device remove b1e2fffff8e4a7be5572f1ee
Are you sure?  Please Type yes to continue: yes
releasing device b1e2fffff8e4a7be5572f1ee
Didn't remove the device Permission Denied

… and …

$ particle device claim b1e2fffff8e4a7be5572f1ee
NAME:
particle device claim

… and …

$ particle device rename b1e2fffff8e4a7be5572f1ee bluz_gw
Renaming device b1e2fffff8e4a7be5572f1ee
Failed to rename b1e2fffff8e4a7be5572f1ee, server said undefined

… and …

    $ particle core add b1e2fffff8e4a7be5572f1ee
    Claiming device b1e2fffff8e4a7be5572f1ee
    Failed to claim device, server said: [object Object]

… and finally …

HOWEVER …

The Gateway itself seems to be connecting to the cloud OK and is passing data back and forth with the NRF51 module …

...
47952:DEBUG: Processing message of size 13 with clientID 3 and service ID 2
47952:DEBUG: You''re gateway ID is b1e2fffff8e4a7be5572f1ee
...
2591384:DEBUG: Handshake complete
2591386:DEBUG: Receiving SPI data of size 28
2591386:DEBUG: Reading chunk of size 28
2591389:DEBUG: Processing message of size 25 with clientID 3 and service ID 1
2591389:DEBUG: Connecting Client3
2592155:DEBUG: Read length = 23
2592157:DEBUG: Starting to send data
2592207:DEBUG: Completed Sending
2592208:DEBUG: 3->BLE    - 45
2593942:DEBUG: In SPI Receive
2593942:DEBUG: Handshake complete
2593944:DEBUG: Receiving SPI data of size 261
2593944:DEBUG: Reading chunk of size 255
2593951:DEBUG: Reading chunk of size 6
2593953:DEBUG: Processing message of size 258 with clientID 3 and service ID 1
2593954:DEBUG: 3->Cloud  - 256
2593954:DEBUG: Read length = 256

Flumoxed, again! :stuck_out_tongue:

Thanks in advance … again! :wink:

Gruvin


Conflicting device IDs
Bluz DK corrupted device ID
How to Flash NRF51 on Gateway Shield
#2

It looks like the external SPI flash got corrupted or erased somehow. Every bluz ID starts with b1e2 and is then followed by a unique 4 character hex string that gets assigned when we provision. Instead, your board is reporting that ID as ffff, which isn’t correct. The log actually indicates the device isn’t connecting either, the 256 to the cloud should be followed by 384 bytes back down but I don’t see that. Most likely this is caused by the wrong ID.

So the device ID is wrong which is why you can’t claim or otherwise access the device.

How did you program it? Can you send me the exact command you used? Did you flash it Over the Air? Or use JTAG somehow?


#3

@eric … goodness me. :-/

EDIT: Since writing the below (still relevant, I think?) I have managed to get myST-Link v2 connected and working under adalink. I have now successfully re-flashed the 4-17-16 firmware (as below) using SWD. Of course, that doesn’t mean I was able to set a GUID in the Flash.


Hmmm … well, first I put the Gateway Shield into setup mode, by grounding D6 for 5 seconds after power-up. This is using 3.3V USB serial, connected to GND/RX/TX per the documentation.

Then …

$ cd ~/Desktop/gateway_firmware_4-17-16
gateway_firmware_4-17-16$ python ~/Desktop/update_fw.py -s /dev/tty.usbserial
Namespace(port='/dev/tty.usbserial')
Welcome to bluz serial programmer!
Enter the firmware filename: system-part1.bin
Writing file contents to serial
Wrote size
Got size back: 95372

All seemed to go OK.

I haven’t had anything remotely JTAG even connected to it, yet. :-/

So I just went through that all again, as above. No change …

4498:DEBUG: Handshake complete
4500:DEBUG: Receiving SPI data of size 28
4500:DEBUG: Reading chunk of size 28
4503:DEBUG: Processing message of size 25 with clientID 3 and service ID 1
4503:DEBUG: Connecting Client3
5028:DEBUG: Read length = 23
5030:DEBUG: Starting to send data
5080:DEBUG: Completed Sending
5081:DEBUG: 3->BLE    - 45
7079:DEBUG: In SPI Receive
7079:DEBUG: Handshake complete
7081:DEBUG: Receiving SPI data of size 261
7081:DEBUG: Reading chunk of size 255
7088:DEBUG: Reading chunk of size 6
7090:DEBUG: Processing message of size 258 with clientID 3 and service ID 1
7090:DEBUG: 3->Cloud  - 256
7091:DEBUG: Read length = 256
25029:DEBUG: Asking for id
25029:DEBUG: Starting to send data
25079:DEBUG: Completed Sending
47088:DEBUG: In SPI Receive
47088:DEBUG: Handshake complete
47090:DEBUG: Receiving SPI data of size 16
47090:DEBUG: Reading chunk of size 16
47093:DEBUG: Processing message of size 13 with clientID 3 and service ID 2
47093:DEBUG: You're gateway ID is b1e2fffff8e4a7be5572f1ee
47093:DEBUG: Read length = 11
49115:DEBUG: In SPI Receive
49115:DEBUG: Handshake complete
49117:DEBUG: Receiving SPI data of size 28
49117:DEBUG: Reading chunk of size 28
49120:DEBUG: Processing message of size 25 with clientID 3 and service ID 1
49120:DEBUG: Connecting Client3
49826:DEBUG: Read length = 23
49828:DEBUG: Starting to send data
49878:DEBUG: Completed Sending

Note the rather long delay between requesting and (allegedly) receiving the device ID. I cannot recall if that is normal or not.

So, how do we reset that ID? I’m guessing I’ll have to directly program the external Flash chip? Yikes.

Gruvin


#4

@eric … I’ve since tried this …

adalink \
  nrf51822 \
  -p stlink \
  -w \
  -b ${PWD}/int.bin 0x3F000     \
  -h ${PWD}/bootloader.hex      \
  -h ${PWD}/s120_softdevice.hex \
  -h ${PWD}/system-part1.hex    \
  -h ${PWD}/tinker.hex

… where the file int.bin contains two bytes, 0x12 and 0x34.

But the Photon gateway script still reports …

26108:DEBUG: Asking for id
26108:DEBUG: Starting to send data
26158:DEBUG: Completed Sending
48191:DEBUG: In SPI Receive
48191:DEBUG: Handshake complete
48193:DEBUG: Receiving SPI data of size 16
48193:DEBUG: Reading chunk of size 16
48196:DEBUG: Processing message of size 13 with clientID 3 and service ID 2
48196:DEBUG: You re gateway ID is b1e2fffff8e4a7be5572f1ee

I’m lost. I’ll need to learn more about the ID provisioning and so on. I’m not even sure that’s the actual problem, at this point. Maybe something more to do with however the, “Asking for ID” process actually works? Maybe that’s failing and simply returning the 0xffff, when in fact that’s not the case?

Oh and, yeah. I guess I’ve blown away my keys as well. But that’s not relevelent right now, considering the Particle cloud cannot even recognise my device.

Last but not least …

$ adalink nrf51822 -p stlink -r16 0x3F000
0x3412

*shrug*

I’m going into surgery tomorrow. It’s a minor procedure, back home same day. But I might not be able to do much more on this with you for a while. See how we go.

Thanks again for all your help. Sorry I managed to break it, somehow!

Gruvin


#5

I am pretty unsure how this managed to break, but I know we can get it fixed! The only code we have that writes to that location in the external SPI flash is the provisioning bootloader, so I am unsure how it would have gotten erased. You could be correct that perhaps the SPI flash is ok, but the code to fetch it is wrong.

Just to make sure, there wasn’t any physical damage done to the board, correct? If the SPI flash somehow came loose or a connection broke, this could also cause the behavior.

If that isn’t the case, let’s try and load the newest firmware for the gateway. You can access it here: http://console.bluz.io/firmware/latest/system-part1.bin

Try the same procedure as last time, short D6 to ground upon boot for 5 seconds, then run the Python script.

If that doesn’t work, we have the exact script we used to provision the boards up on the GitHub beta page. It requires the use of a JTAG programmer and adalink, but it looks like you have those two things running.

I assume 3412 was the old part of the ID? If not, I can probably search for it. We would just need those four numbers so we can reprogram everything back to the way it was.

In terms of recreating the problem, I am going to try and do this to see how it could have broken (or if somehow we posted the wrong build of something somewhere). The procedure is identical to bluz DK, and with the now thousands of boards we have shipped I have not seen this before. We’ll get to the bottom of it though!


#6

Thanks again @eric

I wouldn’t be too concerned about using your time trying to replicating my unusual issue at this stage.

Board has not been damaged and, so you’re aware, I am fully equipped and skilled to deal with SMD reflow and so on. (Promise I have not done so tho! :-P) I’ve built several PCBs, down to 0402 bits. It’s a very satisfying exercise.

Anyway, 3412 is just a random (0x12, 0x34 byte order) code I tried, to see if the GW debug output would at least change from ffff. So that is the code I read from 0x3F000 now … even though the ID request on the Photon log output still shows ‘ffff’.

My guess was that the bootloader is responsible for checking the SPI Flash against the code at 0x3F000 and rewriting it if it’s blank or different. I need to go read the code to confirm this. But if I’m right, then we may indeed have some kind of HW fault. Can’t imagine how. Then again, though rare, it certainly wouldn’t be the first time the unimaginable happened on a PCB in my possession. :blush:

I’ll let you know what else I find, once I’m back home and able.Looking forward to your comments re the above in the meantime. :wink:

Gruvin


#7

Thanks. Using adalink, you are checking the internal flash of the nrf51. The ID is stored on the external SPI flash, which you can’t access through SWD. The only time we write to it is when we provision.

I think if we ran the provisioning script, it will work just fine again. This is how we provision boards internally, and how we updated beta boards in the field.

The script can be found here: https://github.com/bluzDK/bluz-beta/tree/master/gateway/gateway_programmer

I will get you some better instructions. We use a very similar script for the DK, and the instructions for that are here: https://github.com/bluzDK/bluz-beta/tree/master/programmer_release

The only real difference between the gateway and the DK version is that the gateway version doesn’t use Serial and the behavior after you run the script is a little different. I will check the logs to try and figure out what ID your gateway was provisioned for and DM it to you.


#8

Thanks @eric

That gw provisioning code is where I learned of the 0x3F000 address. I figured that must be how it worked. Thanks for clarifying that the provisioning bootloader is different to the run time version, too.

I couldn’t run the provisioning script, simply because of an issue I will resolve around my hodgepodge adalink install. I ran out of time was all.

Only a 16-bit GUID? I’m sure I’m missing one last piece of that puzzle. :wink:

Cheers


#9

Hello again @eric

Well I’m home and supposed to be in bed. But hey …

OK. So I took the latest version or the programmer firmware etc from the link you gave: https://github.com/bluzDK/bluz-beta/tree/master/programmer_release

The programmer.py script will not work for me because I cannot claim my bluz-gw module yet, since it doesn’t have a valid id. Therefore, I also cannot send new keys tot he cloud – “Permission denied”. However …

To get around this, I have the programmer.py script quit just after creating the new keys and renaming the .der file to a .bin, for flashing. This now exits to the command prompt, having created int.bin from bluz_id.txt and with the new key’s files still in place (not yet deleted or moved.)

I then manually execute the following, from the gateway_programmer folder, which contains said keys, thusly …

adalink \
  nrf51822 \
  -p stlink \
  -w \
  -b int.bin 0x3F...    \
etc

The flash runs OK, with a resounding exit code 0. I unplug the ST-Link and power cycle the gateway board.

So at this point, I should have my new (bogus 0xABCD, this time) ID and some (not yet useable) keys stored in SPI Flash. OK, then let’s … re-flash with the runtime gateway_firmware_4-17-16 using …

adalink \
  nrf51822 \
  -p stlink \
  -w \
  -h bootloader.hex      \
  -h s120_softdevice.hex \
  -h system-part1.hex    \
  -h tinker.hex

That went fine, just as before. So now, I install the Photon with the gateway sketch … and … !@#!! alas …

46987:DEBUG: You're gateway ID is b1e2*ffff*f8e4a7be5572f1ee

Without digging into the actual code that writes and read the SPI Flash, I think at this stage I must have a hardware fault.

Unless you have any better ideas, I think the best way to get past this point I think is for me to just buy another gateway board or two. I’ll do that, when I feel a bit better after my op and stuff.

Some time between now and that arriving, I’ll haul out the logic analyser and see what’s actually happening on the Flash chip’s SPI signals. If that looks good, I’ll order a few of those chips and replace this one … or I’ll bin it and just wait for the replacement.

Don’t sweat it. Stuff happens. I’m cool with it. It is what it is and all that good stuff.

Gruvin.


#10

@Gruvin Actually, that sequence wouldn’t have properly programmed the hardware with the ID. I am going to DM you to get this resolved, need to ask for email address and such so don’t want to publish that out here in the open.


#11

@eric
I seem to have gotten into the same boat as @gruvin did, in my case both with a bluzdk and a p1 gateway, where the device id for the bluz part shows up as b1e2ffff… I have no idea what I did to cause this. Is there a fix? I have a jlink edu as well as ft232 and have been unsuccessful in my attempts to resusitate either device using adalink and the programmer.py


#12

I have the same problem like you and I am also looking for a How-To to revive my BluzDK


#13

@hl68fx and @bpr: Can you provide more details? For example:

  1. How many devices have you seen this on?
  2. Did the device work and then stop working?
  3. Where do you see the b1e2ffff reported for bluz? iOS or Android App?
  4. Where do you see the gateway id reported improperly? The console?
  5. Does the device still connect to the Particle cloud? Or does it just blink magenta when you try to connect? If possible, can you try to connect it with the opposite OS app (so if you had been using Android and have access to an iOS device, does that work?)
  6. For the gateway, does it still allow devices to connect through to the cloud? Or does the white LED just blink rapidly all the time and it will never connect?
  7. What firmware version were you running on? Had you performed factory reset? Had you tried to flash firmware to bluz using the UART method? Or did an OTA update cause it to stop working?

Please let me know, and don’t worry, we will get the devices all working properly again. Thanks


#14

@eric here are my responses:

  1. How many devices have you seen this on? 2; one bluzdk and one P1 usb gateway
  2. Did the device work and then stop working? both worked as expected initially
  3. Where do you see the b1e2ffff reported for bluz? iOS or Android App? Android App
  4. Where do you see the gateway id reported improperly? The console? That I’m unsure of
  5. Does the device still connect to the Particle cloud? Or does it just blink magenta when you try to connect? If possible, can you try to connect it with the opposite OS app (so if you had been using Android and have access to an iOS device, does that work?) P1 side of the Gateway breathes cyan and shows up in particle list; the bluzdk blinks green slowly first 30 secs after power up, then green blinking speeds up to 2x sec. I “unclaimed” the bluzdk and bluz part of the gateway through particle hoping reclaiming it would solve the problem. This may have worsened the problem
  6. For the gateway, does it still allow devices to connect through to the cloud? Or does the white LED just blink rapidly all the time and it will never connect? No it doesn’t allow any bluzdks to connect. When first became a proble it blinked white rapidly. Now after my fiddling, the white led does not turn on at all.
  7. What firmware version were you running on? Had you performed factory reset? Had you tried to flash firmware to bluz using the UART method? Or did an OTA update cause it to stop working? Don’t recall succeeding to get either device to factory reset. I cannot get the bluzdk into bootloader mode (yellow) at all anymore and also the BTN button seems unresponsive. I had been using UART on the bluzdk to use newer firmware than I found on Build IDE at the time. Was trying to solve problem with attachInterrupt on D1. My efforts there seems to have resulted in the problem on the bluzdk and probably on the gateway as well.

#15

For the gateway, does the white LED blink once when you first power on the board? Did you ever try to flash code to the P1 on the board? If the LED does blink once on power up and you have tried to flash code, then I suspect that the P1 has different/incorrect code on it. You can reflash it with the latest code for the gateway by following the tutorial for the gateway shield here: http://docs.bluz.io/tutorials/gateway_getting_started/#gateway-shield-setup

If the white LED doesn’t light up at all, then that would indicate a hardware problem.

So with the gateway shield powered off, you connect the DK through the Android app. When you do that, does the LED on the DK ever blink cyan? Or only magenta? It should start to blink green quickly (2x per second) for about 10-15 seconds after you hit Connect in the app, then start to slowly (1x per 2 seconds) blink cyan. Do you see this?


#16

@eric
For the gateway, does the white LED blink once when you first power on the board? No. Did you ever try to flash code to the P1 on the board? Yes, both with Build IDE and DFU. If the LED does blink once on power up and you have tried to flash code, then I suspect that the P1 has different/incorrect code on it. You can reflash it with the latest code for the gateway by following the tutorial for the gateway shield here: http://docs.bluz.io/tutorials/gateway_getting_started/#gateway-shield-setup

If the white LED doesn’t light up at all, then that would indicate a hardware problem. DARN

So with the gateway shield powered off, you connect the DK through the Android app. When you do that, does the LED on the DK ever blink cyan? No, only green as noted above. Or only magenta? It should start to blink green quickly (2x per second) for about 10-15 seconds after you hit Connect in the app, then start to slowly (1x per 2 seconds) blink cyan. Do you see this? Just slow green then fast green as noted above.
On the android app, the gateway bluz nows shows as b1e200005… and the bluzdk currently displays as b1e2ffff0… Clicking claim on either results in “Error Claiming Device”


#17

The gateway can’t appear in the app, it only shows DK’s. Do you have two DK’s operating at once?

So when you plug the gateway into a USB port, the white LED never lights up? Was the device dropped or damaged in some way? Did you ever try to update the firmware through the console?


#18

@eric
The gateway can’t appear in the app, it only shows DK’s. Do you have two DK’s operating at once? After ensuring no other bluzdks are powered in my house, I plug the p1 gateway in and Bluz DK displays with the b1e20000… as above. At the staging console I get :

So when you plug the gateway into a USB port, the white LED never lights up? Correct. but when I first got it set up it worked fine. I think it first started failing after I reflashed the P1 side through the Build IDE Was the device dropped or damaged in some way? No not physically Did you ever try to update the firmware through the console? Yes, for awhile it would say “update started” but the device never showed any signs of update. I tried that many times and let it sit for 30 minutes+. Yesterday I tried the adalink and programmer.py stuff mentioned earlier, so I’m sure the software is all screwed up at this point.


#19

@bpr: Dis you try running the Adalink programmer on the gateway? Or DK?

Programming with the JLink can certainly erase/change the internal flash which could brick the device. But the gateway would require soldering wires to in order to program it (or using pogo pins) as there is no header.


#20

@eric,
I used pogo pins on the 4 usb gateway pads and could read and flash no problem. But I was unsure of the proper command line. I used 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
But I was unsure of how to get the keys onto it and didn’t try that. And I had to mess with the programmer.py to just try to flash the id. Checking 0x3F000 in JLink did show the magic digits in hex but that didn’t get it changed somehow.