I am running this in an endless loop
wlan_stop() wait for 1 s wlan_start(0) waiting for CONNECTED callback waiting for DHCP callback (fast connect is enabled, so this takes 1100-2100ms) create TCP socket connect() send() recv() closesocket() waiting for CAN_SHUT_DOWN callback (always takes 1000ms BTW. Why?) goto start
a
The problem is that the connect() fails in roughly 1% of all cases for no apparent reason.
Tcpdump on the host reveals that the connect() statement sometimes issues no network pakets at all to the hosts (e.g. no TCP SYN, no ARP). The CC3000 then sits there and apparently waits for the connection to be accepted which of course never happens. Sometimes the ARP packet from the CC3000 and the correct ARP response from the host can be seen, but no TCP SYN pakets follow.
Packet loss on the network cannot explain this scenario as the CC3000 is then obliged to retransmit the connection request after a short (few seconds, rather than minues) timeout.
The above behavior is with the SP 1.7 firmware. With the old Firmware (SP1.5?) the erroneous behavior described above was reproducible in 100% of all cases, unless one was waiting for 2000ms after the DHCP callback manually, then it was still reproducible in 1% of the cases as described above.
Cheers,
Johannes
Hi Johannes,
Are you catching any errors in case the socket API returns with a -1 value. Could you share the code, I would like to reproduce.
Pedro
Hi Pedro,
yes, I am catching all errors. The code above is pretty much what I am doing.
I must clarify what happens, since my description above is not really precise:
- In 99% (roughly) of all cases connect() works as expected after a wlan_stop()/wlan_start(0)/wait_for_DHCP_callback()
- In the remaining 1% of all cases connect never returns and blocks indefinitely (for at least 15 minutes or so). This is while the remote server is perfectly up and running and accepting connections.
The problem is that the CC3000 never sends any TCP SYN packets to the remote server, but the CC3000 waits for the connection to be established. Sometimes ARP packets are sent (as expected) and sometimes not even ARP packets are seen.
To reproduce this just run wlan_stop()/wlan_start(0)/connect() in a tight loop as described above. You will find this loop always stops after 50-200 iterations.
As a probably related issue you can try sending UDP packets after wlan_stop()/wlan_start(0): In 75% of all cases these will not be sent. In 25% of all cases the first packet and all following packets will get sent, but in the remaining 75% the first 10 tries to send a UDP packet will all consistently fail, which is when I give up (and reset the CC3000 again).
Thanks for the input, we will look into it and update you.
Thanks,Alon.S
I can verify that I am also seeing the behavior that Johannes describes running Firmware Version 1.7. In some cases, the CC3000 will hang during connect() for one or more minutes and never send a SYN packet. This problem will persist throughout a full MCU Reset / CC3000 INIT / Associate / DHCP sequence. After retrying for some time, the problem will go away for a period of time, but then come back.
Has this issue been verified by TI? Is there an ETA for a Firmware Release that is supposed to fix this?
Thanks, Caleb
Hi Caleb,
We have fixed this issue in our upcoming release.The release should be out this month.We will post a message in the forum once the new release is out.