This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Patch version 1.11.1 - new host driver SDK? (spurious socket connect events, tcp close wait)

Other Parts Discussed in Thread: MSP430G2553

I'm working with the CC3000 and have encountered a problem where the CC3000 sends unexpected command completion events. The specific case is a SOCKET_CONNECT command completion; the status code is -1. This appears to always happen in response to a SOCKET_ACCEPT command. Generally speaking, simply ignoring the unexpected SOCKET_CONNECT completion results in a SOCKET_ACCEPT completion with an error status, and the next SOCKET_ACCEPT works as expected.

However, I am also seeing unexpected TCP_CLOSE_WAIT events, apparently always after SOCKET_RECV. In this case, the SOCKET_RECV does not complete.

Sample code looks like this - I know it's ugly :-)  Taken from a hacked MSP430G2553 demo app

	i = wlan_connect(WLAN_SEC_WPA2, "ssid", strlen("ssid"), NULL,
	  "password", strlen("password"));

	while (ulCC3000DHCP == 0)
		;

	s1 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
	memset(&sa, 0, sizeof(sa));
	sa.sin_family = htons(AF_INET);
	sa.sin_port = htons(80);
	sa.sin_addr.s_addr = htonl(0);

	j = bind(s1, (const sockaddr *)&sa, sizeof(sa));

	while (1) {
 		k = listen(s1, 10);
 		do {
			salen = sizeof(si);
 		} while ((s2 = accept(s1, (sockaddr *) &si, &salen)) == -2);
 		if (s2 < 0) {
			continue;
		}
 		do {
			k = recv(s2, &recv_buf, 10, 0); // eat up the HTTP request header
		} while (k == 10);
 		j = send(s2, &send_buf, strlen(send_buf), 0); // send "test" as a response
 		closesocket(s2);
 	}

The test system does "while true ; do ; wget http://<ipaddr> ; done" and proceeds as normal for some time until it hangs as mentioned below.

My question is - the 1.11.1 release notes indicate unsolicited connect is handled in the host driver. Yet I do not see an SDK 1.11.1 version with an updated host driver, which may at least resolve the unsolicited connects I'm seeing. I vaguely suspect the unexpected TCP_CLOSE_WAIT event is the result of the CC3000 being confused about the state of an incoming connection - I would only expect to see TCP_CLOSE_WAIT in response to an outbound connection initiated by the CC3000.

I am running 1.24 of the firmware from the 1.11.1 patch programmer.

Is there an updated SDK 1.11.1 host driver source I should try?

  • I believe I've answered my own question. I looked in the Patch Programmer installation directory (I'd just used the Windows executables and hadn't looked) and found:

    C:\ti\PatchProgrammerMSP430G2553-2.11.7.14.24\Patch Programmer Source\Source

    Ah. Indeed, running recursive diff, I find that this is version 14 of the Host Driver, and there are handful of changes, several comment changes, and this change to evnt_handler.c:

    	//handle a case where unsolicited event arrived, but was not handled by any of the cases above
    	if ((event_type != tSLInformation.usRxEventOpcode) && (event_type != HCI_EVNT_PATCHES_REQ))
    	{
    		return(1);
    	}
    

    So, yes, there's a new release of  the Host Driver source, it just happens to be bundled in the patch programmer release.

    evnt_handler.c:hci_unsol_event_handler() now claims unsolicited command completions as unsolicited events. I don't think that functionally changes what happens - hci_event_handler() seemed to effectively ignore the unexpected socket connect already. For what it's worth, with the updated evnt_handler.c file, I still see the same hang scenario - a lot of unexpected socket connect completion events in response to an accept command and eventually a TCP close wait event and the hang in recv().

    The release notes for 1.11.1 mention ignoring unexpected socket connect command events - this sounds like a firmware issue to me.

  • Hi, 

    thanks for posting this information, i was also looking for SDK/Host driver upgrade.

    Do you know if TI team will officially release  this software ?

    for information, adding this patch in evnt_handler.c does not work at all on my side as software hangs in

    wlan_set_event_mask just after wlan_start,

    // Wait for command complete event

    SimpleLinkWaitEvent(HCI_CMND_EVENT_MASK, &ret);

     

    //handle a case where unsolicited event arrived, but was not handled by any of the cases above
    	if ((event_type != tSLInformation.usRxEventOpcode) && (event_type != HCI_EVNT_PATCHES_REQ))
    	{
    		return(1);
    	}

    removing the patch makes it work, but i also have unstabilities issues with connect that  sometimes fails 

    thanks 

    Lionel

  • I have seen the same thing with unexpected replies to SEND which caused my system to hang. In my case it was a simple fix in the event_handler.cpp to cater for the -1 status code. The change in host software 1.4 is not sufficient in my opinion.