• State
  • Locked Locked
  • Replies 61 replies
  • Subscribers 41 subscribers
  • Views 3591 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3301: The WiFi firmware occasionally drops packets, causing the TCP transmission speed to drop to 0(R6 version)

yuan yang
Prodigy 190 points
Part Number: CC3301
Other Parts Discussed in Thread: CC3351

Tool/software:

We have seen wifi transfer suddenly stop during bigger downloads (FOTA). A simpler testcase is running iperf, and the test often stops before the 10 seconds finishing. The testcase here is simply enabling iperf3 in the firmware, connecting to wifi and running iperf over the wifi link.  Our analysis suggests that the WiFi firmware loses received packets over a period of time, leading to TCP transmission interruptions, but this situation can be recovered.  The question is how to prevent this situation from happening? 

  

[08:30:36.213] # iperf3 -s
...
[08:31:49.391] Server [192.168.5.94] listening on [5201]
[08:31:49.391] -----------------------------------------------------------
[08:31:55.115] Accepted connection from 192.168.5.1, port 46328
[08:31:55.539] [  5] local 192.168.5.94 port 5201 connected to 192.168.5.1 port 46330
[08:31:56.553] [ ID] Interval           Transfer     Bandwidth
[08:31:56.553] [  5]   0.00-1.00   sec  1.01 MBytes  8.44 Mbits/sec                  
[08:31:57.905] [  5]   1.00-2.36   sec  761 KBytes  4.60 Mbits/sec                  
[08:31:58.549] [  5]   2.36-3.00   sec  1.56 MBytes  20.3 Mbits/sec                  
[08:31:59.549] [  5]   3.00-4.00   sec  2.58 MBytes  21.7 Mbits/sec                  
[08:32:00.549] [  5]   4.00-5.00   sec  2.50 MBytes  21.0 Mbits/sec                  
[08:32:01.549] [  5]   5.00-6.00   sec  2.08 MBytes  17.5 Mbits/sec                  
[08:32:02.550] [  5]   6.00-7.00   sec  1.85 MBytes  15.6 Mbits/sec                  
[08:32:03.545] [  5]   7.00-8.00   sec  1.60 MBytes  13.4 Mbits/sec                  
[08:32:04.925] [  5]   8.00-9.38   sec  686 KBytes  4.08 Mbits/sec                  
[08:32:05.550] [  5]   9.38-10.00  sec  115 KBytes  1.51 Mbits/sec                  
[08:32:06.555] [  5]  10.00-11.01  sec  0.00 Bytes  0.00 bits/sec                  <<<<
[08:32:07.555] [  5]  11.01-12.01  sec  0.00 Bytes  0.00 bits/sec                  
[08:32:08.555] [  5]  12.01-13.01  sec  0.00 Bytes  0.00 bits/sec                  
[08:32:09.555] [  5]  13.01-14.01  sec  0.00 Bytes  0.00 bits/sec                  
...
  • 0 in reply to yuan yang
    TI__Mastermind 31130 points

    Hi Yuan,

    We think we have a theory on why the throughput suddenly drops, but it is dependent on the IRQ scheme. Do you know if your IRQ is using EDGE interrupt or LEVEL interrupt? We think that your host is missing the EDGE interrupt and thus loses communication temporarily.

  • 0 in reply to Sabeeh Khan1
    Prodigy 190 points

    Hi Sabeeh

    This is an issue of lost interrupts. We have already identified this problem and added a timeout-based polling mechanism in the main loop to check the interrupt status, thereby avoiding transmission interruptions. However, the timeout duration is set to 1 second, so I believe the frequent 1-second transmission pauses we encountered earlier might be caused by this. I conducted a test by reducing the timeout to 100ms, and the issue was significantly improved.

  • 0 in reply to yuan yang
    TI__Mastermind 31130 points

    Hi Yuan,

    The cc33xx is intended to be used with LEVEL interrupts. If your MCU host supports, I would recommend using LEVEL interrupts in order to not miss an interrupt. If this hardware interrupt is working correctly, then you could possibly remove the polling mechanism.

    So I am guessing your host only uses EDGE type interrupts and that is why sometimes the interrupt from CC33xx would be missed, correct?

  • 0 in reply to Sabeeh Khan1
    Prodigy 190 points

    Hi Sabeeh

    We used sdio interrupts in our product, not use OOB interrupts, so polling mechanism is necessary.

    Thanks.

  • 0 in reply to yuan yang
    Prodigy 190 points

    Hi Sabeeh

    Here is sniffer log for tp link TL-WR886N router

  • 0 in reply to yuan yang
    Prodigy 190 points

    Hi Sabeeh

    Here is a new sniffer log for tp link TL-WR886N router

  • 0 in reply to yuan yang
    Prodigy 190 points

    I have moved the router away for testing(fw version 1.7.5.310). The RSSI value is -45. After testing iperf for 24 hours, the results show that iperf was not interrupted, but there were still observed cases where the rate dropped to 0. This test result is an improvement compared to the old version of the fw(1.7.0.301). When testing iperf with the old version of the firmware, iperf would be interrupted.

  • 0 in reply to yuan yang
    Prodigy 190 points

    Hi Sabeeh

    I have uploaded the sniffer file (tcpdrop_issue.7z) of new fw to https://tidrive.ext.ti.com/userportal/?v=4.6.1#/shared/public/41CR4HrQkfLxUJHu/6e69507b-7d3c-477b-95d7-dcb58a70ab43

    The problem seems easy to reproduce at certain times, but it returns to normal after changing the channel. It is likely related to network interference.

  • 0 in reply to yuan yang
    TI__Mastermind 31130 points

    Hi Yuan,

    I'm not sure I follow what you are describing. What do you mean "returns to normal after changing the channel"? Are you connecting to a different AP on a different wifi channel? Do you believe the issue you are seeing is not related to the CC33x?

  • 0 in reply to Sabeeh Khan1
    TI__Mastermind 31130 points

    Looking at the sniffer capture, I think I see what you mean by the network interference. From about 167 seconds to about 180 seconds there are many TCP retransmissions. 

    Are you able to test in a more quiet environment like a anechoic chamber?

  • 0 in reply to Sabeeh Khan1
    Prodigy 190 points

    Many TCP retransmissions, does it be assumed that the air interface was busy, resulting in packet loss? This situation did not occur in subsequent tests, so there is no relevant packet capture data available.