I've been trying to download a large system image for an Over The Air (OTA) firmware update and having large failure rates due to TCP 7014 errors which means the socket is closed. The system image file is roughly 600KB, so it can take anywhere from about 400 to 2000 packets to download the whole file depending on how much data is downloaded in each packet. Using WICED 4.1.1 on the BCM943907AEVAL1F board the download would fail about 60% of the time, on an Inventek 43362 shield it would fail closer to 20% of the time and on the Inventek 43340 shield it would fail about 10% of the time. A number of different factors seem to alter the frequency of download failures due to TCP 7014 errors, but what really seems to eliminate the problem is using a different server. I replaced the Google Cloud with an Apache server I installed on an old laptop running Fedora a few years ago and the problem seems to have gone away.
My boss says our development Google Cloud webserver is running on CentOS. I have seen some nginx error messages, so I assume that is the webserver. My boss says the TCP configuration for CentOS Linux kernel is pretty much unaltered from the out of the box solution that Google provides, so he has a hard time believing that the TCP configuration is flawed on the server. Does anyone know of any special configuration on the Google Cloud that would make it more suitable for IOT applications involving downloading large files?
An easy way to reproduce this TCP 7014 error on a WICED platform is add a 0.5 second delay between each call to wiced_tcp_receive() to simulate time required to process the downloaded data. In our actual OTA update code I copy the downloaded data into a buffer and delete the packet before I process that data. This seems to help with some other networking problems that I saw, but has little impact on the 7014 errors. In the example program that I have attached, I delete the packet before I use a delay to simulate processing the data. If you would prefer to hold on to the packet until simulated processing is complete, just move the packet delete after the delay. You should see the 7014 errors either way when downloading from a Google Cloud server like ours, and the 7014 errors should not happen when you use a local Apache server like ours instead. In the attached program I removed the wifi_config_dct.h file, so you will need to add one with your networking configuration information.
timeout.zip 5.5 K