Socket sends garbage

TCP/IP Chip W5500
1

I run a simple http servver on ATMega using w5500, socket open, connect and receive work just fine, the problem is send. For example:

int32_t loopback_tcps(uint8_t sn, uint8_t* buf, uint16_t size) { int32_t ret = recv(sn,buf,size); if(ret < 0) { close(sn); return ret; } ret = send(sn,buf,ret); if(ret < 0) close(sn); return ret; }

Once called the above procedure should perform a loopback to the client. Unfortunatelly after recieve ( received data is fine ) it sends a random garbage string to the client… I’ve checked almost everything including the bytes being sent via spi and it all looks fine ( spi is transmiting proper data bytes to w5500 ) but still w5500 sends random binary data to the client…

It sometimes looks like it sends some random portion of socket buffer because sometimes I can see my data as a substring of that garbage response.

I’m using your official and unmodified driver software: wizwiki.net/wiki/doku.php?id=pro … 500:driver
Attached is transmition log from wireshark.

Please inform on whats wrong.
Thanks
wireshark.zip (4.05 KB)

2

Hi Think01,

We analyze the packet capture which is attacked pcapfiles.
No.16 packet is transmitted after receiving the No.12 packet.
But, No.16 packet is not same No.12 packet.

Please check below 2 points in your code.

  1. buf overflow: Please check the size of buf.
  2. start pointer of buf in send() : buf is transmitted from start pointer ‘0’ in send().

Thanks,

3

Well,
buf is 2048 bytes long and MCU seems to send a proper output buffer bytes in proper order and count via the spi interface to w5500 chip :confused:

I’m using ATMega mcu ( ATMega256rfr2 ) and for your reference I attach my c code.
Thanks a lot!
Slaw
main.c (2.82 KB)

4

I just noticed that this:

uint16_t ptr; socket(3,Sn_MR_TCP,80,SF_TCP_NODELAY); setSn_TX_WR(3,100); ptr = getSn_TX_WR(3);

just after wizchip_init or even this:

setSn_TX_WR(sn,0);

in wiz_send_data does literally nothing… ptr remains unchanged if thats any clue?

5

Well, I’ve tried everything I can think off with no luck… right buffer data leaves mcu spi but w5500 is still sending garbage to ethernet… it looks like data is being saved at wrong pointer in w5500 socket tx buffer or w5500 sends wrong portion of socket tx buffer to ethernet

I guess the wiz550io module I have is broken or your ioLibrary_BSD has a bug somewhere but it is ofcourse also possible I’m making some general mistake somewhere but I’ve ran out of ideas so please verify - my full code is attached.

What I use is:

  • wiz550io module
  • ATMega256RFR2 Xplained PRO board ( which is an oridinary atmega chip in means of spi communication )
  • Atmel Software Framework
  • Atmel Studio 6.1
  • ioLibrary_BSD downloaded from wizwiki.net/wiki/doku.php?id=pro … 500:driver

Also, can you advice on some basic test routines 100% verifying that:

  • my spi configuration is fine or not ( I can set mac, ip, read it back, read device id etc. )
  • my wiz550io module is fine or not ( I can recieve properly )

Thanks in advance!
Slaw
src.zip (120 KB)

6

That at least seems normal. In my experience, after being written to TX_WR is going to be returned as modified only after the SEND command is executed.

Kind regards, Sebastian

7

so if I run below code at any monemt tmp will allways remain 0 right?

ptr_w = getSn_TX_WR(sn); ptr_r = getSn_TX_RD(sn); tmp = ptr_w - ptr_r;

anyways by modifying my loopback_tcps function as follows:

int32_t loopback_tcps(uint8_t sn) { uint8_t i; int32_t ret = recv(sn,socket_buffer,DATA_BUF_SIZE); if(ret < 0) // <- I can allways see properly received data in buf[] here { gpio_set_pin_low(LED0_GPIO); close(sn); return ret; } uint16_t j = 0; for(j = 0; j < DATA_BUF_SIZE; j++, 1) socket_buffer2[j] = 42; for(j = 0; j < 10; j++, 1) socket_buffer2[j] = 48+j; ret = send(sn,&socket_buffer2[0],DATA_BUF_SIZE); if(ret < 0) { gpio_set_pin_low(LED0_GPIO); close(sn); } return ret; }

and doing multiple http requests on that socket I get responses like:

****************************************************************************************************************************************************************************************************************************************************************0123456789******************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
0123456789**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************0123456789**************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************

etc. which ( because data transmitted over SPI is allways starting with 0123456789******* ) means that something is wrong with Sn_TX_WR or Sn_TX_RD, the question is what for gods sake…

help wiznet guys, help! :slight_smile:

BTW Sn_TX_WR seems to increment properly for example 0x239F after first connect and before send, 0x23BF after sending 32 bytes, then 0xD3DF after second connect and 0xD3FF after sending another 32 bytes and so on. The only strange thing is why Sn_TX_WR is not 0x0000 after first conntect following hw reset but this might be normal also…

8

ok, I think I found your bug… its in w5500.c in function wiz_send_data ( and propably wiz_recv_data too )

you declare:

uint16_t ptr = 0;

which looks fine as getSn_TX_WR is 16-bit value but later on you do:

addrsel = (ptr << 8) + (WIZCHIP_TXBUF_BLOCK(sn) << 3);

so with (ptr << 8) you basically shift a word by 8-bits left resulting 0x1234 << 8 = 0x3400 so by this you loose a most significabt byte!

in order to fix that you just need to declare

uint32_t ptr = 0;

and thats it…

I wonder if there are more fruits like this in your code :confused:

9

Hi,
W5500 references codes are based on 32bit MCU as ARM.
The smaller bits MCU user often did mistake to porting the codes into user system.

We will update the code with explict type declaration & casting in near future.

Thank you.

10

Well, if your official driver is for a specific mcu you should propably state this literally in your manual… I lost a bunch of time thrusting the code I believed is well tested, bug free and platform independent ansi c code…

Also the bug I pointed out is not target mcu issu but an ansi c bug. According to language specification if you put an expression into cupbounds its being evaluated first using an allocation unit specific for cupbounded expression. So even so it may work for 32 bit arm its not proper syntax and c campiler can but does not have to evaluate this expression using 32bit lgics ( because your code ALLOWS compiler to optimise to 16 bit value ).

11

Thank for your serious advices.
If you have some idea, suggestions and special modification part, feel free tell to me.

Thank so much again.

12

Thank you Think01!!! I had experienced the same problem using an Atmel XMEGA part (XMEGA-A1 Xplained evaluation board). After confirming my data was being sent to the W5500 correctly, I started searching this forum and ran across your post. Your fix quickly resolved my problem and saved me a significant amount of development time. Thanks again!

WIZnet, I’m using the latest version (v1.0.2) of the Ethernet libraries. It appears as though it’s a simple fix for you to 1.) update the library, or 2.) put a note on your wiki stating that there is a known problem with this function. Issues like this costs us a significant amount of development time. Bugs exists – that’s understandable; however, it’s difficult to understand why we have to rediscover known issues.

13

Hi, Think01 and bobh.

We are fixed the problem and update the driver on [url]http://www.wizwiki.net/wiki/doku.php?id=products:w5500:driver[/url].

Thank again for your serious advice & interest.