Socket sends garbage

Question

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)

suhwan · Answer

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. buf overflow: Please check the size of buf. start pointer of buf in send() : buf is transmitted from start pointer ‘0’ in send(). Thanks,

Think01 · Answer

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 I’m using ATMega mcu ( ATMega256rfr2 ) and for your reference I attach my c code. Thanks a lot! Slaw main.c (2.82 KB)

Think01 · Answer

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?

Think01 · Answer

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)

wangnick · Answer

Think01: in wiz_send_data does literally nothing… ptr remains unchanged if thats any clue? 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

Think01 · Answer

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*************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************…

Think01 · Answer

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

Think01 · Answer

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 ).

bobh · Answer

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.