here the 5’th byte sent was 7B instead of 5B ( one bit difference)
This one bit error is random and can be anywhere in the packet.
Any idea how to debug or resolve this?
(I tried to use Wireshark, but could not set it correctly to hunt just these messages, where can I find simple instuction for doing that?)
Thanks
There’s data checksum within IP packet, and if it is corrupt it must not appear in the RX buffer and chip sends retransmission of request or just discards the packet (depending on mode). I suspect you have issue reading data from the buffer. If error occurs, perform the test - read data from RX buffer several times and see if there will be the same issue in the same location all the times.
I am aware that tcp has internal checksum. This is why I am so confused.
The client is the W5100S chip, sending a packet to AMZON AWS server (which I need to assume working OK).
So I send this packet from W5100S to AWS server. The server gets a bad packet as I add my own CRC to it, I also print it on the server and can actually see that one bit changed randomly.
I tried to reduce SPI speed to minimum, and still the same issue. Its like the send() is putting wrong data in the buffer of the chip. Can’t figure this out.
Thanks
Really wireshark is your friend. You must run it on the computer in between of W5100s and the server (e.g. in network bridge mode) so that you can capture all the packets going through and see the data.
You need either dual interface in bridge mode (can be any interface by the way - e.g. one wired and another WiFi - whatever is convenient), or somehow set up router to duplicate all the traffic from the port of interest (depends on router/switch and its configuration).
Before I connect a PC with Wireshark, I wrote a simple TCP server that just reads tcp on my local PC, and changed the W5100S software to just send these packets. My local serve counts all good and bad packets, the ratio is about 2 bad in 1000.
There is no remote servers, no threads in embedded device, just sending tons of packages with CRC check. and I get 2%% errors.
Is there a simple way to read the txBufeer on the chip, just before it is sent? I want to verify that data written in the buffer is correct before it is sent, if I find errors, then I can look into my SPI interface (even though it looks very OK).
And it is always one bit send as 1 when it should be 0.
The W5100S is assembled on my own PCB module, I tested 3 different modules, it is the same.
Its either some hardware issue in my board (I will run a few tests for voltage a pulse shapes), or a real problem with the W5100S chip.
As I am using only one socket, I set it to use the full 8K txbuffer:
WIZCHIP_WRITE(TMSR, 3);
WIZCHIP_WRITE(Sn_TXBUF_SIZE(0), 8);
When I comment these lines and keep it as the 2K default, the problem is gone.
Tested with 1 million packets, not even one bit wrong if txBuffer is 2K.
Then I tested with 4K:
WIZCHIP_WRITE(TMSR, 2);
WIZCHIP_WRITE(Sn_TXBUF_SIZE(0), 4);
Its working OK too.
So it is just with setting of 8K Tx buffer that this problem exists.
I wonder if using 8K for the TX buffer is not commanded, is there a problem in the chip? the API library?
I can leave with this 4K buffer, but using 8K makes the connection faster, an I would like to know what is the problem.
Thanks
If you can’t show between W5100S and Server the packet through wireshark, it may take a long time to solve the problem.
I think you have to confirm the sending data in tx buffer of W5100S.
So, you send the 8Kbytes data through SPI and you read the TX buffer of 8Kbyte size before sending process execute.
If you use the standard Wiznet Library, you can read the TX buffer data in wiz_send_data() function.
Do we understand you properly that wireshark showed that packets contain wrong data (concluding that W5100s releases wring data into the wire)?
I do not think it is possible to read TX buffer back using this call. Head file says
* @ingroup Basic_IO_function_W5100
* @brief It copies data to internal TX memory
*
* @details This function reads the Tx write pointer register and after that,
* it copies the <i>wizdata(pointer buffer)</i> of the length of <i>len(variable)</i> bytes to internal TX memory
* and updates the Tx write pointer register.
* This function is being called by send() and sendto() function also.
*
* @param sn Socket number. It should be <b>0 ~ @ref \_WIZCHIP_SOCK_NUM_</b>.
* @param wizdata Pointer buffer to write data
* @param len Data length
* @sa wiz_recv_data()
It seems @johanan will have to write his own call which fills the buffer, reads the buffer, compares data, and only then operates pointers and perform SEND.
@johanan I think it is time to think about looking at the SPI transactions, if you have logic analyser or scope please take some pictures of the SPI bus activity.
I did not use WireShark. Whoever, I wrote a simple TCP lisnere server to run on my PC, on the local network. This server got the packets from the W5100S.
I configured the embedded system with W5100S to send small packets of abut 40 bytes with CRC test, all packets are identical, same data and same CRC. The server counted all OK and all bad packets, each bad packet is printed on the consul.
Now I let this setup run, and found about 2%% bad packets, since all packets are same, it was easy to find that one random bit 1 instead of 0,
Then the only change I made is setting the TXbuf size to 2K and 4K. After that I transmitted millions of packets with no error at all.
So there is only one conclusion, its a bug in the chip (or in the API IO lib), it is not reliable to use 8K buffer for socket with the W5100S.
I think my test is very conclusive, whoever, I will look at the signals with an oscilloscope, may be I will see something (The first thing I did in this bug digging was to reduce SPI clock to a very low rate, just to make sure no pulse is distorted, but that did not change anything)
Well then. If it is an spi issue then how it is working ok with 4k, 2K and 1K buffer settings?I will send schematics to you next week as I will be out of office until Monday.
Regards.
