CC3000 DOA - recover from corrupt firmware?

Is it possible to recover from a corrupt CC3000 firmware?

Mine slowly flashes white (no other colour), even after a factory reset and after reflashing the core firmware.

When I try to flash the most current CC3000 firmware, it starts blinking magenta immediately without pushing the mode button. And it doesn’t ever stop blinking. I’ve tried uploading all the firmwares I could find, even one that I compiled.

I have access to SWD JTAG if that’s of any use - ST-Link connects fine to the Spark Core.

The way it stands, I either have to send this Spark Core back or try to reprogram the CC3000 via an Arduino, which would involve some creative SMD soldering to access the MOSI, MISO, SCK & IRQ pins:

FWIW, TI also mentions the following using their FRAM programmer:

“Starting from V1.10.2 package, the patch programmer can recover a corrupted EEPROM.”

It is a new core and it was flashing white?

I remember it as communication with the CC3000 and even patches may not fix it due to the comms being an issue.

Maybe I’m wrong :slight_smile:

It’s a new core.

Got it last week and it worked for the first day, then it wouldn’t connect anymore. Went through the above procedures and ended up with a breathing white LED, similar to this:

Hmm… Let’s see what @Dave says :slight_smile:

1 Like

I had a similar experience with mine. First it stopped handshaking with the cloud, and @Dave helped me swap in/out certificates (but no dice) and then I tried a cc3000 patch update, and after that it never gets past a white flashing led. Now attempting to apply the latest patch I don’t get a flashing magenta after pressing mode. I also have stlink2 so can debug.

Hi @sneakthief,

Sorry to hear your core is flashing white!

The newest cc3000 patch programmer is meant to run immediately, and will only stop when it’s confirmed the driver version on the cc3000 matches what it expects should be installed. If it’s never finishing, and your core is flashing white, I suspect your core isn’t able to initialize the cc3000 wifi module.

My current theory about this problem has to do with moisture on the core. This may be a bit silly, but could you try the old “put your Core in a zip-seal bag of dry rice for 8-12 hours” trick, and see if that helps? Is it extremely humid where you live, or has the core gone through extreme temperature shifts? Any extra information you could provide would help us diagnose this issue.

edit: We also want to make sure people able to build cool things, if your core is stuck at flashing white before you’ve had a chance to build with it, email us at and we’ll get you sorted. :slight_smile:


1 Like

It’s pretty dry here in Berlin, so I doubt humidity is an issue - but I’ll try the desiccant trick anyhow.

The core wasn’t subjected to any big temperature swings either. As I mentioned, it’s brand new and has never been connected to anything except via USB.

Speaking of which, there’s a small possibility that USB power was interrupted briefly during the first time I tried flashing the CC3000 firmware; afterwards I noticed the USB cable was a little flakey.

1 Like

@Dave Re. desiccant trick: No dice.

So is it possible to recover from a corrupted CC3000 EEPROM burn, as mentioned in TI’s Flashing Guide?

I would love to have that core and see how i can fix it.

@Dave let’s make it happen? :smiley:

1 Like

You’re welcome to have mine too - Dave did offer me the chance to send it back previously, but I wanted to wait until I got a JTAG shield to see if I could debug what’s going on.

Unfortunately, JTAG debugging doesn’t cut it - it just shows it’s waiting for the CC3000 to respond, which never happens. I’m a software guy, so my ability to fix this ends there.

1 Like

Thanks for trying to dry the Core out @sneakthief. We need to get you a replacement.

Please email with your shipping address, phone number, and which kind of Core this is (u.FL or chip antenna).

The LED on the Core breathes quickly white at boot. It changes to either flashing blue (listening mode) or flashing green (connecting to Wi-Fi) after it initializes the CC3000. If a Core is never getting past fast breathing white, then the CC3000 is never successfully being initialized. This is almost surely a hardware problem, not a software problem. It probably has its cause in how the components are handled at the factory. It’s odd that your Core used to work and now has this failure mode, but c’est la vie. The Spark team will discuss this week strategies for reducing the incidence of this problem in our next manufacturing run.

Also, try something for me if you don’t mind—imagine that the CC3000 is not soldered down well—boot up the Core while consistently holding the CC3000 on the board really tightly. Can you get past breathing white that way?

Happy to send you a replacement either way.



Thanks for trying! I appreciate it, this is helping me find the cause of this error that seems to pop up during shipping.


I have a core that is doing the same - fast breathing white. This core was fine from the factory so it can surely be also a software/firmware problem, or maybe a failed cc3000 flash (since I tried that too.)

1 Like

It was working fine all along? We need to get those cores back to :spark: HQ or I would love to have them for debug :slight_smile:

@peekay123 have patched 3 cores with no issues so far

Yup, using the Spark CLI “spark flash coreid CC3000” I flashed two old and one new core without any issues.

1 Like

@zachary - Thank you kindly for your great support! I tried pressing down in case it was a soldering issue and it didn’t help.

FWIW, my Spark Core was never even removed from the prototyping board it came in when I got it last week and all relevant precautions were taken - not to mention I’ve built a large number of analog/digital circuits from scratch over the last decade, including mixers, eq’s, sequencers, a TR-808 clone, etc.:

@peekay123 - how can I use the Spark CLI if I can’t connect via a serial terminal or wifi? “Listen Mode” simply doesn’t work anymore. Would I recompile the Core code with the CC3000 disabled? Or via an FTDI & 5v/3.3v level converter connected to the RX/TX?

I really don’t mind poking at this thing to try to get it working.


I think the JTAG programmer will be ideal for this debugging. Let’s get yours exchanged with :spark: HQ and leave the nasty stuff to them.

Would love the core to be sent in my direction for testing since we lost a lead for one locally…

Good point @mdma. I suppose it could be failed CC3000 patch. We’ve tried things like intentionally interrupting a patch to see what that failure would look like and have never seen it stuck hyperventilating white, but it does seem theoretically possible to brick a CC3000 during the patching process and end up with this behavior.

In any case, hooray hardware development. :smile: