Matrix user forums

Firmware for a Wiz810MJ based Ethernet to serial converter PCB was developed using FC ver 7.3.0.6. The converter appeared to work well, but during 6 months of on-site testing some communication errors were experienced.

A Windows based test app showed that a communication error occurred after every few hundred data transmissions. The test data = "P=12345/r/n". There is no pattern as to when the comms errors occur, but about 10 or 11 comms errors occur in about 10 000 data transmissions. Running the test app on a commercially available Ethernet to Serial converter does not show any comms errors.

The problem was found to be with the Wiz810MJ not receiving the full TCP data packet. Using the RxDataAvailable and RxDataSize macros on the TCP_IP_EB023_00_2 component showed that only 1 byte was being received by the Wiz810MJ. The 1 byte received was always the first byte and the remaining 8 bytes of data were lost. This occurred every time there was a communications error. The converter's UART send and receive, and the TCP send, all work without any errors.

Has anyone experienced this or something similar with the Wiznet module? I would appreciate any suggestions as to what the probable cause is.

Kind regards.
Leo

Hi,

Further to the post above, I posted a similar question on the Wiznet forum and the reply from Eugeny Brychkov is as follows:

"Persistent connection assumes TCP, and you know that under TCP no data is expected to be lost by the protocol design, however it can be omitted due to incorrect data flow handling.
As you say another implementation works well, thus we assume that sending device is operating correctly.
It is important to know how remote device sends this data - does it send in single packet (7 bytes in one packet), or one character in one packet (thus 7 packets - some terminal programs work this way - it sends single char as soon as it is typed).
So I suspect that something wrong is happening at the side of W5100, but for this you will have to review the driving code.
For example, you read RX_RSR value in loop; while RX buffer is being filled, and if it is filled not with all 7 chars at a time, but char-by-char, at some point in time RX_RSR pointer can be less than 7. Thus in general in the W5100 state checking loop you must wait for required number of chars received (instead of just waiting for RX_RSR!=0) before you go to data acquisition phase"

The data is sent in a single packet and not one byte at a time. I have no idea how the data is received by the Wiznet W5100 chip. I use the RxDataAvailable macro to check whether data is there or not, exactly like in numerous Flowchart examples from Matrix, before trying to process anything. Is it remotely possible that the way the RXDataAvailable macro reports that data is in the Rx buffer can cause the "dropped bytes" problem?

Kind regards.
Leo

Hi,'

I have tried many different approaches to solving the data loss issue and found that a delay added in just before the RxDataAvailable macro (see flowchart) achieves this.

I have no idea how the macro works but it appears as if the W5100 rx buffer stops? receiving data when being accessed by the RxDataAvailable macro. The delay probably gives the buffer time to receive the whole data packet. I don't expect that this will solve the problem completely, but I have not had one error in more than a million data transfers running our Windows test app.

Unfortunately the solution mentioned above is not viable for my application as the delay introduced over time is unacceptable.
Regards.
Leo