Hello,
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.
Assaf,
it is not clear to me what you mean by opcode 03, 05 and 06270f. Can you elaborate what API you are calling in socket.c and what are the arguments you are passing to these APIs?
What I can say is that the return value of -57 indicates that the socket you are trying to receive from is closed.
Shlomi
Hi Assaf,
I managed to reproduce a similar behavior. It will be handled in next release as it requires some debugging and a new patch in the CC3000 itself.
What I can suggest is a work-around that seems to work for me.
Just before binding the socket to the local port address, send dummy data. Then bind the socket and you would be able to sendto/recvfrom with no constraints.
Please let me know if it works for you.
BR,
Shlomi
Hi Assaf,
The procedure is not exactly as you describe.
The steps are:
Btw, reading again your original post, I might understood it differently. You stated that on CC3000 you apply: socket, bind and then recvfrom (sending from another device). In this case, if you are not sending from the CC3000 and only receiving, I do not see any problem.
The error code of -57 means that the socket is not active (or not exsiting). It may be related to the fact that the socket is closed upon timeout.
I'm not sure what is the timeout you use for sockets but for testing you can manipulate it via netapp_timeout_values() API (not as part of BasicWiFiApplication so you need to call this API yourself).
Shlomi
I could not think of another reason why the socket is closed. 5 seconds is quite small number so I wouldn't expect the socket to close.
What I can share is that I apply the same test and it does work for me.
The only way is to start "playing" more with the socke. By playing I mean: try to send from CC3000 to another device, try TCP, try to disable the socket timeout as I explained, etc.
Shlomi