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.

CC3000 send() issue

Other Parts Discussed in Thread: MSP430F5232, MSP430FR5736, CC3100

Hi Everyone,

I am currently using Basic WiFi Application project based on CC3000 + Host MCU(MSP430F5232), and it did the smartconfig, DHCP, TCP socket connection with no problem. Then I add select(), recv() and send() functions in a while(1) loop, trying to communicate with the sever setup in my PC. What I found is the Host MCU is able to receive and send the data from/to the server, but only one time. I mean once the server sends the data again, the Host MCU can not recevie any more.

After checking further, I found, during the period of send() function, it got stuck in hci_event_handler() waiting for tSLInformation.usEventOrDataReceived to be true. I also checked the IRQ line, finding that, before the first loop of receiving and sending, I can see the IRQ line going dow periodicaly, which i believe triggerred due to the select() function, but after first loop of receiving and sending, the IRQ did not goes down any more, that's why the interrupt routine can not be excuted any more. 

The code I am using has actually been verified in Home Automation project, because previously, I was using the CC3000 + MSP430FR5736, due to it's limited resource, I changed to MSP430F5232. For that configuration, the code was running very well. It was able to communicate with the server continuously without any problem. And then I compared the very detailed spi buffer between the HA and BWA, no matter spi tx buffer or spi rx buffer, I did not find any thing defferent. This issue has troubled me 2 days, anyone has any suggestion will be highly apprecaited! Thank you very much!

here is the code i am using:


unsigned char setupSocketConnection(void)
{
int ret, i;
long maxFD;
fd_set readsds;
timeval timeout;
memset(&timeout, 0, sizeof(timeval));
timeout.tv_sec = 1;
timeout.tv_usec = 0; //50*100;
volatile int bytesRecvd = 0;
volatile long bytesSent = 0;

RSCSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

if (RSCSocket == EFAIL)
{
wlan_stop();
return EFAIL;
}

RSCSocketAddr.sa_family = AF_INET;

RSCSocketAddr.sa_data[0] = (RSCServerPort & 0xFF00) >> 8;
RSCSocketAddr.sa_data[1] = (RSCServerPort & 0x00FF);

//correcting the endianess
RSCSocketAddr.sa_data[2] = RSCServerIP[0]; // First octet of destination IP
RSCSocketAddr.sa_data[3] = RSCServerIP[1]; // Second Octet of destination IP
RSCSocketAddr.sa_data[4] = RSCServerIP[2]; // Third Octet of destination IP
RSCSocketAddr.sa_data[5] = RSCServerIP[3]; // Fourth Octet of destination IP

//Connect the CC3000 WiFi module to the RSC server...by Andy 20140627
RSCServerFlag = connect(RSCSocket, &RSCSocketAddr, sizeof(RSCSocketAddr));
if (RSCServerFlag < 0)
{
// Unable to connect
return EFAIL;
}
else
{
RSCServerFlag = 1;
//setCC3000MachineState(CC3000_CONNECTED_WITH_SERVER);
while(1)
{

//Add client socket ID to to the read set
FD_SET(RSCSocket, &readsds);
maxFD = RSCSocket + 1;

ret = select(maxFD, &readsds, NULL, NULL, &timeout);
if(ret > 0)
{
memset(RxBuf, 0, CLIENT_RECV_BUF_SIZE);
bytesRecvd = recv(RSCSocket, RxBuf, CLIENT_RECV_BUF_SIZE, 0);
if(bytesRecvd > 0)
turnLedOn(LED1);
else
turnLedOff(LED1);
}
else
{
turnLedOff(LED1);
}


__no_operation();
__delay_cycles(10000);


ret = select(maxFD, NULL, &readsds, NULL, &timeout);
if(ret > 0)
{
bytesSent = send(RSCSocket, TxBuf, sizeof(TxBuf), 0);
if (bytesSent != sizeof(TxBuf))
{
turnLedOff(LED1);
}
else
turnLedOn(LED1);
}
else
{
turnLedOff(LED1);

// Here needs to check if connection is closed
// ...
}


}
//success
}

//return 0;

}

  • By the way, I did the patch driver/firmware when i was doing home automation, for basic wifi application, do i need to do the patch too? 

  • After futher analysis, I found the SPI recevice buffer difference between the Home Automation and Basic WiFi Applicaiton. Once the HCI_CMND_SEND(0x1003) has been sent to CC3000, it will get response two times from CC3000, i can see the IRQ was triggerred two times, which means the CC3000 responsed two times. 

    Here are the two picutures i captured to show the spi receive buffer in Home Automation project. But for Basic WiFi Application, there is only one time of receiving from CC3000, and it was approved that I can only see the IRQ was triggered one time. The second picture is the same as i got in Basic WiFi Application, as you can see, the command is to free the buffer (0x4100, HCI_EVNT_DATA_UNSOL_FREE_BUFF), and i traced the code, approving it is the reason why the code got stuck.

    But I still do not know for the configuration of MSP430F5232 + CC3000 with Basic WiFi Application, it only receives one time of spi buffer after sending the HCI_CMND_SEND command.  Is it because I have not patched the CC3000? The CC3000 with MSP430FR5736 had been patched before. 

  • Hi Andy,

    After every send command you should get a HCI_EVNT_SEND event, but you need not necessarily get HCI_EVNT_DATA_UNSOL_FREE_BUFF event everytime. That should not be a problem. Can you please trace the flow on your host and understand what happens after your application receives the HCI_EVNT_SEND event? Doesn't this event notify the 'send()' API in your application at all?

    Thanks & Regards,
    Raghavendra

  • Hi Raghavendra,

    Thanks a lot for your quickly response. 

    I did trace the code many times, finding that the the host MCU can only receive the  HCI_EVNT_DATA_UNSOL_FREE_BUFF event from CC3000 after sending the HCI_CMND_SEND to CC3000.

    But for the Home Automation project I tested before, it was able to receive both HCI_EVNT_SEND and HCI_EVNT_DATA_UNSOL_FREE_BUFF events, and then successfully jump out of the while(1) loop and go to execute the select() funciton in my application loop. 

    Could it be related with the patch programs because this is the new lot of CC3000 which i did not run the patch? 

     

    Andy

  • Really...?!?, because I have to wait for it to come back or the CC3000 wont respond afterwards, at all, so what am I doing wrong?  How are we supposed to handle an event that may or may not come?  If I dont wait for it, it will just interrupt something else.  Can someone please start answering the hard questions? Please, because the only thing that works for me is resetting the CC3000.

    Thanks,

    Chad

  • CC3000 uses internal buffers for send and sendto and it frees them at it's own pace, which explains why the HCI_EVNT_DATA_UNSOL_FREE_BUFF might or might not arrive in a specific timeframe.

    If you send lots of data back-to-back, then CC3000 will emit HCI_EVNT_DATA_UNSOL_FREE_BUFF faster, if you just send one packet, it waits quite a bit before it will emit the HCI_EVNT_DATA_UNSOL_FREE_BUFF.

    Thus in the code using send or sendto one should not wait for the HCI_EVNT_DATA_UNSOL_FREE_BUFF event, in case there are still buffers available. But note that it is up to user code to make sure the buffers are not depleted. When initializing CC3000, a HCI_CMND_READ_BUFFER_SIZE should be issued to find out the buffer count. At each send or sendto this internal counter should be decremented with 1. At reception of each HCI_EVNT_DATA_UNSOL_FREE_BUFF the available buffer count should be incremented again in user code, BUT note that not always with 1 as the number of buffers freed (given in HCI_EVNT_DATA_UNSOL_FREE_BUFF message) might be higher than 1.

    In case when using the TI CC3000HostDriver code, it is important to know that when buffers are depleted, issuing further send or sendto messages will cause the TI CC3000HostDriver to block and wait until one or more buffers get freed (when CC3000 has freed some buffers, it will tell this to CC3000HostDriver by emitting a HCI_EVNT_DATA_UNSOL_FREE_BUFF message).

    Cheers,
    Risto

  • Hi Risto,

    It's really great to have your reply. You know, I was trying to figure out what's the exact meaning of the HCI_CMND_READ_BUFFER_SIZE, but failed. Your reply is very helpful for me to understand it. 

    And today, I have fixed the issue. As I suspected before, it is due to the lack of service pack. After I run the patch programs, the issue was gone. Right now, my wifi module is able to recv/send data from/to the server continuously and it works very well.

    Also thanks a lot for Raghavendra's suggestion by email. 

    Andy 

  • Risto,

    Thanks for the help, I didnt realize HCI_EVNT_DATA_UNSOL_FREE_BUFF could come back and tell you about freeing more than one buffer at a time.  Once I referenced http://processors.wiki.ti.com/index.php/CC3000_HCI_EVNT_messages#HCI_EVNT_DATA_UNSOL_FREE_BUFF_.280x4100.29 I quickly realized where the command was freeing more than one buffer at a time and my problem seems to be fixed now with the send command as I havent seen it hang up all weekend.  Thanks for all your help in this forum, TI should truly be paying you or at least sending you some cool freebies for all your time helping there customers.

    Thanks,

    Chad

  • Hi Andy and Chad,
    I am very glad to have been a help to you guys!

    Chad: TI should truly be paying you or at least sending you some cool freebies for all your time helping there customers.

    Thanks for the kind words (wink, wink TI?)! But seriously, I would rather have TI publish official interface documentation that would save me and a number of other customers not wanting to only use the provided HostDriver lots of time reverse engineering and guessing what is going on under the hood.

    Maybe if someone from TI is reading this, TI could start publishing protocol data starting with CC3100, similarly to what I have gathered for CC3000 under CC3000 HCI Protocol Wiki and subpages HCI Commands, HCI Data, HCI Patch and HCI Events.

    Raghavendra, may I ask you to relay this wish inside TI further! Many customers are interested in developing fully their own code and the non-existing CC3x00 interface documentation has been the biggest hurdle in properly achieving this. By publishing the (official) interface documentation, you will IMHO not only reach broader market but will also have less support issues to deal with. Surely providing a generic host driver is great for a wide audience, but most of your high volume expert customers buying wireless LAN modules are engineers, and an engineer can only engineer well, if he/she understands the underlying technology.

    Cheers,
    Risto

  • Hi Andy,

         I encounter the same problem as you. Can you explain more detail about the patch programs? What functions should be called or what should be set befor sending data?

         Thank u.

    Allen

  • Hi, my problem is probably similar, it is few days I am trying to understand what is going on.

    I am using CC3000 Host driver v1.12. I have RTOS tirtos_tivac_2_00_01_23   and I run 2 tasks.

    One task performs:

    clientfd = accept(lSocket, (sockaddr*)&client_addr, &addrlen);

    if (clientfd != SOC_IN_PROGRESS)

    {

           if (clientfd == -1) {

                  System_printf("accept failed\n");

                  closesocket(lSocket);

           }

           else{

           nbytes = recv(clientfd, buffer, TCPPACKETSIZE, 0);

           if (nbytes > 0) {

                   // Echo the data back

                  send(clientfd, buffer, nbytes, 0 );

           }

    }

    Everything works fine the first time. I connect an external device, I use TCP, send data to the CC300, receive data back...everything fine

    ... but after send () my two task are blocked forever. I use semaphores to activate the tasks , the semaphores are working fine but the tasks are never ready(they were working fine until send() ).

    I tried to see what happens after send(). The data is actually sent back to my external device then I checked the semaphores of the SPI and hci_event_handler and it seems that they are working fine and the

    WiFiTivaCC3000_triggerRxProcessing looks ok to me.

    ..but I stall in:

    Void Task_schedule()

    /* stall until a task is ready */

    while (Task_module->curSet == 0) {

    Task_allBlockedFunction();

    }

    Any Suggestions?

     Gian

     

     

  • Hi   & Yang Xu,

     

    Patch program is actually the prvious name of the service pack provided by TI. You can download it from TI's website. The service pack is in fact a frimware running in host MCU, but it consists of image data of  two parts: driver patch and firmware patch. Once the service pack runs in host MCU, it will actually program the driver and firmware of CC3000 via SPI. Since the driver/firmware bug of CC3000 is unavoidable, so TI uses this method to fix it. 

    So you have to run the service pack before to do any firmware design based on you host MCU. And since the host MCU you are using could be different with the one that service pack uses, you may have to port the code of the service pack to fit it in your own host MCU. Luckly, the porting work is not very difficuty, you just need to change the SPI interface and possiblly the clock initialization codes. Once you get the service pack running correctly, I believe you will get your issue fixed. 

     

    Andy

  • Thanks Andy,

    I have updated the service pack many times in the last few months and I have the right application for my MCU. I know TI is going to release an update this month so I will use the update as soon as it is available.

    For now, the only thing I can do is to understand more in deep what the issue is, in the past I have found out you can't call CC3000 drivers in a timer/clock routine...and other similar issue but...now I think I am pretty close to have the SW running, at least it runs until, after send() my task is blocked.

    I am trying to analyze the task behavior using Execution Graph.

    For me it looks like I never return from send().

    If anybody has had the same issue and found the root cause I would really appreciate some help.

    Thanks Andy

    G.

  • so..as I suspected I never return from send(); 

    Can anybody explain what exactly the MCU should receive fro CC300 after sending data with send()?

    The data are sent...so I guess the host Driver is waiting to close the loop when it receives something from CC3000.

    I have noticed that after send() the semaphore_post() is not done and there is just 1 unsolicited event (event_type =0x0000000A), so stuck in my task....

    I checked what happens with recv() (this works fine), in this case when I send data to the CC3000 from an external device then I receive 2 events: the fist has event_type =0x0000000A the second is event_type =0x00000000.

    Any idea?

    Thanks

    Gian

  • Hi Andy,

    I think I have the same problem you had. May I know which version of patch fixed the issue?

    Thanks

    Gian

  • Ok, problem fixed. It was the patch. I have v1.13 now and recv/send are working fine...but...after this modification

    mdnsAdvertiser is not working anymore (it was working fine before). Any known issue that affects mdnsAdvertiser with patch programmer v1.13?

    Thanks

    Gian

  • Hi,

    Yes, there is a known issue with mDns on 1.13. For mdns related issues on 1.13, please refer to the below thread: http://e2e.ti.com/support/wireless_connectivity/f/851/p/342177/1197251.aspx#1197251


    Thanks & Regards,
    Raghavendra