-
If I do not need the data in the receive buffer in UDP mode, can I just set Sn_CR to RECV without reading from RX_FIFOR? Is it necessary to copy data even if I do not need the data? Currently we are reading the data from RX_FIFOR - since there was some suggestion from some site that this is necessary to clear the buffer to make way for new data - and then setting RECV, but it is not required to read the data, is it not? When we set RECV, next data will simply overwrite the previous data, right?
-
If a wiznet UDP socket port is being bombarded with continuous data (may be junk / broadcast ), how does this affect the chip? Will it cause speed issues with other sockets? Can it cause the chip to reply to pings only once, or not reply at all? Can it cause the chip not to reply to arps?
-
What is the best way to deal with unwanted data sent to wiznet udp port? Can we check the source port and then simply set RECV and exit?
Hi,
[quote]1. If I do not need the data in the receive buffer in UDP mode, can I just set Sn_CR to RECV without reading from RX_FIFOR? Is it necessary to copy data even if I do not need the data? Currently we are reading the data from RX_FIFOR - since there was some suggestion from some site that this is necessary to clear the buffer to make way for new data - and then setting RECV, but it is not required to read the data, is it not? When we set RECV, next data will simply overwrite the previous data, right?
[/quote]
Unfortunately, W5300 FIFO register can not be flushed. So, You should read the data even if you don’t want it.
If there is only unwanted data in socket buffer, you can flush the buffer using close and reopen the socket.
But, If there is both unwanted data and wanted data in socket buffer, you should read FIFOR for ingnoring the unwanted data.
[quote]2. If a wiznet UDP socket port is being bombarded with continuous data (may be junk / broadcast ), how does this affect the chip? Will it cause speed issues with other sockets? Can it cause the chip to reply to pings only once, or not reply at all? Can it cause the chip not to reply to arps?
[/quote]
When being bombarded with junk, W5300 just receives the data as many as socket buffer size and the rest bombarded data is discarded until the socket buffer is free.
It maybe cause speed issues with other sockets because the continous bombarded data should be also read for determining it to need.
W5300 have the hardwired ping-reply logic. When W5300 have received the ping-request despite the network traffic, W5300 can ping-reply about the request. But, the ping-reply is likely to loss by network traffic. Therefore, ping-loss caused by network traffice, not W5300.
[quote]3. What is the best way to deal with unwanted data sent to wiznet udp port? Can we check the source port and then simply set RECV and exit?
[/quote]
For determining the data to need, you can read the packet information of data. Although if it don’t need, you should be read FIFOR.
Thank you.
Just a stupid question. A confusing piece of code. Data length appears after 14 bytes (6 times read of *S5_RX_FIFOR0, and 1. Wiznet is directly memory mapped. Definitions are shown at the top of the code.
uint8 xdata *S5_IR1 = (uint8 xdata *)0x2347;
uint8 xdata *S5_SSR1 = (uint8 xdata *)0x2349;
uint8 xdata *S5_RX_RSR3 = (uint8 xdata *)0x236B;
uint8 xdata *S5_RX_FIFOR0 = (uint8 xdata *)0x2370;
uint8 xdata *S5_RX_FIFOR1 = (uint8 xdata *)0x2371;
uint8 head0;
uint8 head1;
uint8 udpsizelsb;
if(*S5_SSR1 == 0X22) // check if the socket is in udp mode
{
/// get the length of the recv packet, LSB will indicate a minimum length. assuming it won’t be zero.
udpsizelsb = *S5_RX_RSR3;
if(*S5_IR1 & 0X04 || udpsizelsb > 0x08) // if minimum 8 bytes are recvd or if interrupt is set
{
*S5_IR1 = 0X04; // clear the recv interrupt bit of socket
head0 = *S5_RX_FIFOR0; // read 2 bytes from wiznet recv memory and throw it. Need only data size.
head1 = *S5_RX_FIFOR1;
head0 = *S5_RX_FIFOR0; // read 2 more bytes from wiznet recv memory
head1 = *S5_RX_FIFOR1;
head0 = *S5_RX_FIFOR0; // read 2 more bytes from wiznet recv memory
head1 = *S5_RX_FIFOR1;
//completed - totally 6 bytes - next 2 bytes must be data size !!
head0 = *S5_RX_FIFOR0; // read 2 more bytes from wiznet recv memory
head1 = *S5_RX_FIFOR1;
//totally 8 bytes
head0 = *S5_RX_FIFOR0; // read 2 more bytes from wiznet recv memory
head1 = *S5_RX_FIFOR1;
head0 = *S5_RX_FIFOR0; // read 2 more bytes from wiznet recv memory - 13/14 bytes
head1 = *S5_RX_FIFOR1;
//totally 14 bytes
// now, next 2 bytes indicate datalength. Actually, it should have been the last 2 bytes of the header (7 and 8), and not 15 and 16. But some how, 15/16 matches datalength. From 17nth onwards, it is data.
datalength = *S5_RX_FIFOR0; // read the datasize now, from 15/16 bytes
datalength =(maclength << 8);
datalength = datalength + *S5_RX_FIFOR1;
for(index = 0 ; index < datalength; index++) // copy the data contents of recv memory of he socket to user memory. variables are defined elsewhere.
{
mydata[index] = *S5_RX_FIFOR0;
index++;
mydata[index] = *S5_RX_FIFOR1;
}
Now, mydata has UDP data. Actually, I am reading from 17, 18 … of the buffer, instead of 9,10… So my data has to be incorrect, but it seems to be correct. Is this some datatype conversion issue?
Please comment. Code seems to be right, but something is wrong. (In the actual code, we are using a header array as per the sample code.). Code gives correct receive size o 15/16 reads. Some stupid interpretation, but if you can comment on this, we would appreciate it.
Hi,
Did you check the first 4 bytes to valid ip address and next 2 byte check to valid port number?
If the ip & port number is invalid, it seems to be likely to access incorrect Sn_RX_FIFOR.
Let me know the result of test the first 4 & next 2 bytes.
Thank you.
