Other Parts Discussed in Thread: CC3100
My application can connect to an HTTP Server and download a firmware update file that is around 3.5MB in size. I have 3 endpoints and 2 different WIFI networks from which I can download the file from and get different results depending on which WIFI network my application is connected to and which endpoint it uses.
WIFI Network 1 (AMT) - Security = WEP, this is much older WIFI hardware
WIFI Network 2 (ENGR) - Security = WPA2, a NetGear WNR3500
Server 1 (Staging) - An HTTP server hosted on Heroku, downloads from this endpoint use SSL
Server 2 (Production) - An HTTP server for the final application, downloads from this endpoint use SSL
Server 3 (S3) - Another HTTP server, the first 2 servers provide endpoints that return a link to this server for file download, downloads from this endpoint are not using SSL
The application downloads successfully almost always from Server 1 using either WIFI Network.
When connected to WIFI Network 1 (AMT), I will get about 1 out of 5 successful attempts from Server 2 (Production) or Server 3 (S3) and at varying times can get a much higher success rate around 4 out of 5.
When connected to WIFI Network 2 (ENGR), I will get about 1 out of 20 successful downloads from Server 2 (Production) or Server 3 (S3).
The file I am downloading is a .hex file (text file basically).
What I typically see is at the start there is lots of data when calling sl_recv (reading in 10240 chunks), then the process gets to varying points in the download and the amount data read from sl_recv drops off dramatically and often SL_EAGAIN is returned and then when data is available it is typically a few 100's of bytes. Once this starts it deteriorates to the point where calls to sl_recv always returns SL_EAGAIN. Where the data available rate falls off is variable and not some time into the process. Sometimes it occurs very early, within the first 100KB or it may get to 3.0MB+. Seems pretty random at this point how far into the download it gets before this starts to occur.
It kind of seems like my application does not read data via sl_recv fast enough. Didn't suspect this as TCP flow control should allow a slow client to receive data from a very fast server.
When downloading from Server 1 (Staging), there are periodic slow downs in the data available from sl_recv and SL_EAGAIN is returned periodically, not much different from the other Servers. Watching debugger outputs there doesn't seem to be any significant or obvious difference in the download process. Except the process completes successfully.
The application is attempting to read data from the TCP Stream and write it to a file on an SD card.
The application also can upload files to Server 1 and Server 2. There is never a problem uploading to the endpoints. The file it uploads can be 4.0MB+.
I don't know much or have any access to the how the servers are setup. A third party development team. The developers there have no idea of anything on the server side that might help and since the download works on other devices (PC's, tablets, phones) it becomes this apps problem.
Is it possible to not service the CC3100MOD receive buffer soon enough? Is a buffer overflow possible?
Is changing the PHY Data rate applicable to this issue?
The application is using a non-blocking socket using a polling method by calling sl_select. It looks like there are times where sl_select returns a read descriptor for the socket but when sl_recv is called the first time SL_EAGAIN is returned. Didn't expect this since the idea for sl_select was that data is available for reading. It seems that things start going bad, sl_recv returns SL_EAGAIN much more frequently.
Thanks for any help or ideas with this issue.
