Unable to handshake with cloud

Troubleshooting
1

Hi.

We are building a product using the P1, and currently compiling locally.

I have a development device that I was having some issues with with certain versions of system firmware, and as part of my testing I upgraded/downgraded it a few times. I also unclaimed it from one account so I could claim it on another development account.

I’m now in the situation where I am unable to reclaim it because it won’t successfully handshake with the cloud service anymore.

My logging shows:
0000005346 [system] INFO: Cloud: connecting
0000005356 [system] WARN: Read Server Address = type:255,defaulting to device.spark.io
0000005356 [app] INFO: Event: Cloud status changed - Connecting [64, 1]
0000005361 [system] INFO: Resolved host device.spark.io to 107.22.28.43
0000005649 [system] INFO: connected to cloud 107.22.28.43:5683
0000005661 [system] INFO: Cloud socket connected
0000005672 [system] INFO: Starting handshake: presense_announce=1
0000005682 [comm.sparkprotocol.handshake] INFO: Started: Receive nonce
0000005935 [comm.sparkprotocol.handshake] INFO: Encrypting handshake nonce
0000006018 [comm.sparkprotocol.handshake] INFO: Sending encrypted nonce
0000006029 [comm.sparkprotocol.handshake] INFO: Receive key
0000006293 [comm.sparkprotocol.handshake] ERROR: Unable to receive key -19
0000006302 [system] WARN: Cloud handshake failed, code=-19
0000006563 [system] INFO: Cloud: disconnecting
0000006574 [system] INFO: Cloud: disconnected
0000006586 [app] INFO: Event: Cloud status changed - Disconnected [64, 0]

I have tried a few ideas that I’ve seen documented around, e.g.

  1. Using ST-Link I have written 0xFF to offset 34 in the active application DCT (so 0x1D9E into the DCT flash segment).
  2. Used particle-cli to generate new keys, flash them into offset 34 and send to cloud as per P1 is not able to connect to WiFi - Unable to receive key -19
  3. Further to the suggestions in the previous point I also reflashed the server public key.

Anything that involves DFU mode isn’t a good option for me because I’m going to be able to need to solve this in production should it happen, and our device won’t have USB.

Any ideas?

Thanks.

2

Can you try this in DFU Mode anyway to see whether this would help at all?

particle keys server
particle keys doctor <enterYourDeviceIDHere>

(I suppose you have OpenSSL installed and available to CLI)

You could always first pull a full dump of the flash and reapply that to get back into this stage to further investigate how to do this without DFU Mode.

BTW, when you upgraded to 0.7.0 or above the bootloader may have been altered too and hence downgrading would also require you to downgrade the bootloader (via YModem - Listening Mode)

3

That did fix the issue, I’ll try to reverse engineer from the flash dumps what changed so I can do it without DFU next time (hopefully never though…).

Yes, I had downgraded my bootloader already, although I just direct flashed it with my ST-Link.

Thanks for the suggestion.

1 Like