Maximum transfer and stability function for the CC3000 problems

Martin Andersson

Other Parts Discussed in Thread: CC3200

I am trying to do a maximum transfer function to verify the stability and transfer rate of the CC3000, but the system hangs after 769 consecutive transfers. I have posted the part of the functions that I am having problems with.


void data_transfer(void)
{
	//A TCP connection is already active at this point.
	unsigned long Data16 = 2147483647;
	for(cch = 0; cch < (1440)/2; cch++)	
        //1440 bytes of maximum transfers on the cc3000, Data16 has the size of 2 byte.
	{
		Storage[cch] = Data16;
	}

	Int_Data = (unsigned long *)&Storage;
	DataLength = 1440;

	for(c = 0; c<500; c++)		//Transfer 500 packages with the total size of 720Kb
	{
		send(SOCKETClientTCP, (unsigned long*)Int_Data, DataLength, 0);
	}

	// CLEAR THE MEM BUFFERT
	memset(Storage, 0x00, sizeof(Storage));
	memset(Int_Data, 0x00, sizeof(Int_Data));
	free(Storage);
	free(Int_Data);
	//It is possible to run this function one time but on the second time it hangs up after a total of 769 transfers.
	//I can also change the amount of packages to 100 and it will then hang up on the 8th iteration.
	//The program stops in the function get_socket_active_status(long Sd) in evnt_handler.c every time. 
}

Am I missing a step when it comes to clearing a internal buffer in the CC3000 some how?

over 10 years ago

0 Marie Maurer over 10 years ago

Genius 4895 points

Hi Martin,

just some small comments:

- 2147483647 does not fit into 2 bytes. 2 bytes unsigned long has a maximum of 65535. 2147483647 seems to be the maximum of a signed long (when it is 4 bytes long).

- You do 2 frees at the end. I see no malloc. Are you sure you have allocated the correct amount of memory? And do allocation again when calling the function again?

- Why do you fill Storage and then cast it to Int_Data and use this for sending? Why not directly Storage?

- What else do you do before, between and after your function data_transfer?

- Have you checked on SPI e.g. via logic analyzer what is sent out and what is received to distinguish what the host is doing, what the CC3000 is doing and what error occur exactly?

- Why does get_socket_active_status stop? As far as I remember there is not even communication in this function, just checking variables in host, no while/for-loop, how can it stop here beside the host is crashing when accessing the variables?

Best regards,

Martin

0 Martin Andersson over 10 years ago in reply to Marie Maurer

Expert 1295 points

Hello Martin and thank you for helping me out here.

- I have corrected the size of the Data16 variable, just dumb mistake.

- I have added the way I allocate the ulStorage memory, should I use malloc instead of the fixed allocation?

- That was just some garbage from an old experiment and has now been rectified.

- All that is done before the the use of the data_transfer function is the startup of the system and everything works perfect right now, except the strange crash. I have changed the code so that I don´t have to do any input after the function is activated so right now the system starts up and then function is run and then it crashes.

- I have not checked with a logic analyzer since I haven´t wanted to spend that time just yet. I am using breakpoints on the lab computer and Wireshark on the receiving client computer to verify the data transfers.

- The function get_socket_active_status is not involved in the crash of the system, it just becomes active after a few seconds. Meaning the system does not crash byt is holding for a error of some sort. Below I have posted the sequences of the functions that are active at the stop. The last activated is the top posted function:

HostFlowControlConsumerBuff()

simple_link_send()

HandleUartCommand()

main()

In function HostFlowControlConsumerBuff() the program holds at the following code line(125):

if (SOCKET_STATUS_ACTIVE != get_socket_active_status(sd))

return -1;

In function simple_link_send() the program holds at the following code line(1021):

// Check the bsd_arguments

if (0 != (res = HostFlowControlConsumeBuff(sd)))

{

return res;

}

Variable c is at count 779.

Variable SEND_TCP is 1440 according to the amount of bytes sent.

I can send and receive any data that I want with the CC3000 to and from Matlab, but the CC3000 stops after sending 779 packages. I am going to go through my old backup files since this is something new, problem is that I don´t know when the maximum transfer function was working last. But it has worked before, but I believe it was when I was using UDP and not TCP.

//################################################################################
    //##################### CODE BELOW IS USED FOR THE TESTING #######################
    //################################################################################

	//################################################################################
	//########################### DUMMY DATA GENERATING ##############################
	//################################################################################
	int cch = 0;
	int size = 0;
	unsigned short Data16 = 0;	//16-bit = 2 byte in size, maximum value 65535
	unsigned short ulStorage[HALF_MEM_BUFFER_SIZE];

	for( cch = 0; cch < HALF_MEM_BUFFER_SIZE; cch++)
	{
		ulStorage[cch] = Data16;
		Data16++;
	}
	ulDataLength = 1440;
	//################################################################################
	//######################### THE END OF DATA GENERATING ###########################
	//################################################################################


	//################################################################################
	//################### MAXIMUM TRANSFER AND STABILITY TESTING #####################
	//################################################################################
	//Single Send command issued to make it possible to send multiple packages.
	*Prep_Data = 1;
	SEND_TCP = send(SOCKETClientTCP, (unsigned short *)Prep_Data, 1, 0);

	int c = 0;
	for(c = 0; c<1000; c++)
	{
		send(SOCKETClientTCP, (unsigned short *)&ulStorage, ulDataLength, 0);
	}

	// CLEAR THE MEM BUFFERT
	memset(ulStorage, 0x00, sizeof(ulStorage));
	memset(Prep_Data, 0x00, sizeof(Prep_Data));
	free(ulStorage);
	free(Prep_Data);
	//################################################################################
	//############################# THE END OF TESTING ###############################
	//################################################################################

0 Martin Andersson over 10 years ago in reply to Martin Andersson

Expert 1295 points

After looking at the data flow through the system I believe I have located the problem.

It looks like the internal memory buffer on the CC3000 gets filled up, I have added some printing to the HostFlowControlConsumeBuff() that keeps me updated on the amount of buffer that is available during the test. I get constant update through out the transfer and in the end of the transfer the following part of the function is activated: if(0 == tSLInformation. usNumberOfFreeBuffers )

How can I force a clearing of the buffer of the CC3000? Is the good logic to apply here for example I send 100 packages and then activate a separate function that will force a memory clearing or should I force a memory clearing after each transfer?

static int
HostFlowControlConsumeBuff(int sd)
{
#define SEND_NON_BLOCKING;
#ifndef SEND_NON_BLOCKING
    /* wait in busy loop */
    do
    {
        // In case last transmission failed then we will return the last failure
        // reason here.
        // Note that the buffer will not be allocated in this case
        if (tSLInformation.slTransmitDataError != 0)
        {
            errno = tSLInformation.slTransmitDataError;
            UARTprintf("NON: Transmission error code = %d\n", tSLInformation.usNumberOfFreeBuffers);
            tSLInformation.slTransmitDataError = 0;
            return errno;
        }

        if(SOCKET_STATUS_ACTIVE != get_socket_active_status(sd))
            return -1;
    }
    while(0 == tSLInformation.usNumberOfFreeBuffers);
    {

    	tSLInformation.usNumberOfFreeBuffers--;
    	UARTprintf("NON: Number of buffers free = %d\n", tSLInformation.usNumberOfFreeBuffers);
    	return 0;
    }
#else

    // In case last transmission failed then we will return the last failure
    // reason here.
    // Note that the buffer will not be allocated in this case
    if (tSLInformation.slTransmitDataError != 0)
    {
        errno = tSLInformation.slTransmitDataError;
        UARTprintf("Transmission error code = %d\n", tSLInformation.usNumberOfFreeBuffers);
        tSLInformation.slTransmitDataError = 0;
        return errno;
    }
    if(SOCKET_STATUS_ACTIVE != get_socket_active_status(sd))
        return -1;

    //If there are no available buffers, return -2. It is recommended to use
    // select or receive to see if there is any buffer occupied with received data
    // If so, call receive() to release the buffer.
    if(0 == tSLInformation.usNumberOfFreeBuffers)
    {
    	UARTprintf("No more buffers left = %d\n", tSLInformation.usNumberOfFreeBuffers);
    	//RECV_TCP = recv(SOCKETClientTCP, (unsigned short *)uiRx_Buffer, sizeof(uiRx_Buffer), 0);
    	//RECV_TCP = recv(SOCKETClientTCP, (unsigned short *)ucRx_Buffer, sizeof(ucRx_Buffer), 0);
        return -2;
    }
    else
    {
        tSLInformation.usNumberOfFreeBuffers--;
        UARTprintf("Number of buffers left = %d\n", tSLInformation.usNumberOfFreeBuffers);
        return 0;
    }
#endif
}

0 Raghavendra Shenoy over 10 years ago in reply to Martin Andersson

TI__Mastermind 27095 points

Hi Martin,

With respect to freeing of buffers, may be you should consider the MCU and Multi-threading support if required (for freeing up the blocks concurrently). I think it would be simpler and straight forward to clear memory after each transfer.

Thanks & Regards,

Raghavendra

0 Martin Andersson over 10 years ago in reply to Raghavendra Shenoy

Expert 1295 points

Right now I am using the Tiva C and that is the only MCU option that I have. Exactly HOW do I force clearing the internal memory of the CC3000?

0 Raghavendra Shenoy over 10 years ago in reply to Martin Andersson

TI__Mastermind 27095 points

Hi Martin,

Sorry I misunderstood it for the Tx buffers on the Host side. I don't think that you can clear the internal buffers on the controller.

Thanks & Regards,

Raghavendra

0 Joo Hong over 10 years ago in reply to Martin Andersson

Intellectual 280 points

Hi,

It looks like you have the similar problem that I have. It seems like there is a potential bug in the CC3000 TCP handling. I believe and hope the TI employees are looking into this problem.

Thanks

Joo

0 chad ely over 10 years ago in reply to Joo Hong

Intellectual 480 points

DEAR TI,

WE SEEM TO HAVE A BUFFER PROBLEM!!!!

THERE ARE SO MANY POSTS LATELY THAT HAVE ENCOUNTERED THE INTERNAL BUFFER ON THE CC3000 RUNNING OUT FOR NO APPARENT REASON. IT IS PRETTY CLEAR YOUR DEVICE HAS A SERIOUS PROBLEM. YOU NEED TO START TAKING US SERIOUSLY AND START SOME MAJOR TESTING OF THIS DEVICE.

I HAVE SPENT THE LAST 4 DAYS TRACING THE MDNS QUITS BROADCASTING ISSUE AND IT MOST DEFINITELY IS THE INTERNAL BUFFER FILLING UP. SOMETIMES IT CLEARS ITSELF OVER TIME SOMETIMES IT NEVER RECOVERS AND IT MUST BE RESET.

I AM NOT SURE WHAT WE HAVE TO DO TO GET THIS RESOLVED BUT YOUR ANSWER SEEMS TO BE THE SAME, SEND US THE DEBUG LOGS. WELL GUESS WHAT MOST OF US DIDN'T ROUTE THEM OUT DUE TO ANY NUMBER OF ISSUES. IF YOU HAD FOLLOWED THE REST OF THE INDUSTRY AND PROVIDED A NORMAL PACKAGE LAYOUT, YOU KNOW WHERE THE CONNECTIONS ARE ON THE SIDES AND IT CAN BE SOLDERED LIKE NORMAL, LIKE EVERY OTHER WIRELESS RADIO MODULE I HAVE EVER SEEN, THEN WE COULD SIMPLY DO THIS FOR YOU BUT WE CANT AND WE ARE ALL REALLY PISSED OFF.

I PERSONALLY HAVE SPENT SIX MONTHS TRYING TO DEVELOP A PRODUCT THAT SEEMS DOOMED! IT COULD HAVE BEEN SO MUCH DIFFERENT. YOU COULD HAVE PROVIDED US WITH OP CODE TABLES AND ERROR CODE TABLES AND IT WOULD HAVE BEEN SO MUCH EASIER. WE ASKED SO MANY TIMES FOR THEM WITH NO REAL ANSWER AS TO WHY YOU CANNOT PROVIDE THEM. WHY CANT YOU????????????????? CAN SOMEONE PLEASE ANSWER THIS???? WE WILL SIGN AN NDA IF WE HAVE TO! I HAVE HAD TO DO THIS BEFORE TO GET SUCH INFO BUT AT LEAST THEY SAW THE NEED TO GIVE IT TO THEIR DEVELOPERS.

I REALLY DON'T KNOW WHERE TO GO FROM HERE, MAYBE I SHOULD JUST GO BACK TO USING GAINSPAN AND PAY THEM $1000 TO USE THEIR PRODUCT, AT LEAST IT WAS RELIABLE. THIS CHIP WAS SUPPOSED TO BE AWESOME AND IT SO HAS THE CAPABILITY TO DO SO, BUT YOU MUST FIGURE IT OUT. I HAVE SEEN MANY PEOPLE GET FRUSTRATED ON THIS FORUM DUE TO LACK OF SUPPORT FROM TI. THIS IS YOU SUPPORT PORTAL AND YOU MUST LEARN TO SUPPORT IT BETTER. YOU MUST LEARN TO MAKE YOUR DEVICES MORE DEVELOPER FRIENDLY, YOU MUST LEARN TO WORK WITH THE PEOPLE WHO ARE WILLING TO PUT THE TIME IN TO MAKE YOUR PRODUCT BETTER AND THUS MAKE YOU MORE MONEY.

AND LET ME BE CLEAR THE LAST POINT IS THE MOST IMPORTANT, WE ARE TRYING TO HELP YOU, LET US HELP YOU, MAKE IT EASIER. I DID NOT SPEND THE LAST 6 MONTHS DEVELOPING TO LET SUCH A SIMPLE ISSUE STOP ME. YOU ARE A VERY LARGE COMPANY, ARE YOU WILLING TO ACTUALLY DEVOTE SOME RESOURCES TO GETTING THIS TO WORK? I AM WILLING TO HOST AN ENGINEER IN MY LAB TO FIGURE THIS OUT ONCE AND FOR ALL AND I AM SURE A LOT OF OTHER PEOPLE ARE.

WHAT EVER IT TAKES, THAT IS MY ATTITUDE, THAT IS THE AMERICAN ATTITUDE, IS THAT TI'S ATTITUDE? IF SO LETS START THINKING OUT OF THE "PLEASE GIVE A DEBUG LOG" BOX AND LETS GET THIS DONE!

CHAD

0 Joo Hong over 10 years ago in reply to chad ely

Intellectual 280 points

I believe they are looking into it, and I don't think the front line customer support engineers is capable of resolving these kind of bugs, and I hope the design engineers who writing the firmware can figure out what is going on or you will on your own. It takes long time to get some irrelevant response. Very frustrated!!!

0 Dmitry Bodnya over 10 years ago in reply to Joo Hong

Expert 1140 points

Completely agree with Chad!

Most important(and really actual) problems remains unresolved. CC3000 using solution becomes unreliable.

0 Martin Andersson over 10 years ago in reply to chad ely

Expert 1295 points

Well spoken Chad, I have been trying to develop a system with the CC3000 in it´s center for almost a year now and the level of support given are most times lacking and let´s not talk about the none existing manuals for the usage of the CC3000!

Right now I am forced to develop my system with asumption that this bug will be fixed some how in the next few weeks. But the level of severity this bug represents is enought to force my employer to look else where for a wifi solution!

0 Glenn Vassallo over 10 years ago in reply to Martin Andersson

Guru 21435 points

I am utterly shocked there has been no response from TI to this thread.

We are all assuming that this bug is being worked on, but no where has there been any official acknowledgement of this issue from TI. Instead we are all hoping issues are being worked on through hearsay.

Professional support organisations communicate with their customers, they let them know when there are bugs, and what is being done to resolve the bug. I know TI does this, as I have seen it occur in other forums, they even sometimes provide a bug number, which you can look up on an online bug reporting system.

0 Raghavendra Shenoy over 10 years ago in reply to Glenn Vassallo

TI__Mastermind 27095 points

Hi Glenn,

Thanks for your patience. We are looking into this issue. We will update you once we have something on this.

Thanks & Regards,

Raghavendra

0 Martin Andersson over 10 years ago in reply to Raghavendra Shenoy

Expert 1295 points

Over two weeks has passed now and still no update! What is happening?

0 Bill Harris over 10 years ago in reply to Martin Andersson

Prodigy 10 points

It's almost the end of 2014!! Any updates to this?

0 Martin Andersson over 10 years ago in reply to Bill Harris

Expert 1295 points

I killed this project because the CC3000 could´t handle it. I am involved in a new project working with the CC3200 and the new API is easy and much more mature so my tip would be to move over to that platform instead.

Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

Wi-Fi

Wi-Fi forum

Maximum transfer and stability function for the CC3000 problems