Go Down

Topic: Ethernet module freezing (Read 2528 times) previous topic - next topic


I'm using a wiz811mj ethernet module (basically the same functionality as the ethernet shield) and the  UDPsendReceiveString sketch that comes with the ethernet library, with an Arduino uno.

I'm sending this a stream of packets 530 bytes long.

A correct report looks like this -
Received packet of size 530
From, port 6454

At higher speeds (40-60 pps) the reported size quickly rises like so -
Received packet of size 12128
From, port 0

Until the device freezes (within seconds usually)

At lower speeds (like 20 pps) the errors will be fewer but still present, and the device will still crash, though less frequently.

All I need is to read and parse one current packet (ideally the most recent, though not essential), ignore any that the arduino does not have time to deal with, then read and parse the next (most recent) packet when the arduino is ready (ie main loop cycles round)

I don't know if it's the w5100 buffer that is filling up and freezing, or the arduino memory.

It is not always possible for me to control the speed of (duration between) the incoming packets, so the system must be able to ignore packets it can't process in time.

I've tried calling EthernetUdp.flush() at the end of every loop, which I presumed would clear the w5100 buffer after the packet had been read but the only effect is to make crashes much more frequent.

Would an arduino mega help? or an ethernet controller based on the w5200 for example?  It'd be nice not to have to spend more money but I'm happy to if it works.

Any ideas?



Try disabling the SD SPI interface if you have not done that in your setup routine. It messed up my NTP routine, which also uses UDP.

Code: [Select]


Thanks for the tip.

Tried it but it hasn't helped my issue


I use the wiz811mj and was having trouble with it freezing; but not as frequently as you.

I put in the fixes to the library as described below and all's good:



Hope this helps.


Didn't help sadly.

What behaviour should I be expecting here?

I'm sending packets 530 bytes in size, about 40 packets per second, with the following code -

Code: [Select]

#include <SPI.h>         // needed for Arduino versions later than 0018
#include <Ethernet.h>
#include <EthernetUdp.h>         // UDP library from: bjoern@cs.stanford.edu 12/30/2008

// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = { 
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(2, 0, 0, 101);

unsigned int localPort = 6454;      // local port to listen on

// buffers for receiving and sending data
char packetBuffer[1024]; //buffer to hold incoming packet,
char  ReplyBuffer[] = "acknowledged";       // a string to send back

// An EthernetUDP instance to let us send and receive packets over UDP
EthernetUDP Udp;

void setup() {
  // start the Ethernet and UDP:


void loop() {
  // if there's data available, read a packet
  int packetSize = Udp.parsePacket();
    Serial.print("Received packet of size ");
    Serial.print("From ");
    IPAddress remote = Udp.remoteIP();
    for (int i =0; i < 4; i++)
      Serial.print(remote[i], DEC);
      if (i < 3)
    Serial.print(", port ");

    // read the packet into packetBufffer

    // send a reply, to the IP address and port that sent us the packet we received
    Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());

The correct response is (with my packets)-
Received packet of size 530
From, port 6454

Wheras most of the responses end up being something like-
Received packet of size 702
From, port 0

Received packet of size 20012
From, port 2

And often the packet size value will rise to  just under 32000 before crashing.

I've tried flushing the buffer after each read with EthernetUdp.flush() which in theory would fix my problem (I don't care about lost packets).  But it just seems to make the crashes more frequent



Test out your setup by trying the Webserver and Webclient examples. This is a simpler setup that doesn't use UDP or processing but you can switch back later if you don't like TCP. Its just a matter of fault finding at this stage and determining if your module is working, correctly wired, etc.

Go Up