Troubleshooting: My Core is flashing yellow/red lights after it connects to wifi

Hi @annon,

That’s a good question! This shouldn’t be happening now, but we’re seeing some users report this issue even after the second wave of manufacturing (although much much less). I’m going to review our process again and continue to cut the rate down as far as possible.

Thanks,
David

I got mine last week and it has this problem. Just send my public key and core id to Spark. I have spent too much time just to connect this thing to Spark servers. I thought this is supposed to be easy. Better quality control is needed.

1 Like

Thanks @rawmean,

Glad we got you back up and running quickly after you sent your key.

I can tell you I literally sat on the factory line during the second manufacturing run to try and avoid this problem the second time around! :slight_smile: Unfortunately part of this has to do with the strict security in place to protect messages sent from the core, so it’s a trade off, but we’re trying to make sure this happens as rarely as possible.

Thanks,
David

Hello Dave, I have some problem .

I done 1~8 already.

9.) connect to your core over serial, and hit ‘i’ to get your core id
I used usbserial and CoolTerm(Mac),goSerial(Mac), connect to the Spark Core RX,TX
I don’t see any response from console.
(I just tried to use the same usbserial to connect the cubieboard (ARM), it works .)

This is the spark core strange lighting video .
http://youtu.be/fzZIn5Ad1qg
Maybe it still in recovery mode ? How can I reuse it ?

Thank you .
(sorry for my english ability)

Hi @peterlee0127,

The serial config on the core is expecting to talk to you via the virtual usb port serial interface. Can you use that com port instead of the hardware tx/rx pins?

Thanks!
David

Thanks for reply.

Yes, it works.
I will send the key and core id .

Thank you.

1 Like

I have gone through these steps and emailed the public key and core ID to:

But it's been about 3 days an no reply or even ack that the email was received. How long does it typically take for turn around on these?

To be sure I just plugged in the core again to verify it's still stuck at the handshake.

@goseese,

@Dave must have missed the email! Usually he gets to it almost immediately when he sees it.

I have @Dave and he will get this in his email or when he comes to the community!

1 Like

Hi Guys,

Just got the email about this thread. I went back and checked my spam filters, and it looks like your email was flagged as spam for some reason. As a side note, I recommend setting up SPF and DKIM when sending from your own domain, see: http://en.wikipedia.org/wiki/Sender_Policy_Framework , and http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail .

I just added your key to the database, sorry again about the delay. I also flagged your message as not spam, so hopefully Google won’t decide to flag it again. :frowning: You can always private message me on the forums as well, or just use @Dave to flag me down as well.

Thanks!
David

2 Likes

Thanks the core is hooked up and connected. I appreciate the quick response.

2 Likes

Awesome, glad it’s working! Sorry again about not checking my spam more often!

Thanks,
David

Hi,

I got my Spark Core in the mail on Saturday and was so fired up to get it going. But… I’m either missing a key step or something else odd is going on. I have the same issue that the title of this post mentions, that is a connection to my home wifi (I can see the device get a DHCP address), but shortly after this, I get a sequence of about 15-20 seconds of flashing yellow/red LEDs, then a few second burst of red, then a pattern on cyan (blue/green LEDs are being driven, I think)… The cyan pattern might be a real fast version of SOS, then the whole thing repeats.

I tried first using my work Win7 laptop, but moved to my desktop Linux box, with the same results. I’ve reset and re-entered the wifi credentials many times (most correctly). I have a chip antenna version of the Spark Core. It is currently about 4 feet from a dd-wrt router, that has been forced into BG Mixed mode runing WEP2. I can see the router getting messages from the device, showing that the Spark Core is asking for 54Mbps in each direction, so the signal strength should not be an issue. This a NAT’ing router that is attached to a rural wifi access point. This is a static IP address that I use many, many different ports on, so I’m pretty comfortable saying that it is open. I’ve opened the port so that packets on that port go directly to the Spark Core.

I recently found the instructions about installing the Spark CLI interface. Thinking that I might of have a bad certificate, I ran the 'sudo spark keys doctor , that seemed to run well, but left a couple of error messages, but seemed to run to completion. The message about the invalid DFU suffix signature seems to be no issue. But the following statement makes me wonder. However, it is not clear if the updated public key was uploaded.

This is a snippet from the terminal screen.

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Error saving key… TypeError: Cannot call method ‘on’ of null
Make sure your core is in DFU mode (blinking yellow), and that your computer is online.
Error - TypeError: Cannot call method ‘on’ of null
Opening DFU capable USB device…
ID 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #1
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "SPI Flash : SST25x"
Downloading to address = 0x00002000, size = 610
Download [=========================] 100% 1024 bytes
Download done.
File downloaded successfully

In the end, the question that I have is what am I doing wrong? Does the problem that the OP have, still exist in the latest builds.

Any thoughts about the next steps for me?

Thanks (and sorry about the long (first) post.

johnbo

Hey there,

Seems like you did the steps right and the error messages can be ignored. Just some issues with dfu-util.

So is it working now or still flashing red/yellow?

Hi,

Yes, no change that I can see from before the rekey and after.

I just found that when I tried to claim the core via the spark cloud claim command, it would not complete as it could not establish a connection. I was hoping that this might be a chicken and egg problem where the updated key could not be updated with a core to attach it to. Not sure if I completely understand the whole eco-system yet.

Later,

johnbo

spark key doctors automatically sends the new key to the :spark: cloud so it shouldn’t happen.

Try a factory reset and send wifi credentials again! :smiley:

Hi,

I did the factory reset, (press both buttons, release reset, wait for white flashing, release mode). Got the flashing blue light.

I ran “sudo spark setup”, provided wifi details, got the message “Please wait until your core is breathing cyan and then press ENTER” Core went through the wifi process, then started the yellow/red sequence and stays there. Never got to the breathing cyan. Hit ENTER anyway, the setup program said that the server said [ device is not connected ]. And repeats the message. Had to control-C out. I can see that the router has provided an DHCP address to the Core, so I think that I’ve got the right credentials to the Core.

Seems like I’m back where I started. Am I doing the reset incorrectly?

Am I not getting the new public key to the server? Do I still need to email this to the addresses mentioned in the thread?

Thanks,

johnbo

Hmmm… @dave what do u say for this problem?

Honestly, you don’t need to. The spark keys doctor does the upload automatically.

One thing i suspect might be the public key for the cloud and not the issue with the core key?

I got it!

I dug into the code in the spark-cli and found that I should have seen more output logs when I run the “keys doctor” command. I believe that it aborted after I saw “File downloaded successfully” in the above messages. There was one extra line that immediately followed that “Transitioning to dfuMANIFEST state” then it returned to the command line.

In digging through the code, I found the elements for another command “spark keys send [core]_new.pub.pem”. I executed this and got a message that submitting the public key was successful.

After that, I watched the Core finish up its error display and reset, this time it was a bit more active and now its gone to the cyan breathing state. Yeah!

Just to finish the thread, in case someone else stumbles upon this. After I got to the cyan breathing state, I claimed the core with: “spark cloud claim [core]” Then renamed the core with: “spark cloud name [core] [newName]”

After all of this, I’m able to use the Tinker app via iOS to toggle D7 and make the little blue LED toggle.

The engineering manager in me wants to understand what went wrong in the first place. @Dave if there is anything else that I can help with tracking this down, please don’t hesitate to ask. I’ve got the earlier key if that is useful.

Thanks,

johnbo

1 Like

Ah… Does that mean that spark keys doctor missed out the part to upload the keys using spark keys send core ?

It was working well when i tested in the early phase :wink:

Hi,

I think that this was missed. I’m lousy at javascript, but in the keyDoctor function, there is a sequence of:

 var allDone = sequence([
        function () {
            return dfu.findCompatibleDFU();
        },
        function() {
            return that.makeNewKey(coreid + "_new");
        },
        function() {
            return that.writeKeyToCore(coreid + "_new", true);
        },
        function() {
            return that.sendPublicKeyToServer(coreid, coreid + "_new");
        }
    ]);

I can’t find any evidence in my console log that the sendPublicK… function was ever called. I’m looking at the ‘leave’ flag being passed as true and wondering what this was trying to do.

Got my first script running on the Core, its exercising the relay shield…

Later,

johnbo