Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I have an existing embedded application running on a BCM943362. This embedded application communicates with an app on an iOS device using sockets, and with a web service (apache server hosted on AWS), also using sockets. It is all pretty basic stuff and follows the tcp client/server example code. I use wiced_tcp_send_packet (or wiced_tcp_send_buffer) for example. I originally developed this under v3.1.2 of the Wiced SDK and it seemed to be working properly.
I have now moved to v3.3.1 of the SDK. I now find that I can send a packet to my web service, but when it is received there is data missing. I am sending a POST with some JSON data in the http body. I send a total of 358 bytes (including http headers and http body), but only 349 bytes are received, and it is the last portion of the buffer that is missing (i.e. the last few bytes of the JSON). I don't see anything missing in the middle of the received buffer. I do not receive any errors from Wiced and the tx buffer looks good deep down at the point where nx_tcp_socket_send is being called. This is very repeatable.
I am also seeing instances where entire packets are missing when sending to an iOS device. Again, everything looks good, no errors on the embedded side.
I am working on an Over the Air Update process that downloads about 600K system images with TCP using WICED 3.3.1 and fails every time. Frequently I don't get all of the bytes that were sent, but on rare occasions I do, but a checksum shows that the data is corrupted even when all bytes are received. The bizarre thing is that when all packets are received, the checksum seems to give the same number, so TCP seems to be consistent in the way it corrupts the data. We are going back to using WICED 3.1.2.
I have the same issue. I managed to make it work most of the time (but the code involves lot of retransmission), but I still get failures. I didn't try out the latest SDK yet, but the differences in the provided code don't seem to solve any issue related to this.