Great news, looking forward to TI’s replies
That’s awexome @timb! As a double check, does it ever get to 5 bars if you get closer to your Wifi AP? And it would be cool to see it update live as you walked away from the AP 
If I get super close to the AP the signal goes down, which is normal (you get to a certain point where the signal can be too strong and cause interference). I can get 5 bars when I’m about 10 feet away line of sight.
1 Like
@BDub I was working on both the RSSI stuff and my Digole Display Library last night. I came up with this.
I should have both released tonight!
2 Likes
For those interested, I wanted to give an update. The CFOD is back with the current versions of firmware. I get about 1-2 hours before I get CFOD. It will at times reconnect correctly (flashing cyan, followed by breathing cyan). But other times it will just stay flashing cyan until I reset.
If it will help with the logging effort I have one of these Spark Simulator I can send to you. It will need a CC3000BOOST (https://estore.ti.com/CC3000BOOST-CC3000-BoosterPack-P4258.aspx)
It is a maple-mini board moded to be io compatible with the spark.
1 Like
I have about the same results provided I'm polling via the cloud. The CFoD does not clear unless I press the reset button. Here are the "up times" that I recorded before CFoD.
Up Time (minutes)
282.8
98.4
72.1
122.9
118.4
84.7
75.1
89.4
163.2
123.0 Average
Thanks @dorth - given the great data you’ve collected, could you tell us what the TTL is on your DHCP lease in your router settings?
Same goes for everyone else actually; we have a new theory that CFOD relates to DHCP.
1440 minutes (24 hours) I also borrowed an AT&T Mobile Hotspot and will try running against it tonight for a bit as well. A co-worker also has a SparkCore and I'm hoping to run that next to mine and see if I get identical results.
Dave O
Im running a couple of Spark Cores on the same network all with the same code and some of them ticks on fairly well and some of them gets CFOD at random intervals. It seems to be always the same Core that get CFOD if that might be a lead.
1 Like
I hate to post this without more test time, but since the results have been so conclusive, I figured I'd at least mention it.
Hooking my SparkCore to the AT&T Mobile Hotspot allowed it to run for almost 11 hours until some dumb bunny had to disconnect it from my^H^H his laptop to head in to work. I got one timeout (at 1/28/14 11:25 UTC) over the course of ~630 readings, but the reading 1 minute later was successful. I don't have data to determine if it was the Spark, the Cloud API, or the network, but the good news is that it kept chugging along afterwards.
I now have it connected to a power supply and the hotspot and will let it chug away to see what happens. I don't know if I am able to see or control the DHCP lease times on the HotSpot or not, but certainly for my home router, I'm happy testing out changes there.
Dave O
I have set my lease expiration to 2 min (the minimum) It did not cause any CFODs
On the network I have the most problems with, the DHCP lease time is 310599 seconds. The core disconnects every 30-90 seconds. It’s also the most busy wifi network I’ve used with a core.
On other wifi networks that have less traffic, the core disconnects less frequently. I’ll find the lease times of those networks when I get home.
On the network that I’ve had zero disconnects with, the only thing connected to the wifi router are two spark cores. I’m seeing more of a correlation to network traffic than DHCP lease times.
Mine is set at 24 hours, and when I was getting CFoD it was occurring about once every 3 hours
Another side note… On my home network, I have one DHCP server that serves IPs at a lease time of 24 hours. But I have two access points. One access point serves wifi to all my other devices in my house. When the cores are connected to it, they frequently disconnect, but when they’re connected to the other access point (different SSID) that has no traffic, the connection is stable, even though the DHCP server is exactly the same.
Hi,
Have you looked at the code in the cc3000_spi.c?
Does it look like the code in SpiReadDataCont for the case where data_to_recv >= SPI_WINDOW_SIZE and the SPI_DMA_IntHandler for the case eSPI_STATE_READ_FIRST_PORTION would clobber memory?
SpiReadData(evnt_buff + 10, SPI_WINDOW_SIZE); Is this an over write by 10 bytes?
SpiReadData(sSpiInformation.pRxPacket + 10 + SPI_WINDOW_SIZE, data_to_recv);
Overwrite by 1034 bytes?
What do you think?
It ran for over 14 hours (851 minutes) on the AT&T HotSpot and had two disconnects which re-connected by the next query. So I think it's pretty clear that this is related to my Router and/or my WiFi traffic.
I dragged an old LinkSys 54G router from the closet and flashed it with Tomato 1.28 f/w. It's operating as an Access Point but tied into the DHCP and hardwired network traffic of my main router. I've restarted the Spark pointing to that empty WiFi network and will see how it goes.
Certainly my main WiFi network is somewhat busy, but most of the heavy consumers are either hardwired or run off another AP. It will be interesting to see what happens.
Dave O
You should dig into it @david_s5 and let us know what you find. Relevant TI SPI protocol description:
http://processors.wiki.ti.com/index.php/CC3000_Serial_Port_Interface_(SPI)
I just wanted to send a thank you to the Spark team that you are continuing battling with Texas in the support thread you have opened. Shows dedication to get this thing working and I appreciate it.
4 Likes