[SOLVED] Can't activate and claim my core

So…

Introduction:

  • core cannot be discovered neither by Android not iPad nor iPhone
  • telnet device.spark.io 5683 proves there’s no connection issue
  • Changed WiFi setup number of times:
    ** Apple TimeCapsule
    ** BritishTelecom home router
    ** Android Nexus 5 hot spot

Re-cap of the events

  • reset and flash the core
  • core blinks blue
  • supplied core with WiFi details through spark-cli
  • core blinks cyan for long period, then blinks green for long period and again cyan, green, cyan, green, cyan, green… forever.

Feels like the core can’t connect to the cloud (blinking cyan) and reinitiates network connection (blinking green). Please see yourself: https://www.youtube.com/watch?v=wpi4fzMFpiU. Core switches from blinking cyan to blinking green at 2:08

Starting to think my unit is broken :confused:

Ah ha! Apple timecapsule… You might be connecting the core to the 5Ghz SSID which is not supported by the CC3000.

Try setting up the 2.4Ghz SSID and connect again :slight_smile:

Hmmm. I’m using an Apple Airport Extreme (current version). It’s just set to automatic … EDIT: Oh wait, I see I don’t have a tick in the 5GHz name box …

I’ll enable 5GHz and see if it causes a problem for my 'cores. Will get back here shortly.

As I said I tried three different access points: Time Capsule, home hub and Nexus 5’s hot spot.

Just to confirm, my WiFi settings are no different from @gruvin. Then I also tried:

Always the same result… blinking cyan. blinking green

Weird stuff. As far as I know, the core is unable to reach the cloud when blinking cyan appears.

@teke might want to take over from here.

Right, so you did. Well, I just enabled 5GHz and set a 'core to use it’s unique SSID and it actually connects just fine, surprisingly.

What I was really confused about though, is that when I use spark setup wifi to install completely bogus credentials, my core still connects, though it takes a couple tries. It was then that I realised that the CC3000 module can in fact have multiple WiFi configurations, which it cycles through.

So right now, with this knowledge and other stuff in mind, I’m trying a bunch of stuff to see if I can duplicate the exact same symptoms you are seeing. I’ll get back shortly.

EDIT: Skip to next post first, then back here if no joy.


Here’s some steps I just followed and some observations I made, with a known working core …

  1. Factory reset
  2. Core into DFU mode
  3. spark flash --usb deep_update_2014_06
  4. Core reboots and enters listening mode (flashing blue). Deep update flash not performed yet.
  5. spark setup wifi … but using bogus credentials, so the core cannot connect. Core is now flashing green for a long time. Deep update is still not performed.
  6. Place core back in listening mode
  7. spark setup wifi with correct credentials. Core reboots, connects, then performs deep update, indicated by flashing crimson (purple). Core eventually reboots and connects to cloud.

This tells us that the core must be able to at least establish a WiFi access point connection before it will perform the the deep update. (I highly doubt a cloud connection would be required. But I’m not sure.)

So @ciukes … my question for now is, did you actually witness the lengthy session of crimson/purple LED flashing indicating that the deep update was in progress, directly after the DFU-spark flash --usb deep_update_2014_06 command? (I am guessing “No”.)

My main reason for asking right now is only so that I can replicate the events, to see if I can get my core in the exact same state as yours.

P.S: Incidentally, I’m not sure I have ever witnessed a core flashing cyan in quite that same ‘erratic’ manner. Rapid and for a long time, yes … erratic, no. I originally put this down to video frame rate interpolation, though. Perhaps you could confirm?

Ah!! I believe I may have now produced the exact same symptom. I think you have a corrupt (or invalid) cloud server public key.

I just purposely corrupted the cloud server’s public key and installed it back in my core. I now have the same sort of slow/fast/mostly fast cyan blinking, on and on – seemingly just like in your video.

So here’s how you fix that …

First, download a copy of the cloud server’s public key, here: https://s3.amazonaws.com/spark-website/cloud_public.der

Then put your 'core in DFU (bootloader - flashing yellow) mode and execute the following, from a directory containing that above file …

spark keys server cloud_public.der

Reset your core. Cross your fingers. Let us know!

  • I did update server’s public key. No improvement.
  • I did go through @gruvin steps. Core flashes as described but no success at the end

But…
I did set up local spark server ( https://github.com/spark/spark-server ). The core did connect successful to the local server although on number of occasions I have seen this message …

c8a11c6dddc19 HTTP/1.1" 200 2 "-" "-"
Handshake failed:  Handshake did not complete in 120 seconds { ip: '192.168.1.84',
  cache_key: undefined,
  coreID: '55ff6c065075555331341887' }

… or this one …

192.168.1.72 - - [Thu, 31 Jul 2014 18:44:11 GMT] "POST /v1/provisioning/55ff6c065075555331341887 HTTP/1.1" 200 10 "-" "-"
1: Core disconnected: socket error Error: read ECONNRESET { coreID: '55ff6c065075555331341887', cache_key: undefined }

I run out of ideas at this stage.

One more experiment:

  1. Factory reset
  2. Core into DFU mode
  3. spark flash --usb deep_update_2014_06
  4. Core into DFU mode
  5. spark flash --usb cc3000
  6. Core into DFU mode
  7. spark flash --usb tinker
  8. Core into DFU mode
  9. spark keys server cloud_public.der
  10. Unplug power & plug in again
  11. Core blinks blue, ready for setup
  12. spark setup
  13. setup done

Core blinks cyan for a brief moment then blinks yellow for long time and ends cycle with red flash. Cycle starts again, you can see it here:

According to the colors guide (https://community.spark.io/t/what-do-the-colors-on-the-spark-core-led-mean/533) blinking yellow/red means “Bad credentials for the Spark Cloud. Contact the Spark team (hello@spark.io)”. So I did.

Thanks for the video(s). It really helps.

Wow. OK. That last set of symptoms is something else again. Never seen anything like that. The LED is blinking much more rapidly than for the usual connection error reports. It’s usually more like a 1/4 or 1/2 second cadence. What you’re seeing there seems much more ‘erratic’ and strange. Plus, the yellow color indicates bootloader mode, which AFAIK should never happen on its own, unless something is badly wrong.

I’m fresh out of ideas at the moment. It’s looking now to me like something may be physically wrong with your 'core, unfortunately.

That looks like you have a bad key, hopefully you should get a response soon from hello@spark.io, we can fix that up for you. Otherwise @Dave can help you with this one. Apologies for the inconvenience!

This is a relatively uncommon symptom that basically means that we don’t have the Core’s key stored in our database. It typically happens because of an issue on the manufacturing line - somehow the Core’s key doesn’t get uploaded to our servers from the manufacturing line. Every manufacturing run we’re streamlining the process so this happens less frequently, but unfortunately there are still a few that get through each time. But don’t worry, we’ll make it right!

Hi @ciukes,

Looks like you have the Spark CLI, you can repair your keys with:

#connect your core in DFU mode (hold both buttons, release reset, continue to hold mode until it blinks yellow)

spark keys doctor your_core_id

edit: I don’t know why it’s bolding the comments like that… :confused:

Thanks!
David

That does seem to align with the other problem I thought I found. Writing the new server public key changed the behaviour from rapid cyan to rapid yellow flashing. So I’m picking that this 'core didn’t get any keys stored in its Flash at all, at the factory. Hopefully then, this last piece of the puzzle will get @ciukes on track.

@zach / @kennethlimcp … In the meantime, perhaps the docs need to be updated to include these presently undocumented rapid/erratic cyan or yellow flashing meanings? I see no mention of them anywhere at present. Am I wrong?

1 Like

Actually it is listed in the docs:

http://docs.spark.io/troubleshooting/#troubleshoot-by-color-flashing-orange-red-yellow

spark keys doctor your_core_id and …

taaaamdaaaaammmmdaaaaaammm :slight_smile:
https://vine.co/v/ME2VnpZ1pZ2

I owe each of you a beer. Ping me when visiting London :smile:

4 Likes

@kennethlimcp … I recall you are largely involved with the docs side of things. This doesn’t seem to warrant a pull request from me . What do you think? …

Yeah … well, but nah, not really. The phrase “flashing yellow/red/orange lights after it connects to Wi-Fi” does not sufficiently describe what we were seeing, IMHO. I read all this previously, of course and I suspect from his comments above that the OP did, too. Yet we both failed to interpret that description as matching what we were seeing.

How about, “My core is rapidly flashing yellow, red or orange after connecting to WiFi”?

I have never seen a 'core flashing “yellow/red/orange” before and I doubt I ever will. :stuck_out_tongue:

The devil is in the details.

Fair enough - how did you perceive the color?

There’s two perspectives on that.

From the perspective of trying to find documentation on “rapid flashing yellow” or “rapid flashing cyan” (previously), the text “flashing yellow/red/orange” simply didn’t match.

In hindsight, “flashing yellow/…” is a match. But for whatever reason, I read that more as, “flashing yellow, then red, then orange, repeating”, at the time. Plus, I was originally looking for the rapid, “cyan”, so later ignored the non-matching text that I’d already parsed previously and filtered out of possible matches.’

The use of fast (but not as fast) flashing yellow for DFU mode confused the issue, also. The flashing is slower for DFU mode. I had seldom seen the much faster and more erratic looking flashing that occurs with bad keys and even then, only cyan (bad server public key) which is not in the list, “yellow/red/orange”. So again, no match.

I guess it was more about how I perceived the, “flashing yellow/red/orange” description to not match – reasons to exclude it – than reasons to consider it a possible match, if that makes sense.

Thanks for asking. :smile: