CC3000 : Error in loop back MSG (PC-CC300-PC)

In LoopBack Trace Send pkt are from PC to CC3000 and Recv Pkt is from CC300 to PC

Hi,

Kindly capture the wireshark and  Device logs as mentioned in below wiki.

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

The Log is in binary, once you share it, we will be able to analyze what goes wrong.

Also, please share the setup details ( MCU board etc) as well.

Regards,

Geet

Hi Geet,

Thanks for looking into it...

I don't have an access to Tx Rx UART pin, so as of now I can not take those treaces to analyze but I took some trace using wireshark, please look into it and see if you can trace the problem using it.

While capturing this I am sending a 1000 byte of data from PC to CC3000, Here is the attached code to recv and send data :

void ServerSendRecv()
{
	long sd = 0; 
	sockaddr saddrClient,saddrServer;
	long socketStatus = 0;
	socklen_t tSoclength ;
	int clientDescriptor = -1;
	int iLoop =0;
	int nNumOfBytesRecvd = 0;
	int nNumOfBytesSend = 0;
	unsigned long optval = 10000;
	int nret = 0;
	int Count = 0;
	char *StartAdd = DataRecvCC3000Buffer;
	
	for(Count = 0;Count < 1000; Count++)
	{
		DataSendCC3000Buffer[Count] = Count+10;
	}
	saddrClient.sa_family =  AF_INET;

	saddrServer.sa_family =  AF_INET;
	saddrServer.sa_data[0] = 0x20;saddrServer.sa_data[1] = 0x1D;    saddrServer.sa_data[2] = 0x00; 
	saddrServer.sa_data[3] = 0x00;saddrServer.sa_data[4] = 0x00;	saddrServer.sa_data[5] = 0x00;
	if((sd = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP)) < 0)
		return;

	if((socketStatus = bind(sd,&saddrServer,sizeof(saddrServer))) != 0)
		return;
		
	if((socketStatus = listen(sd,1)) != 0)
		return;
	tSoclength = sizeof(saddrClient);
	while(clientDescriptor < 0)
	{
		clientDescriptor = accept(sd,&saddrClient,&tSoclength);
	}
	
	MCF_GPIO_GPIO1_OUT |= MCF_GPIO_GPIO1_OUT_GPIO_OUT32;	//LG2 -CAN1 LED
	
	

	while(1)
	{
		nNumOfBytesRecvd = 0 ;
		bEnableUnSolEvent = 0;
		hci_unsolicited_event_handler();
		hci_unsolicited_event_handler();
		while(nNumOfBytesRecvd < 1000)
		{
			
			
			nNumOfBytesRecvd += recv(clientDescriptor,DataRecvCC3000Buffer ,CC3000_MAXIMAL_RX_SIZE  ,0);
			
			hci_unsolicited_event_handler();
			
			MCF_GPIO_GPIO1_OUT ^= MCF_GPIO_GPIO1_OUT_GPIO_OUT36;
		
		}
		
		if(nNumOfBytesRecvd)
		{
			nNumOfBytesSend = 0 ;
			if(nNumOfBytesRecvd >  1000)
			{
				nNumOfBytesRecvd = nNumOfBytesRecvd -1000;
				nNumOfBytesSend += send(clientDescriptor, DataSendCC3000Buffer , 1000, 0);
			}
			nNumOfBytesSend += send(clientDescriptor, DataSendCC3000Buffer , nNumOfBytesRecvd, 0);
			
				
			MCF_GPIO_GPIO_OUT  ^= MCF_GPIO_GPIO_OUT_GPIO_OUT29;
		}
		
	
		hci_unsolicited_event_handler();
	
	}
}

So if you look into the trace then you can see I am only less byte then transmitted but ideally it should be same as per written logic. and when I try to transmit data at higher rate then it will eventually lose the TCP connection

Platform detail : Host MCF5253 (FreeScale)

***

So if you look into the trace then you can see I am receiving less byte then transmitted but ideally it should be same as per written logic. and when I try to transmit data at higher rate then it will eventually lose the TCP connection

Did you see anything wrong in the log file, please update your comment

Hi,

I believe that we recently fixed that issue. It's currently under testing. It's caused by a race condition of issuing the send command and right after the recv command.

The official fix will be by a patch. The fix is planned to be out on our next official release V1.11.

In the meantime, could you please use the select command before issuing the recv command. I believe it should overcome the problem you're seeing.

Regards,

Tomer

Thanks Tomar,

I have a few more update on this issue.

In current situation I can able to do the communication in one direction without any problem, means at a time if I am doing only one operation then there is no issue.

Like if CC3000 keep on receiving a data from PC then it will work without any problem with high data rate(~2Mbps) and the same is true when CC3000 only sending a data to PC continuously without any delay in between two send operation.

But when I am making a loop type of application in which PC is sending a data to CC3000 then CC3000 sending back to PC then after some time it will reset the adapter and it seems like some memory violation issue to me, it does not stop in very first loop but it hit this condition after certain amount of time and if I will increase the time delay between two send operation in PC side then I can see better performance and it works for a long time, with the use of 150 ms delay in between two send operation in PC application I have seen it works for a long time and in this case it does not even reset the adapter  but it hangs somewhere in host driver.
Do you think changes made in V1.11 can help us to resolve the issue, if you can send me the patch before official release, only for testing then I can verify if this changes fix the issue.

I am using freescale micro-controller - MCF5253

I have already made one change in CC3000 to work with our compiler environment, after making this change I can able to Tx and Rx data in one direction.here is the change done by me:

unsigned
short STREAM_TO_UINT16_f(char* p, unsigned shortoffset)
{
//return (unsigned short)((unsigned short)((unsigned short)(*(p + offset + 1)) << 8) + (unsigned char)(*(p + offset)));
return (unsigned short)((unsigned short)(((unsigned short)(*(p + offset + 1)) << 8) & 0xFF00) + ((unsigned short)(*(p + offset))& 0x00FF));
}

unsigned
long STREAM_TO_UINT32_f(char* p, unsigned shortoffset)
{
//return (unsigned long)((unsigned long)((unsigned char)(*(p + offset + 3)) << 24) + (unsigned long)((unsigned char)(*(p + offset + 2)) << 16) +
//(unsigned long)((unsigned char)(*(p + offset + 1)) << 8) + (unsigned long)((unsigned char)(*(p + offset )) << 0));//(unsigned long)((unsigned long)(*(p + offset))));

return (unsigned long)((unsigned long)(((unsigned long)(*(p + offset + 3)) << 24) & 0xFF000000)|
+ (unsigned long)(((unsigned long)(*(p + offset + 2)) << 16) & 0x00FF0000)
+ (unsigned long)(((unsigned long)(*(p + offset + 1)) << 8) & 0x0000FF00)
+ (unsigned long)(((unsigned long)(*(p + offset )) << 0) & 0x000000FF));
}

 If I don't do this change then it will modify the value to very high value when working on (unsigned long)(((unsigned long)(*(p + offset )) << 0) & 0x000000FF));
Suppose it has E8 in this to convert then without this change the output was 0xFFFFFFE8, so to prevent from this condition I need to change this.

Do I need to make any other similar type of changes to make the host driver compatible to Freescale?

Also I am using a latest patch version 1.11.7.12.14 and using a host driver of 1.10.6.11 cause changes made in 1.11.712.14 was creating a problem in transmitting a data from CC3000 to PC and resetting the device(Memory exception issue)

Hi,

Yes, I believe it will fix the issue. Please see my reply on a different thread:

"The issue we have found is when doing a test in a loop back mode, meaning the CC3000 device receives a packet, and only then transmits the same packet to the PC (target). The scenario involves doing recv and right after send commands. Since recv is a blocking command by default, so if the socket is not defined with a timeout, the application would "hang" waiting for receiving some data.

Usually, a user should either use select command to identify if packets are waiting in the queue, or define a timeout for recv. In the specific scenario, there is no timeout defined.

The bug involves a race condition (corner case), where send is issued and right away recv command. The race condition causes the recv command to be executed before the "send", but it will wait forever, as the target device didn't receive the packet, and therefore will not transmit the next one."

Please send me an email directly to: tomer.kariv@ti.com for further discussion about the patch.

I tried the latest patch but it does not help me to resolve the issue which I am facing.

Our adapter is still getting reset while doing back to back Tx and Rx operation. PFA code running on adapter for Tx and Rx operation.

int initDriver(unsigned short patch)
{
	long lResult = 0;
	
	ulCC3000DHCP = 0;
	
	ulCC3000Connected = 0;
		
	ulSmartConfigFinished=0;
	
	bEnableUnSolEvent = 0;
		
	wlan_init( CC3000_UsynchCallback,NULL, NULL, NULL, ReadWlanInterruptPin, WlanInterruptEnable, WlanInterruptDisable, WriteWlanPin);

	wlan_start(patch);
	
	wlan_smart_config_set_prefix(aucCC3000_prefix);
    	
	wlan_set_event_mask(HCI_EVNT_WLAN_KEEPALIVE|HCI_EVNT_WLAN_UNSOL_INIT|HCI_EVNT_WLAN_ASYNC_PING_REPORT);
 
	ucStopSmartConfig   = 0;
	
	wlan_ioctl_set_connection_policy(0, 0, 0);	
	
	wlan_ioctl_del_profile(255);
	
	bEnableUnSolEvent = 1;//To Call hci_unsolicited_event_handler() in every 500ms
	
}

void ServerSendRecv()
{
	long sd = 0; 
	sockaddr saddrClient,saddrServer;
	long socketStatus = 0;
	socklen_t tSoclength ;
	int clientDescriptor = -1;
	int iLoop =0;
	int optlen;
	unsigned short nNumOfBytesRecvd = 0;
	unsigned char lengthBuffer[2];
	int nNumOfBytesSend = 0;
	unsigned long optval = 10000;
	int nret = 0;
	int Count = 0;
	char blinkLED =  0;
	char bCheck = 1;
	int  bTransmitter = 0;
	int bReceiver = 0;
	int nNumberOfBytesToSend = 0;
	int loop = 1;
	//fd_set readfds, active_readfds;
	//fd_set writefds, active_writefds;
	struct timeval timeout;
	//int iRet;

	for(Count = 0;Count < CC3000_MAXIMAL_TX_SIZE; Count++)
	{
		DataSendCC3000Buffer[Count] = (char)0x00;
	}
	saddrClient.sa_family =  AF_INET;

	saddrServer.sa_family =  AF_INET;
	saddrServer.sa_data[0] = 0x04;saddrServer.sa_data[1] = 0xB4;    saddrServer.sa_data[2] = 0x00; 
	saddrServer.sa_data[3] = 0x00;saddrServer.sa_data[4] = 0x00;	saddrServer.sa_data[5] = 0x00;
	if((sd = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP)) < 0)
		return;

	if((socketStatus = bind(sd,&saddrServer,sizeof(sockaddr))) != 0)
		return;
		
	if((socketStatus = listen(sd,1)) != 0)
		return;
	
	tSoclength = sizeof(saddrClient);

	nNumOfBytesRecvd = 0 ;
	
	bEnableUnSolEvent =0;//Stop calling from system thered and call directly from this routine
	
	while(1)
	{
		
		
		hci_unsolicited_event_handler();
		
		while(clientDescriptor < 0)
		{
			clientDescriptor = accept(sd,&saddrClient,&tSoclength);
			//if(clientDescriptor >= 0)
			//{
			//	FD_ZERO(&writefds);
			//	FD_SET(clientDescriptor,&writefds);
			//	FD_ZERO(&readfds);
			//	FD_SET(clientDescriptor,&readfds);
			//	timeout.tv_sec = 0;
			//	timeout.tv_usec = 0;
			//}
		}
		
		hci_unsolicited_event_handler();
		
		MCF_GPIO_GPIO1_OUT |= MCF_GPIO_GPIO1_OUT_GPIO_OUT32;	//LG2 -CAN1 LED
		
		nNumOfBytesRecvd = 0 ;
		
		
		
		//active_readfds = readfds;
		//iRet = select(clientDescriptor + 1, &active_readfds, NULL, NULL, &timeout);  
		//if(iRet > 0)
		//{
		nNumOfBytesRecvd = recv(clientDescriptor,&DataRecvCC3000Buffer[0] ,CC3000_MAXIMAL_RX_SIZE  ,0);
		if(blinkLED++ > 3)
		{
			blinkLED = 0;
			MCF_GPIO_GPIO1_OUT ^= MCF_GPIO_GPIO1_OUT_GPIO_OUT36;
		}
		hci_unsolicited_event_handler();
		//}
		
		
		nNumberOfBytesToSend  = 100;//I tried with differen value also, but if I use big value then host driver control get stuck in loop of MAGIC 					    //NUmber
		//active_writefds = writefds;
		//iRet = select(clientDescriptor + 1,  NULL, &active_writefds, NULL, &timeout);
		//nNumberOfBytesToSend = 100;
		nNumOfBytesSend = 0 ;
		//if(iRet > 0)
		//{
		nNumOfBytesSend = send(clientDescriptor, &DataSendCC3000Buffer[0] , nNumberOfBytesToSend , 0);
		
		if(blinkLED++ > 3)
		{
			blinkLED = 0;
			MCF_GPIO_GPIO_OUT  ^= MCF_GPIO_GPIO_OUT_GPIO_OUT29;
		}
		hci_unsolicited_event_handler();
		//}
			
	}
}


main()
{
	long lStatus1=0,lStatus2 = 0,lStatus3 = 0;
	
	unsigned char ucstatus = 0;
	
	tNetappIpconfigRetArgs  ipconfig;
	
	init_spi();
	wlan_connect(WLAN_SEC_UNSEC,(char*)"default",7,NULL,NULL,NULL);
	while ((ulCC3000Connected == 0) || (ulCC3000DHCP == 0))
	{				
		hci_unsolicited_event_handler();	
	}
	lStatus1 = 0;
	while(lStatus1 != 3)
	{
		lStatus1 = wlan_ioctl_statusget();
	}
	hci_unsolicited_event_handler();
	ipconfig.aucIP[0] = 0x00;
	while(ipconfig.aucIP[0] == 0)
	{
		netapp_ipconfig(&ipconfig);
		hci_unsolicited_event_handler();
	}
	ServerSendRecv();
}


//But if I will modify the function ServerSendRecv to only Transmit or Receive the data at a time then the same code works smoothly.

Here are the buffer value received while doing a wlan_start :

usSlBufferLength = 6

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Threading;
using System.Net;
using System.Net.Sockets;
namespace ClientForm
{

    public partial class Client : Form
    {


        public static bool bReadThreadStop;
        public static bool bSendThreadStop;
        public static bool bCC3000ThreadTestStop;
        private IPConfig ClientConnectionInfo;
        private IPAddress RemoteIPAddress;
        private IPEndPoint RemoteEndPoint;
        private Socket ClientC;
        private EventWaitHandle ConnectDone;
        private EventWaitHandle SendDone;
        private EventWaitHandle ReceiveDone;
        private EventWaitHandle SendNextPacket;


        private string textConnectedClient;
        private int NumberOfBytesSent;
        private int NumnerOfBytesRead;
        private int SumNumberOfBytesSent;
        private int SumNumnerOfBytesRead;
        private int RxMsgCount;
        private int TotalNumberofBytesRead;
        private bool ConnectSucess;
        private byte[] ReceiveDataBuffer;

        bool bSendMsg;
        byte Loop;
        private bool bPartialMsg;
        private int nNumofBytesToRead;
        private short nMsgLength;
        private byte PartialByte;
        private delegate void UpdateTextDelegate();


        public Client()
        {
            InitializeComponent();

            ConnectDone = new EventWaitHandle(false, EventResetMode.AutoReset);

            SendDone = new EventWaitHandle(false, EventResetMode.AutoReset);

            ReceiveDone = new EventWaitHandle(false, EventResetMode.AutoReset);

            SendNextPacket = new EventWaitHandle(false, EventResetMode.AutoReset);

            textConnectedClient = null;

            NumberOfBytesSent = 0;

            NumnerOfBytesRead = 0;
            Loop = 0;


            SumNumberOfBytesSent = 0;

            SumNumnerOfBytesRead = 0;

            bReadThreadStop = false;

            bSendThreadStop = false;

            ConnectSucess = false;

            ReceiveDataBuffer = new byte[5000];

            TotalNumberofBytesRead = 0;

            RxMsgCount = 0;

            textConnectedServer.Text = "";

            bSendMsg = false;

            bCC3000ThreadTestStop = false;

            bPartialMsg = false;

            nNumofBytesToRead = 2;

            nMsgLength = 0;

            PartialByte = 0;

            Update();
        }


        private void ConnectToServer_Click(object sender, EventArgs e)
        {

            try
            {
                ClientConnectionInfo = new IPConfig();

                ClientConnectionInfo.ShowDialog();

                ClientConnectionInfo.ConnectEvent.WaitOne();


                RemoteIPAddress = IPAddress.Parse(ClientConnectionInfo.RemoteIPaddress);

                RemoteEndPoint = new IPEndPoint(RemoteIPAddress, Convert.ToInt32(ClientConnectionInfo.RemotePortNumber));

                ClientC = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

                ClientC.BeginConnect(RemoteEndPoint, new AsyncCallback(ConnectCallback), ClientC);

                ConnectDone.WaitOne();

                if (ConnectSucess == true)
                {
                    bReadThreadStop = false;

                    bSendThreadStop = false;

                    bCC3000ThreadTestStop = false;

                    ConnectToServer.Enabled = false;


                    Thread ReadMsgThread = new Thread(new ThreadStart(ReadMsgThreadProc));

                    ReadMsgThread.Start();



                }
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

                bSendThreadStop = true;

                bReadThreadStop = true;

                bCC3000ThreadTestStop = true;

                ConnectToServer.Enabled = true;
            }
        }

        private void ConnectCallback(IAsyncResult ar)
        {
            try
            {
                /*
                // Retrieve the socket from the state object.
                Socket client = (Socket)ar.AsyncState;

                // Complete the connection.
                client.EndConnect(ar);
                */

                ClientC = (Socket)ar.AsyncState;

                // Complete the connection.
                ClientC.EndConnect(ar);
                //MessageBox.Show("Socket connected to {0}",client.RemoteEndPoint.ToString());
                textConnectedClient = "Socket connected to " + ClientC.RemoteEndPoint.ToString();

                ConnecetedClient.BeginInvoke(new UpdateTextDelegate(UpdateClientConnectedText));

                ConnectSucess = true;

            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

                ConnectSucess = false;
            }

            // Signal that the connection has been made.
            ConnectDone.Set();
        }

        private void SendMsg_Click(object sender, EventArgs e)
        {
            try
            {
                SendMsg.Enabled = false;

                Thread SendMsgThread = new Thread(new ThreadStart(SendMsgThreadProc));

                SendMsgThread.Start();

            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

                bSendThreadStop = true;

                SendMsg.Enabled = true;
            }
        }
        
        public void SendMsgThreadProc()
        {
            try
            {
                bSendThreadStop = false;

                while (bSendThreadStop == false)
                {
                    int i = 0, j = 0;

                    byte[] byteData = new byte[Convert.ToInt32(MsgLength.Text)];//Take the lenght of MSG from user

                    for (j = 0; (j < Convert.ToInt32(EditMSGCount.Text))/*Number of times MSG to send of the legth received from user*/ && (bSendThreadStop == false); j++)
                    {
                        for (i = 0; i < byteData.Length; i++)
                        {
                            byteData[i] = (byte)(i + 1);
                        }

                        Loop++;

                        ClientC.BeginSend(byteData, 0, byteData.Length, 0, new AsyncCallback(SendCallback), ClientC);

                        SendDone.WaitOne();

                        Thread.Sleep(Convert.ToInt32(Delay.Text));//I generally  use 10 ms of delay in between two send operation while sending a data of 100 bytes to CC3000
                    }
                    bSendThreadStop = true;


                }

            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

            }
            bSendThreadStop = false;

            SendMsg.BeginInvoke(new UpdateTextDelegate(EnableSemdMSgButton));

        }
    
        private void SendCallback(IAsyncResult ar)
        {
            try
            {
                int BytesSent = 0;

                // Retrieve the socket from the state object.
                Socket client = (Socket)ar.AsyncState;

                // Complete sending the data to the remote device.
                BytesSent = client.EndSend(ar);
                NumberOfBytesSent += BytesSent;
                SumNumberOfBytesSent += BytesSent;

            }
            catch (Exception ex)
            {
                bSendThreadStop = true;

                bReadThreadStop = true;

                bCC3000ThreadTestStop = true;

                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

            }
            // Signal that all bytes have been sent or error occur.
            SendDone.Set();
        }
        
        public void ReadMsgThreadProc()
        {
            try
            {
                while (bReadThreadStop == false)
                {
                    // Begin receiving the data from the remote device.
                    ClientC.BeginReceive(ReceiveDataBuffer, 0, ReceiveDataBuffer.Length, 0, new AsyncCallback(ReceiveCallback), ClientC);
     
                    ReceiveDone.WaitOne();

                    SendNextPacket.Set();

     


                }
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

                bSendThreadStop = true;

                bReadThreadStop = true;

                ConnectToServer.Enabled = true;
            }
            RxMsgCount = 0;

        }

        private void ReceiveCallback(IAsyncResult ar)
        {
            try
            {
                Socket client = (Socket)ar.AsyncState;

                // Read data from the remote device.
                NumnerOfBytesRead = client.EndReceive(ar);

                TotalNumberofBytesRead += NumnerOfBytesRead;

                SumNumnerOfBytesRead += NumnerOfBytesRead;

                RxMsgCount++;

                if (RxEnable.Checked == true)
                {
                    RxMSGBox.BeginInvoke(new UpdateTextDelegate(UpdateReadMsgText));
                }
                else
                {
                    ReceiveDone.Set();
                }
                bSendMsg = true;

            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Source + " : " + ex.Message, ex.HelpLink, MessageBoxButtons.OK, MessageBoxIcon.Error);

                bSendThreadStop = true;

                bReadThreadStop = true;

                bCC3000ThreadTestStop = true;

                ConnectToServer.Enabled = true;

                ReceiveDone.Set();
            }
            //Temporary Place, Need to change the location when start displaying MSGS
            //ReceiveDone.Set();
        }

        
         
        private void UpdateSendMSgRateText()
        {
            SendMsgRate.Text = NumberOfBytesSent.ToString();

            TotalSend.Text = SumNumberOfBytesSent.ToString();

            NumberOfBytesSent = 0;
        }

        private void UpdateClientConnectedText()
        {
            textConnectedServer.Text = textConnectedClient;



            textConnectedClient = null;
        }

        private void UpdateReadMSgRateText()
        {
            ReadMsgRate.Text = TotalNumberofBytesRead.ToString();

            TotalRead.Text = SumNumnerOfBytesRead.ToString();

            TotalNumberofBytesRead = 0;
        }

        private void EnableSemdMSgButton()
        {
            SendMsg.Enabled = true;
        }

        private void UpdateReadMsgText()
        {

            string S = "";

            S = "Msg Count : " + RxMsgCount.ToString() + " ; " + "Msg Length : " + NumnerOfBytesRead.ToString();
            //S = "Msg Count : " + RxMsgCount.ToString() + " ; " + "Msg Length : " + nMsgLength.ToString();

            RxMSGBox.Text += (S + Environment.NewLine);

            Application.DoEvents();

            Update();

            NumnerOfBytesRead = 0;
            RxMSGBox.SelectionStart = RxMSGBox.Text.Length;
            RxMSGBox.ScrollToCaret();
            ReceiveDone.Set();
        }

        private void Timer_1Sec_Tick(object sender, EventArgs e)
        {

            SendMsgRate.BeginInvoke(new UpdateTextDelegate(UpdateSendMSgRateText));

            ReadMsgRate.BeginInvoke(new UpdateTextDelegate(UpdateReadMSgRateText));
        }

        private void DisconnectFromServer_Click(object sender, EventArgs e)
        {

            bReadThreadStop = true;

            bSendThreadStop = true;

            bCC3000ThreadTestStop = true;

            ConnectToServer.Enabled = true;

            ReceiveDone.Set();

            SendDone.Set();


        }



    }
}

Hi Abhishek,

Regarding your queries:

1. When it is stuck on while(0 == tSLInformation.usNumberOfFreeBuffers), it means that the pool of TX buffers in CC3000 is fully occupied. The use case you describe is back 2 back of send/recv. So if the PC (client) is pending on receive from the server (CC3000), and only then sends a new packet, how can it be that the CC3000 sends more than one packet at a time? Can you describe the PC side in terms of procedure, length of each packet, etc?
2. When it is stuck on if (wlan_tx_buffer[CC3000_TX_BUFFER_SIZE - 1] != CC3000_BUFFER_MAGIC_NUMBER), it means you have a memory overrun on the TX buffer. Can you please share the complete code running on the host driver?

Apart from these observations, it is hard to know what is wrong with no driver logger.

I'll go over the air sniffer and provide feedback.

Shlomi

Hi, At least regarding the second scenario, the problem is that you try to receive data of size CC3000_TX_BUFFER_SIZE which is the size of your RX buffer (defined in CC3000_common.h). But this size should contain the payload data and also the SPI header, HCI header and arguments. You can see explanations in the same file (CC3000_common.h): Given the maximal data size MAX_DATA that is expected to be received by application, the required buffer is: Using recv() or recvfrom(): max(CC3000_MINIMAL_RX_SIZE, MAX_DATA + HEADERS_SIZE_DATA + fromlen + ucArgsize + 1) Since TCP is a stream data, when you stress from the PC, the data gets piled up at the Network Stack of CC3000. When you try to receive data of CC3000_TX_BUFFER_SIZE (1520 bytes), it actually gets: 1520+10 (SPI and HCI headers)+24 (args) = 1554 bytes. This is why you get the overrun. And this is why you see in the SPI the large value. When you add a delay between packets, any receive would give you what is already in the CC3000 RX buffers which is probably a single packet, i.e. 1200 bytes and then you are OK. Please use 1460 bytes when you invoke recv() API. Regarding the first scenario, I still need to take a look. Shlomi

Hi,
Thanks for the suggestion, reducing the size of buffer will help us to solve the problem of Buffer over run but still I can see the adapter is getting reset.
We got the drive log also, see the attached file for driver log and and wireshark log file.
To reproduce the adapter reset condition I am sending a 100 bytes of data from PC application without any delay and in adapter side on reception of 100 bytes it sends back 100 byte of data.

8686.Trace.zip

Hi

We have made some changes in host driver code which reduce the frequency of getting adapter reset.
So I have taken a trace with the latest released (  P1.11.7.12.14.) and also with the unreleased patch (P1.1X)sent by you when adapter does not get reset.

Here is the observation on  P1.11.7.12.14(Last Released Patch):

Back to back recv and send operation runs for sometime and then control get stuck in recv API call and it never returns from here, please find the attached trace for the scenario and please confirm if it is the same issue reported as a bug in this release.

2474.P1.11.7.12.14Trace.zip

Observation on P1.1X(unreleased version) :

In this version while doing the same operation as above, control get stuck in send API and it never return from here. In the send api control get stuck in SimpleLinkWaitEventfunction . please find the attached trace for it.
8473.P1.1XUnrelasedPatch.zip

And if you can confirm the issue from the trace taken with P1.11.7.12.14 is the same as bug reported then why the fix made in P1.1X is not resolving the issue for us.

please give your input on it.

Hi,

I analyzed the logs that you provided, and indeed I could see some issue. can you please tell if you integrated Shlomi's changes in the host as well?

Can you please provide your application code? I'd like to try reproducing at my place. 

Thanks,

Tomer

Hi,

Can you also make sure recv is called from the host all the time? It's like rx queue in the device is full..

Can you also specify the SPI clock?

Thanks,

Tomer

Hi Tomar,

 Thanks for looking into the traces.

SPI Baud rate : I tried with 8 as well 16 mhz but the result is same in both the case.

Also I merge the latest change in host driver code for the latest driver I received from Shlomi.

I am attaching the code of Host Driver and application running on adapter(Diagnosis_Thread.c),

Also I am sending an applition which I am using at my end to run on PC, you can directly use the exe if you want to.
2376.HostDriverAndAdapterSideApp.zip

7536.PCApp.zip

To reproduce the error at your end do the following steps :
1. Establish connection with adapter (use connect button to specify IP addr and port number)
2.  Use edit control box to specify Msg Length (100)  and Msg Count (1000000).
3. Click on send button.

So in the above case client application will keep on sending a data and on reception of this data on adapter side adapter will reply with 100 byte of data back to pc application.

Whereas if you enable the EnableLoop checkbox then client application will wait for sending a next packet until it receive a response from adapter and in this case I did not see any problem and Tx Rx is working fine but this will reduce the overall data rate of communication and which is not acceptable.

Hi,

I believe that I've succeeded to reproduce the issue with your instructions.

I'm currently analyzing the problem, and will update you as soon as I find something.

Regards,

Tomer

Hi,

While using your application I could see the TCP connection got reset, but I could only reproduce it whenI defined the RX buffer to be small (let's say around 100 bytes, in your case it's defined to be maximum - 1460).

What happened is that the Rx and Tx queues got filled, and since there's flow control in the host, the application is blocked, and the recv function was not called. Therefore the buffers were not freed, and TCP ack was not received. 

This can be solved by disabling the flow control in the host level. This results in packet not transmitted to the cc3000 device, and then right away, recv function will be called.

The application is in charge to re-transmit the packet when no flow control is enabled.

Please note, that I'm not sure if this is what you actually see. Please try to disable the flow control. In order to do this, please add the following define in your host driver: SEND_NON_BLOCKING (add that to your workspace).

If that doesn't fix the issue, please send another set of air capture + NS log (FW is not required), but this time, please enable more logs by issuing the following command in the application (should be after init_driver):

netapp_set_debug_level(0x1FF);

Thanks,

Tomer

Hi Tomar,

I tried with SEND_NON_BLOCKING Macro also but the result is same.

I was trying to set the debug level to said value but could not get netapp_set_debug_level() function anywhere in the host driver code.

I am using the latest host driver code and update this with the files received from sholami.

Pleas let me know how to get the detailed trace using latest host driver code

Please find the attached traces for following condition :
1. Enable Send_Non_Blocking Macro :Here I divided wireshark trace in two parts due to limitation on size of uploading file
7077.SendNonBlockingWiresharkTracePart1.zip
0804.SendNonBlockingWireSharkTracePart2.zip

|�8�D�
$	O




$

$	O




$

$	O




$

$	O




$

#
|�8�D�
$	O




$

$	O




$

$	O




$

$	O




$

|�8�D�
$	O




$
VU�!��
��0j�
.
p	�8=���
F
/02v	Y
+","2-"K�
2,"� "-"?2,"�-"�2,"��"-"�2," 1�"-"�2,"`1�"-"�2,"��"-"�
�!+���
+���


+l�
+l�+6n

=
>
?*5(B�0
� 
�
��D��
�(� �\
�0���l�|��
� Z(
[�
{Td�b�r�
	
	

	
	
	
	
	
�
^

]

�
@
	
	
		
�
�
�
l

i	

	

	
	
	

�
�
	
	
	
	
	
	
	
�
�
�
�
�-sP*
t
u
v-w

x%Ё

:

�
o!


-e�

�
�
� !
�
�
�n!w
�-
m!-m!����
m!''''-e@-e�-e�
e-e-e-e-e�-e�
-e�-e�-e-e-e-e-e-e-e-e-e-e-e-e#-e-eF
-e9-e4-eE-e-ea-eO-e-e-e8&-e$-eN-e4-e%-e1
e

e
-eI-e&-e&-e&-e-eR-eQ-eQ-eQ-eQ-eQ-eQ-eQ-eQ-e/e/P�-eS-e--eP-e>-e?-e\-e]"
]-e
`
\
�-
	T�-��]-eK-eD
@

�|@
KX
L
	
	
	^@

$+,!TTT4_New_FTC-2!_length_modulati+,!D��UI
�DI,!-2!��lhF�
+,!�U0�<\ 


�%



p
sH�
5#defa
8#defa
4
e3-
	�
$#defa
!#��
,#
-
!#��

,#
-
!#��
,#
-
!#��
,#
-

$-�8&�&-�8&-e

�	
F
�

G#
��
A
	
�
�
�

�	�
s	�
|
�
	-e-e?-e4
d-
	�j


Q
t	
-e=D



	

#���r	�|�+,!	
DWJh-2!
*�Hc!��&�HW-T! _New_FTC#���/
���
/


$


$


$


$


$


$

|�8�D�

$


$


$


$
II

$



$


$



$

|�8�D�

$



$


$



$


$



$

#

$



$


$



$

|�8�D�

$



$


$



$


$



$


|�8�D�











|�8�D�







|�8�D�


|�8�D�




|�8�D�






|�8�D�




$




$

|�8�D�

|�8�D�








|�8�D�




|�8�D�




|�8�D�






|�8�D�




|�8�D�


|�8�D�



$;



$



|�8�D�





|�8�D�



|�8�D�


|�8�D�





|�8�D�





|�8�D�




|�8�D�





|�8�D�


$	W


$



|�8�D�




















|�8�D�









|�8�D�














|�8�D�













|�8�D�














$�



$


$�



$

#
|�8�D�

$�




$


$�



$


$�



$


$�



$

|�8�D�

$� 



$


$�#



$

Hi,

I will analyze the logs, but in the meantime,  in order to add more logs:

netapp_set_debug_level(0x1FF);

//*****************************************************************************
//
//! netapp_set_debug_level
//!
//! @param[in] level debug level. Bitwise [0-8],
//! 0(disable)or 1(enable).\n Bitwise map: 0 - Critical
//! message, 1 information message, 2 - core messages, 3 -
//! HCI messages, 4 - Network stack messages, 5 - wlan
//! messages, 6 - wlan driver messages, 7 - epprom messages,
//! 8 - general messages. Default: 0x13f. Saved: no
//!
//! @return On success, zero is returned. On error, -1 is returned
//!
//! @brief Debug messages sent via the UART debug channel, this function
//! enable/disable the debug level
//!
//*****************************************************************************

#ifndef CC3000_TINY_DRIVER
long netapp_set_debug_level(unsigned long ulLevel)
{
signed char scRet;
unsigned char *ptr, *args;

scRet = EFAIL;
ptr = tSLInformation.pucTxCommandBuffer;
args = (ptr + HEADERS_SIZE_CMD);

//
// Fill in temporary command buffer
//
args = UINT32_TO_STREAM(args, ulLevel);

//
// Initiate a HCI command
//
hci_command_send(HCI_NETAPP_SET_DEBUG_LEVEL, ptr, NETAPP_SET_DEBUG_LEVEL_PARAMS_LEN);

//
// Wait for command complete event
//
SimpleLinkWaitEvent(HCI_NETAPP_SET_DEBUG_LEVEL, &scRet);

return(scRet);

}
#endif

Here is the trace with more logs enable using netapp_set_debug_level

1. Enable SEND_NON_BLOCKING macro :
1212.SendNonBlockingTrace.zip

2. Disable SEND_NON_BLOCKING macro (Regular) :
5758.SendBlockingTrace.zip

Still the result is same and host driver stop responding after a while.

Let me know if you need anything else to debug the issue

Hi,

The wireshark captures can't be opened. Can you please tell how you captured them and re-verify they can be opened at your place?

Thanks,

Tomer

Hi,

I have noticed that the files are just saved as text files, so was able to open them eventually. Would appreciate if you could send them in pcapng next time or any other omnipeek or wireshark format.

In the blocking case, I could observe the issue that I saw at my place, where tx and rx queue got filled, and since the tx is a blocking function by default, the recv function could not be called, which eventually led to socket inactivity timeout. 

In the nonblocking flag test, which should fix this issue, I couldn't observe the disconnection as a result of this. In fact, according to the log file you attached, the rx queue got filled up, then you call the send function, but then I can't see any more recv calls, therefore, the rx queue is stack, which eventually lead to socket inactivity timeout.

Can you tell what was the state of the application? as from the log, the recv function is not being called.

In parallel, I'm continuing to investigate the logs.

Regards,

Tomer

Sorry for delayed response , thanks for looking into the traces , currently I am working on non blocking send call and let you know the place where application get stuck.

Looks like there is some problem in blocking implementation, so is there any fix for this issue?

hey Tomar,

I got the new traces for non blocking call in the said format.

PFA zip file

3364.NonBlockingTrace.zip

while doing send recv control get stuck in following sequence on host driver code
1. Send() -> simple_link_send -> SimpleLinkWaitEvent -> hci_event_handler -> tSLInformation.usEventOrDataReceived != 0

Hi,

Regarding the blocking implementation of send, there is no bug, but expected behavior. When the tx queue is full in the device, the host will be blocked, and therefore, recv will not be called. Since recv is not called, rx queue gets full, which might lead to sock inactivity timeout if tx is blocked for too long.

Thank you for the logs that you sent. I will review them now and feedback.

Regards,

Tomer

Hi,

In both blocking and non blocking logs that you provided us, we've found two things that we would like to analyze better. We will work on them and update you in the next few days.

Please note that as a workaround, I believe that adding a short delay between send and recv, or either adding a select before rx will probably "solve" the issue.

Regards,

Tomer

Hi,

I believe the problem is related to TCP retry packets sent with original (old) ack number, and not with the latest received value. This is probably confusing the remote side's application. I'm running the test with your application for almost an hour and it's still running smoothly. Previously, it stopped after a very short time, or actually stopped on the first TCP retry.

Please try the evaluation patch I sent you over email, and let me know if it solves the issue. If it does, I will integrate the fix, so it will be a part of our next official release. 

Please remember to set the host's flow control to non blocking.

Regards,

Tomer

Hi Tomar,

I tried with this patch and definitely I can see some improvement in performance and now control is not getting stuck in Send API call but I have seen one different behaviour while doing a testing :
I use following paramter while doing testing :
1. Msg Count - 100000000
2. Msg Length - 100

So initially when application starts I am getting Bytes Receive per second is ~ 15000 (Data from CC3000 to PC) but after running for a while it will come down to 100 bytes/ sec.

Do you see thesame behaviour at your end?

_Hi,

very glad to hear. I didn't check the throughput, will do that tomorrow morning. I left a night run with these exact parameters before I left the office.

in order to understand the throughput, would appreciate if you can provide me air captures, as the low throughput might be related to a lot of tcp retries. Another suggestion is maybe try to conduct the test in a shielded room, or any other isolated env.

Regards,

Tomer

Hi,

I tested this today, and I can not see the tx throughput drops. The average I see is around 10,000 bytes/sec, and I'm testing in a very congested environments.

In order to analyze, please send air capture, and if possible, also the driver logs. I believe it's due to lots of TCP retrys sent from the CC3000 device.

Regards,

Tomer