I am running this in an endless loop
wait for 1 s
waiting for CONNECTED callback
waiting for DHCP callback
(fast connect is enabled, so this takes 1100-2100ms)
create TCP socket
waiting for CAN_SHUT_DOWN callback (always takes 1000ms BTW. Why?)
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.
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.
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.
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?
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.