1 spark core : ok, 2 spark cores : constant reset [SOLVED]

I have 2 spark cores (default tinker app loaded)

If I power either one up, all seems ok
If I power both up at the same time (separate power supply),
then both devices start to reset about every couple of minutes ?
after the reset, they are connected to the cloud again for a short time.

-I ran cc3000-patch-programmer to update cc3000-patch-programmer.bin
-I reloaded the tinker firmware (from the android app)
-I replaced the tinker app with the flashing led app

this made no difference

I think when one successfully connects to the cloud, the other one immediately resets ?

That’s interesting!

I wonder if the router is mixing up the cores and causing this problem…

Can you try this patch:

Thanks for your reply,

I think the problem is that they both have the same MAC Address (as shown in DHCP reservation list on my router)


would your patch fix that ?

That’s kinda weird…

Let me see where to change it.

They should be unique.

@dave and @satishgn knows best on the functions to change it.

According to the TI CC3000 support forum, this means that the update to TI CC3000 did not work properly.

I think you need to try the TI update again.

1 Like

ok thanks,
I ran dfu-util with the new bin file, this just took a couple of seconds.
however the light still blinks yellow after some minutes (led D7 is on).
Should I just wait until the led turns off or did something go wrong ?


this new patch requires a factory reset once you see it flashing yellow :smile:

I did a factory reset, but the MAC address is still 00-12-55-55-55-55

I think you are going to need help from the Spark team–I don’t know how to get your MAC addresses back now. There might be a way, but I sure don’t know it. There is definitely a way to set it again via netapp_config_mac_adrress (their misspelling, not mine!), but what the right value is, I am not sure. Maybe the Spark team stashes the MAC address away in flash for a rainy day like this or maybe they have a big speadsheet or database.

I hope @Dave or @zachary has an ace up their sleeve for this one.

For now, you can use them one at a time, right? Or on separate wireless networks.

Thanks for your help

it looks like this fixed my MAC address. (which I got from my router logs, so I must have messed them both up trying to update the CC3000 firmware…)

void setup() {

UINT8 address[6];

address [0] = 0x08;
address [1] = 0x00;
address [2] = 0x28;
address [3] = 0x....;
address [4] = 0x....;
address [5] = 0x....;

void loop() {


So is everything fine now? Can we mark this solved?

Glad to hear it is working for you!

Yes… all looks OK now. Thanks for the help!


I’m bookmarking that mac address config for future reference. That may come in handy some day!

1 Like

p.s. note that I just tried to update to 1.13.7 (because I still see restarts every hour or so with just tinker loaded)

I flashed the bin file from : cc3000-patch-programmer-ti-patch-1.13.7


dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D cc3000-patch-programmer.bin

and that changed the MAC address to 00-12-55-55-55-55 again.

At least I know now how to set it back to the correct value.

1 Like

another thing I found:

after flashing the bin file from : cc3000-patch-programmer-ti-patch-1.13.7
nvmem_read_sp_version returns 1.28

I just received some new spark cores that I have not updated.
nvmem_read_sp_version returns 1.29

I don’t know what patch version that is ?

I wonder if my lost MAC addresses were caused because perhaps I went from 1.29 BACK to an older version 1.28 ?

Hello @mhwlng
Thanks for sharing your observations! I’m trying to understand how the MAC address’s are getting corrupted and if that can be avoided as we get ready to release a wide patch update to our users.

According to TI’s release notes, 1.28 is the latest official release and is same as cc3000-patch-programmer-ti-patch-1.13.7 branch.


1.29 is weird, since it should have been 1.26 which is the latest master branch.

I tried another core (that I received this week) and that one also shows version 1.29

    uint8_t fwver[2];
    digole.print(fwver[0]); digole.print("."); digole.println(fwver[1]);