Hi,
The issue we have found is when doing a test in a loop back mode, meaning the CC3000 device receives a packet, and only then transmits the same packet to the PC (target). The scenario involves doing recv and right after send commands. Since recv is a blocking command by default, so if the socket is not defined with a timeout, the application would "hang" waiting for receiving some data.
Usually, a user should either use select command to identify if packets are waiting in the queue, or define a timeout for recv. In the specific scenario, there is no timeout defined.
The bug involves a race condition, where send is issued and right away recv command. The race condition causes the recv command to be executed before the "send", but it will wait forever, as the target device didn't receive the packet, and therefore will not transmit the next one.
This specific case is not related to a race condition where packet is received in parallel to send being executed over the SPI lines. Therefore either defining a timeout, or using select would overcome that case.
Regards,
Tomer