• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 39 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 stops responding if too much data is received over wireless connection

Kevin Calcote
Prodigy 70 points

Hello, I have been using the CC3000 with a STM32F103x.  My current implementation is working fairly well and on average I achieve about 3.5 Mbps with an SPI clock set to 9 Mhz, no complaints there.

I currently have a test server setup on my embedded system which receives data from a connected client and then echos the received data back (used to do data integrity testing).  This is working pretty well, I can transfer GB's of data without error.  The only issue I am running into is if I set a breakpoint or insert a large delay (50ms+) between the receive from the client and send/echo to the client, the CC3000 stops responding and I can no longer ping it.

It appears the CC3000 is having a RX buffer overflow issue from the wireless side.  If I stop processing on the uC but continue to send from the PC then the CC3000 crashes.

Below is my basic test server code:

while(1)
{
   //Receive data
   int32_t rcvlen = recv(cli_socket, (char*)rx_buf, 1500, 0);

   if(rcvlen > 0)
   {
      int32_t bytes_sent = 0;
      
      //Keep track of receive bytes
      total_bytes_received += rcvlen;

      //NOTE:If delay or breakpoint put here then CC3000 stops responding!
      
      //Send all data back
      while (total_bytes_sent < total_bytes_received)
      {
         bytes_sent = send(cli_socket,
                           &rx_buf[rcvlen - (total_bytes_received-total_bytes_sent)],
                           total_bytes_received-total_bytes_sent,
                           0);
         
         if (bytes_sent > 0)
            total_bytes_sent += bytes_sent;
      }
   }
}

  • 0
    Prodigy 70 points

    If the number of bytes to send over the WiFi connection is large (~20K) then the issue occurs.  If I keep the value small then the issue does not occur.  This makes me believe the CC3000 is having some sort of RX buffer overflow problem.  It appears sending too much data to the CC3000 via wireless while the uC is not reading from the CC3000 will cause the CC3000 to crash due to a RX buffer overflow.

    Below is my python script used on the PC as the client connection:

    if sys.argv.__len__() > 1:
    server_address = (sys.argv[1], 1025)
else:
    server_address = ('192.168.1.101', 1025)

if sys.argv.__len__() > 2:
    array_size = int(sys.argv[2])
else:
    array_size = 1400

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(server_address)
total_sent = 0
total_received = 0
last_total = 0
start_time = time.time()

while True:
    sent = 0
    received = 0
    recv_data = ''
    send_data = bytearray(os.urandom(array_size))

    #Send data
    while sent < array_size:
        sent += s.send(send_data[sent:])

    total_sent += sent

    #Read back data
    while recv_data.__len__() < sent:
        recv_data += s.recv(sent-recv_data.__len__())

    total_received += recv_data.__len__()

    if 0 != cmp(recv_data, send_data):
        print 'Data does not match!'
        sys.exit(0)

    if ((total_received + total_sent) - last_total) > 1024000:
        last_total = total_received + total_sent
        time_run = time.time() - start_time
        print 'Total data transferred: ' + str(last_total/1024000) + ' MB' + ' at ' + "%.2f" % (((last_total*8)/time_run)/1024000) + ' Mbps'

  • 0
    Prodigy 70 points

    I looked into this some more and found that the CC3000 is not reducing it's advertised window size (MSS) as the CC3000 receives data over the wireless connection.  According to some research I have found online the CC3000 has four internal RX buffers (I am assuming they are 1460 bytes each since that is the advertised window size), I did a capture and found that once I stopped the micro-controller from reading data from the CC3000 it took five additional packets before the CC3000 crashed.  This makes me wonder if the CC3000 buffered the first four then crashed on the reception of the 5th one.  Remember, this is the wireless RX side of the CC3000.  TI, why is the window size (MSS) not being decreased to 0 once the buffers are full?  I believe advertising the proper available buffer would resolve this but I have no way to do this myself.

    Here is an image of the traffic I capture during the CC3000 crash.