Corrupt or incomplete UDP packets with W5500

Question

Hi there, I’m using an ESP32 with ESP-IDF and a W5500 module to receive ArtNet packets streamed over Ethernet. The SPI interface is running at 20Mhz and each of two sockets is set to 8K. While I’m able to get some packets, it seems the very frequently UDP packets are received incomplete or corrupt, which results in wrong values in the UDP packet header and the addressing to get our of sync with actual packet starts and ends. I’m quite to using the W5500 but tried to follow the datasheet and examples I saw in both the Arduino Ethernet library and your IoLibrary on GitHub. My reading code is quite simple and follows your example’s workflow for UDP: esp_err_t EthernetDriverClass::read(int socketIndex, uint16_t port, uint8_t* buffer, size_t length, size_t* received, in_addr_t* remoteIp) { if(this->sockets[socketIndex] == -1) { ESP_LOGE(ETH_TAG, "Attempted to read from closed socket"); return ESP_FAIL; } // take semaphore W5100.lock(); /* 1. Check available data */ uint16_t rd = getSnRX_RSR(socketIndex); if (rd > 0) { ESP_LOGI(ETH_TAG, "Available: %d", rd); } rd %= SSIZE; // // nothing to do, no new data if (rd == 0) { W5100.unlock(); return ESP_OK; } /* 2. Read packet header */ uint8_t header[8]; // read packet header from current RX address // read_data(socketIndex, state[socketIndex].address, (uint8_t*)&header, sizeof(header)); socketRead(socketIndex, (uint8_t*)&header, sizeof(header)); /* 3. Parse UDP packet header */ // get remote IP memcpy(&state[socketIndex].remoteIp, (uint8_t*)&header, 4); // parse UDP payload size uint16_t payloadSize = (header[6] << 8) + header[7]; /* 4. Read data */ // check for invalid packets if (payloadSize == 0 || payloadSize > SOCKET_MAX_PAYLOAD) { ESP_LOGI(ETH_TAG, "Invalid packet: %d, flushing", payloadSize); ESP_LOGI(ETH_TAG, "Payload: %d", payloadSize); // state[socketIndex].address += rd; payloadSize = 0; } else { // read_data(socketIndex, state[socketIndex].address + sizeof(header), buffer, payloadSize); socketRead(socketIndex, buffer, payloadSize); // state[socketIndex].address += sizeof(header) + payloadSize; } // write out data and remote IP *received = payloadSize; *remoteIp = state[socketIndex].remoteIp; /* Update RX address */ // apply mask // state[socketIndex].address = state[socketIndex].address & SMASK; // give semaphore W5100.unlock(); vTaskDelay(1); // If we get here, there's no data available or recv failed return ESP_OK; } with socketRead implemented as: void EthernetDriverClass::socketRead(int socketIndex, uint8_t* buffer, size_t length) { uint16_t ptr; ptr = W5100.readSnRX_RD(socketIndex); read_data(socketIndex, ptr, buffer, length); ESP_LOGI(ETH_TAG, "Reading: %d from %d", length, ptr); ptr += length; W5100.writeSnRX_RD(socketIndex, ptr); W5100.execCmdSn(socketIndex, Sock_RECV); } With this code however, after a short amount of time (and variable number of packets received) the data seems to get either corrupted or incomplete, and the UDP headers are wrongly parsed. Here is a log of a stream of…

barak · Answer

Running wireshark for a few minutes showed exactly the same packet size being send repeatedly: 217 0.267572 192.168.2.30 192.168.2.255 DMX Channels 572 ArtDMX (0x5000) length is always correct at 572 and it’s the only packet sent on this interface, which eliminates any extraneous reasons for data being off when parsed. Another look at the logs reveals a potential source for this issue, notice the changing numbers logged in available data, current RX pointer and parsed UDP packet size: I (12923) ETHERNET: Available: 6994 I (12924) ETHERNET: Reading: 8 from 416 I (12930) ETHERNET: Payload: 530 I (12933) ETHERNET: Reading: 530 from 424 I (12940) ETHERNET: Available: 6456 I (12941) ETHERNET: Reading: 8 from 954 I (12947) ETHERNET: Payload: 530 I (12950) ETHERNET: Reading: 530 from 962 I (12958) ETHERNET: Available: 416 I (12959) ETHERNET: Reading: 8 from 1492 I (12964) ETHERNET: Payload: 769 I (12967) ETHERNET: Reading: 769 from 1500 I (12975) ETHERNET: Available: 7831 I (12976) ETHERNET: Reading: 8 from 2269 I (12982) ETHERNET: Payload: 0 I (12986) ETHERNET: Available: 7823 I (12989) ETHERNET: Reading: 8 from 2277 I (12994) ETHERNET: Payload: 0 I (12999) ETHERNET: Available: 2313 I (13001) ETHERNET: Reading: 8 from 2285 I (13007) ETHERNET: Payload: 3601 I (13010) ETHERNET: Invalid packet: 3601, flushing The first few reads return available numbers that are all divisible by 538, and result in correct packet parsing - 8 bytes of header and a parsed payload size of 530. Packets are parsed one at a time so you’d expect numbers to increment slowly by 8 and 530 on the pointer, and decrease as slowly on the available side. However, timestamp 12958 reveals a wrong available data value returned, 416, despite the code correctly reading only 530 bytes in the line before, the available data dropped from 6456 to 416, and corrupted packets follow - payloads of 769, 0 3601, resulting in flush since it catches that the wrong value finally exceeds the max packet size. The available…