I am currently involved with a project based on Particle photon, which uses BCM 43362 chip as wifi module. In the firmware level, it uses wiced_tcp_send_buffer() to perform tcp blocking send. Currently we are trying to send 2466bytes packet for every 100ms to the server.
However sometimes, it looks like the wiced_tcp_send_buffer() will return 16 error [WOULD BLOCK]. And the problem is that, when this error occurs, there are actually some data arrives at the server, which breaks the designed protocol. For example, if I sent 2466 bytes using BCM chip, I only received 1024 bytes at the server when would block error returned by wiced_tcp_send_buffer, i.e. the corrupted packages, which brought huge problems to us.
I am wondering is there any way to resolve this issue, which means:
- if wiced_tcp_send_buffer() sent successfully, then ALL data should arrive at server;
- if wiced_tcp_send_buffer() doesn't sent successfully (for example the would block error), then NO data should arrive at server (we don't want to receive corrupted data on the server side..).
As a reference, I used the gcc-arm-none-eabi as the tool chain to compile and build the firmware and application code, however I am not sure what version of wiced library I am using. The following are the gcc-arm-none-eabi version I used: And I am thinking whether the bug can be resolved if I use newer version of gcc-arm-none-eabi toolchain??
Status: install ok installed
Maintainer: Ubuntu Developers <email@example.com>
Depends: libc6 (>= 2.14), libgmp10, libmpc3, libmpfr4 (>= 3.1.3), zlib1g (>= 1:1.1.4), binutils-arm-none-eabi
Description: GCC cross compiler for ARM Cortex-A/R/M processors
Bare metal compiler for embedded ARM chips using Cortex-M, Cortex-R and
This package is based on the GNU ARM toolchain provided by ARM.
Original-Maintainer: Agustin Henze <firstname.lastname@example.org>
Finally as a reference, to resolve this issue, I tried to send smaller size of package for multiple times, for example:
for every 100ms, instead of sending 2466 bytes, i sent
- 1233 bytes for twice;
- 1024 bytes for twice and 418 bytes;
It can resolve the issue if there are only few devices. However the error will eventually occur if I increase the number of device to over 10 (we believe the server shall have ability to handle such amount of requests).
Thanks for the suggestions!