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)

00-12-55-55-55-55

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 ?

@mhwlng,

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....;
netapp_config_mac_adrress(address);
}

void loop() {

} 
7 Likes

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!

3 Likes

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

using

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.

http://processors.wiki.ti.com/index.php/CC3000_Release_Notes

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];
    nvmem_read_sp_version(fwver);
    digole.print("FW=");
    digole.print(fwver[0]); digole.print("."); digole.println(fwver[1]);