I am designing an LED Lighting product using W5500 to receive Art-Net. (Art-Net is a UDP protocol with packets of 534 bytes). The controller is ESP32. I am using the interrupt pin of the W5500 to trigger reading of packets.
Everything works fine until we send a large number of Art-Net packets together (e.g. a burst of 24 packets), then W5500 stops receiving the UDP data after a short length of time (30sec - 2 minutes). The interrupt pin stops triggering. W5500 can still be read but reports no data has been received. I’m running the SPI bus at 32MHz. I have the W5500 set to one single socket with a buffer size of 16KB. If I read back the configuration registers of W5500 everything still seems to be set correctly.
The only way to restore operation is to reset the W5500, then it will work correctly again for a short time.
ESP32 is using Arduino framework with the standard ethernet library. I’m not sure how to debug this further as the problem seems to be inside the W5500.
I have made a little progress with this issue. It seems to relate to UDP data arriving faster than it is being read by the MCU. I would expect the W5500 to drop packets if there is not enough buffer space, but in fact it appears to stop receiving data altogether.
Could Wiznet please advise what should happen if more packets are received than available buffer space?
If I place the UDP reading code inside the interrupt routine, and stay in the interrupt routine until all packets have been read, then the W5500 will successfully receive 32 consecutive packets of 572 bytes. However this causes other problems with watchdog resets in the ESP32 as other tasks are starved of time.
If I play nice with the rtos and put the UDP reading code in its own high priority task and use a semaphore from the interrupt routine to release the task, then the W5500 locks up in less than a minute.
According to your description of your architecture: interrupt pin will activate when data is received if you programmed its mechanism properly. In ISR you must read all the data received to date, not only one packet of data. And the gray area is if data will arrive just before or during you clearing interrupt flag - you risk to clear new interrupt request. To prevent it, in the ISR, first clear interrupt flag in W5500, then process data, then exit ISR. If there will be new request coming during ISR processing data, it will be brought in again.
Hi, thanks for reply, I am reading all data that has been received. If I stay in ISR until all data is read, this can cause watchdog reset or idle task reset on ESP32, so I was attempting to trigger a high priority task to read the data, using a semaphore from the ISR. However this causes a delay in reading the data and this delay causes the W5500 to stop receiving further UDP data.
In the case of data arriving during interrupt flag being cleared, I expected that the W5500 should still show that some data is waiting to be read from the buffer if it is polled afterwards.
The strange thing is that W5500 says no data is in the buffer, and does not receive any more UDP packets from the network until it is reset. If the W5500 internal buffer fills, could that cause it to stop receiving UDP and return a data count of 0?
