Bug bounty: Kill the 'Cyan flash of death'

The main issue I was having with the Spark Core was when my cellphone’s wireless hot spot would get reset by Verizon it would cause flashing dark blue indicator on the Spark Core that would require a manual rest. This was happening pretty often lately due to high internet traffic.

The latest firmware update via the web IDE has completely fixed that problem it seems. I have not seen any other problems with the Spark Core after about 60 days of usage.

I’m much happier with not having to manually reset the Spark. Hopefully I don’t speak too soon, if I notice anything change I’ll report back.

1 Like

After 26 hours of testing on multiple cores, we have not seen a single failure.

TI reports their first day of formal testing also went well.

Look for another update tomorrow.


How’s it been after 5 days?

Today isn’t a good day to ask that question. You won’t know if he’s telling the truth or telling a joke.


I have a found a network that is total rubbish and my core always fails after a while even with the latest CC3300 firmware, so I’ll be happy to test the new patch when it’s available and report if it kills the problem forever.


Any update on test results and making this available to the community ?

Testing continues to be positive. I am meeting TI on Monday to tie up any loose ends.


So, any update on the outcome? You really know how to build up tension ;-).

I am dying to get finally a working version of the Spark Core. I would really like to start working with it. But I won’t start until the connectivity is reliable!

Calling all conspiracy theorists in the community :slight_smile: Has TI done a runner?, are their open source issues in issuing the update?, is someone making a takeover of spark labs inc ?, the silence is deafening…

What remains the biggest problem with the :spark: and 18 days after getting a RC from TI still little word. Appreciate reliable OTA update stuff may be challenging but still nothing for those who flash locally. Certainly firmware v0.2.0 has helped with reliability but the best uptime I can get is < 24hrs

C’mon @zach @AndyW is there anything you can tell us ?, please.

Hi @deancs,

There’s no silence from us :), you’re hearing news as soon as we get it.

TI has a large testing lab, and we’re waiting for them to be confident about their cc3000 fix. We’ve done quite a bit of planning, and we want to make sure they’ve tested this patch thoroughly before rolling it out to the community. There should be more details in our post-sprint blog post which should come out sometime Monday since we ended this last sprint just this last Friday.

In a potentially unfair teaser, we continue to hear good things about testing on the patch. As much as we want the patch out quickly, it’s also good for them to test very thoroughly. If they find bugs now, that just means more fixes will be included in the next update.


1 Like

Well, silence is the absence of sound. So if there is no sound (==news) that’s silence, or :-). Have you ever been in a phone call where suddenly the background noise stops? And you ask “are you still there”?

Anyway it’s good news that none of the conspiracy theories seem to hold :-).

There is only one thing I wonder: If TI has such a big QA lab and such a lengthy QA procedure, then how could all these issues have possibly slipped through??? (Not the fault of the Spark, of course). I mean TCP did barely work, UDP does not work (not preserving packet boundaries is no UDP for me)…

To be fair to TI,

  1. you can’t test all the router make in the world. Like android app makers can’t customize for all and some might have an issue. So feedback is important :slight_smile:

  2. everyone is in an unique wifi environment and the not a majority is hit with the event even though the fix is definitely needed.

  3. I feel that they moved fast to zoom in on the issue and even took extra steps to get this fix out and I applaud them for that.

  4. :spark: core is one of the largest product with a CC3000 and this create new environments untested.


1 Like

I promise not to be annoyed if Spark Team updates this thread daily :slight_smile:


The meeting with TI went well, and Spark HQ are busy making plans to roll out the new improved firmware.

Look for an update any day now on the feature content of the next sprint.


Will the result of this activity be TI releasing a new CC3000 Firmware and Host Driver package? e.g. version 1.13, 1.12.1 or something like that? Ref: http://processors.wiki.ti.com/index.php/CC3000_Release_Notes

I do not know if they plan to formally release a package that matches the code they have released to us.
I understand that TI has a release scheduled for May/June that will include some additional fixes/features beyond the issues behind CFOD, that may be the next formal release from them.

Thanks @AndyW, Is the fix confined to the CC3000 firmware or does it also impact the Host Driver as well? Also what CC3000 firmware release did the KickStarter Spark Cores ship with?

The current fix is CC3000 firmware only.

The May/June release will have host driver changes also.

I’ll defer to others what host driver version the spark code is based on.

1 Like

I’m working on a project and found lots of great information on this data stream. I also purchased some Adafruit CC3000 chips and was able to port functionality from that code into a solution that worked for me. Hopefully it will work for you, too. I’m not a professional developer, so please forgive sloppy formatting. BSD license applies.

    typedef struct Result_Struct{
        uint32_t        num_networks;
        uint32_t        scan_status;
        uint8_t         rssiByte;
        uint8_t         Sec_ssidLen;
        uint16_t        time;
        uint8_t         ssid_name[32];
        uint8_t         bssid[6];
    } ResultStruct_t;       /**!ResultStruct_t : data struct to store SSID scan results */
    void structSSID(){
    char ssidname[32];
    ResultStruct_t SSIDScanResultBuff;
    int res = (wlan_ioctl_get_scan_results(0, (uint8_t* ) &SSIDScanResultBuff)); //loads results into struct
    if (res != 0) {
        Serial.println("Could not get WiFi Scan results.");
    int index = SSIDScanResultBuff.num_networks;
    int i = 0;
    while (i<index){
        int _rssi = (SSIDScanResultBuff.rssiByte >> 1);
        int _mode = (SSIDScanResultBuff.Sec_ssidLen & (~0xFC));
        uint8_t ssidLen = (SSIDScanResultBuff.Sec_ssidLen >> 2);
        strncpy(ssidname, (char *)SSIDScanResultBuff.ssid_name, 
        ssidname[ssidLen] = 0;
        long rssi = _rssi-128;	
        String myrssi = String(rssi, (unsigned char)DEC);
        String encrypted = "";
        switch (_mode) {
    		case 0:
    		    encrypted = "OPEN";
    		case 1:
    		    encrypted = "WEP";
    		case 2:
    		    encrypted = "WPA";
    		case 3:
    		    encrypted = "WPA2";
    	String SSID = ssidname;
    	String results = SSID + "," + myrssi + "," + encrypted;
    	int res1 = (wlan_ioctl_get_scan_results(0, (uint8_t* ) 
            &SSIDScanResultBuff)); //iterates the buffer
    	if (res1 != 0) Serial.println("Get Scan Results iteration 
1 Like

Hey gang, any new updates on this thread?