When things fail InternetTest is called before the reconect.
On the close InternetTest test socket the writeās status comes back 2
times. The second is without a ballenced SimpleLinkWaitxxxx. This caused
the hci_unsolicited_event_handler to not resume the SPI interrupts.
I fixed this by rewriting the SPI Driver. Pull request forthcoming.
Sparks arrived yesterday, also been noticing buggy behavior with wifi. Just ordered a JTAG interface (already got the JTAG shield for the spark) to join in on the fun
If the userās code has a socket they open and close regularly This should have a socket handle value of #1 with the sparkSocket being the socket handle value 0. However, if the sparkSocket is closed due to a error or a timeout in the CC3000 and the main loop calls into the userās loop before it detects the spark socket is closed the users can reopen itās socket and get handle 0. Then the Spark protocol ends up reading the USERS data an will most likely over write memory.
bool SparkProtocol::handle_received_message(void)
{
last_message_millis = callback_millis();
expecting_ping_ack = false;
int len = queue[0] << 8 | queue[1];
if (0 > blocking_receive(queue, len)) <------- what is length!!!!!
{
Nice find! I'll pass that along for the firmware guys to checkout
Sorry if this is a silly response, I just saw the "what is length" thing and I just wanted to chime in and say the core->server protocol prefixes each message with a two byte length packet.
I have re-written the TI cc3000_driver.
I fixed an dead hang in the write code where the race of a write to the device lost to a read request and was stuck waiting on the WIFI_INT pin.
I have fixed a ti bug in the event handler logic to prevent the situation documented above in "Found a bug that kills the SPI Dirver." post
I have added a watchdog to the TI event loop that will not let it run on longer then the inactivity timeout (+250 ms) and returns errors to the callers.
I do not have a good fix for post "Found an Issue:" other then extending the inactivity timer from 20 seconds to 32 seconds. But I believe this will not fix the issue, just mask it because of the async nature. of B, to D below
Need to discuss with you guy's best way to resolve this.
Anyway Please give these 4 builds a shot and report back....
There needs to be central management of socket descriptors on the STM32. Only call connect() from one place and keep track of the sockets that have been opened. If connect() returns the same descriptor of another socket which is thought to be open, mark it as closed and give the socket descriptor to the current caller. Next time through the spark(or user) loop sees that its socket is closed and makes another call to the connect() wrapper and is issued the next free descriptor.
Great catch on the blocking_read() with undefined length btw.
@david_s5
So here is all the firmware tested with their results.
" bad_every_1_core-firmware.bin" seems to restart the Core every ~30 seconds and then after doing that 10 or so times started to broadcast 6 red blinks followed by a series of faster blinks
" bad_every_3_core-firmware.bin" the same behaviour as in test 1 but just took a bit longer for the issue to appear
āgood_20_sec_inactivity_core-firmware.binā had 6 red blinks followed by a couple of faster red blinks in less then 30 second of loading the firmware
āgood_32sec_inactivitiy_core-firmware.binā seems to be ticking along nicely and no error is reporting. Will run this test for a bit longer to see if any strange comes along.
Yes if you count the blinks after the SOS ā¦āā¦ Blinks and report back the number that is the error code. My guess is it will be 6. See āFound an Issueā above
Please give good_32_sec_inactivity_core-firmware.bin and let us know if it works ok.
I tried out all the binaries. good_32sec_inactivitiy_core-firmware.bin seems to be the most stable but it still ends up in CFOD after a few minutes. Unfortunately, it did not recover.
Update: It does recover most of the time!
Iām not monitoring the serial log yet. Will update soon.
Here is the serial output from running good_32_sec_inactivity_core-firmware.bin for 1 minute without any problem. How long test do you want to have? It is hard to force a CFOD and it might take hours so thats quite long logs.
Iāve the Coreās worst test network at the office here. Its a collection of Aerohive APs, that make the Core CFOD consistently within a few minutes. MIMO is CC3000ās worst nightmare.
Coreās worst test network at the office here. Its a collection of Aerohive APs, that make the Core CFOD consistently within a few minutes.