Continues red flashing

I bought 2 Spark Core back as a Kickstarter. Haven’t had time to test them until now. We’ll first Core was a work just as quick start guide described. No problems at all. The second one I have still not been able to connect to either the iPhone tinker or to the cloud by specifying wifi credentials by USB. Have even tried to give wifi credentials via the TI WiFi Smartconfig app.

I have updated the firmware from various instructions I have found. This being the last https://community.spark.io/t/tutorial-upgrading-factory-reset-firmware/3430

In the best runs I get a blue flashing to go to a green (even with the iPhone app) but then I get flashing red. Every single time! :frowning: starting to give up soon. Via the USB I got the device ID but that can’t be claimed.

At the moment this is all I get https://www.youtube.com/watch?v=VNPwiqs0jlU

Latest test was to use an alternative wifi router.

So, what is the secret to just get it to connect?

From the factory reset, if I do this

dfu-util -d 1d50:607f -a 1 -s 0x00020000:leave -D Downloads/core-firmware-spark_2/build/core-firmware.bin

plus a factory reset it will go into DFU mode

But…if I do this

dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D Downloads/core-firmware-spark_2/build/core-firmware.bin

It will start to blink blue and wait for wifi credentials. Though, no matter what wifi credentials I get blinking red. I have tested with multiple wifi routers and even having no encryption enabled.

So…my last straw is this.

Seems like no end to it…

Hi @epatel

The Spark team has been traveling lately so I am sure @Dave will jump in here at some point.

Do you think your LED is flashing RED or flashing ORANGE? As that thread says < 1% of initial Spark cores shipped had bad crypto keys and need to be updated. If it is orange, you can generate a new key, install your new private key and the Spark public key using dfu-util, and email your new public key to @Dave and be on the air shortly.

Think its definitely flashing red. I have now also tried to use the cli tool to generate new keys.

Looks like a great tool. Wish it worked for me though…just to be transparent, it did not help. Still only flashing red.

The trace looked like this (where NNNN is the core device ID) so I imagine the process has been automated.

$ spark keys doctor NNNN
FOUND DFU DEVICE 1d50:607f
running openssl genrsa -out NNNN_new.pem 1024
running openssl rsa -in NNNN_new.pem -pubout -out NNNN_new.pub.pem
running openssl rsa -in NNNN_new.pem -outform DER -out NNNN_new.der
New Key Created!
FOUND DFU DEVICE 1d50:607f
FOUND DFU DEVICE 1d50:607f
running dfu-util -d 1d50:607f -a 1 -s 0x00002000:1024 -U pre_NNNN_new.der
Saved!
checking file  NNNN_new.der
running dfu-util -d 1d50:607f -a 1 -i 0 -s 0x00002000:leave -D NNNN_new.der
Saved!
attempting to add a new public key for core NNNN
submitting public key succeeded!
Okay!  New keys in place, your core should restart.

Blinking red sounds like not being able to connect to the internet.

If you have time now we can have a chat and see what’s going on :slight_smile:

The video looks like a blinking orange/red issue but it’s not that clear so I cant tell :slight_smile:

@Dave, some field report to speed things up when you debug for @epatel,

  1. When the core is powered on, it immediately enters DFU_mode (blinking yellow)

  2. Performing a factory reset would be… blinking yellow —> Flashing white --> blinking yellow

  3. The V02 factory-reset firmware was downloaded to both the factory-reset address on the External flash and the User firmware location on the Internal flash

  4. Pressing the MODE button to get into Listening Mode does not work

  5. When the V02 factory-reset firmware is downloaded into the Internal Flash aka User Firmware location, the core resets into Blinking blue

  6. Once wifi credentials are sent, the follow happens: blinking blue --> blinking green --> red blink(fast flashing, with occasions of white blinks)

Sounds like the bootloader is screwed somehow!

Time for you to take over :smiley:

1 Like

Hey @epatel,

Sorry about the key issues, and thank you guys for helping troubleshoot! Can you send me your device ID (in an email david@spark.io, or over forum private chat), so I can look it up in the logs? Can you also re-flash the server public key by doing:

Download this:

https://s3.amazonaws.com/spark-website/cloud_public.der

Run this:

spark keys server cloud_public.der

Thanks!
David

@Dave,

I believe it has nothing to do with the keys(for now)

See:

The core is not behaving as it should be…

Unless not having a correct server public key is going to cause such a behavior.

Flashing red during a handshake generally indicates a key issue, either server or local, so re-flashing those is important. Having the device ID lets me know if the core is reporting errors, or is completing the secure handshake or not.

Hmm… a factory reset is throwing it into DFU mode? That generally indicates a problem with the external flash chip (bad sectors). The best way to test that is to write something to the chip (like re-flashing the factory reset region), and then reading it back and comparing the two. If they don’t match then @epatel should email us at hello@spark.io and we’ll send a replacement.

Thanks!
David

Hi @Dave,
I’m having some issues connecting to the local spark cloud, it flash green, cyan and finally red for at least 10 attempts and finally it connects. Is there any way to improve the handshake to be more reliable?
Thanks a lot!

Hi @juano2310,

Make sure you’re running the latest copy of the local server, and the latest core firmware, and your core has the latest cc3000 patch. All of those should help with the reliability of the handshake. :slight_smile: If all of those are true, can you paste a snippet of logs from your server for one of these handshake attempts and maybe we can see what’s up?

Thanks,
David

Hi @Dave, Thanks a lot for the quick response. The problem was on the encryption of the wifi connection. I switched from WAP2 to WAP and it’s working great now :smile:
Thanks a lot!

Oh awesome, thanks for posting your solution! :slight_smile:

It’s funny to see how much drift a standard like WPA2 can have across different access points, glad you got it figured out.

Thanks,
David

1 Like