Issue with Ethernet/lwIP: Packet Loss and Reordered Pings After Data Bursts [LPC54S018]

[Bartosz_Z]

Hello,

I am using the lwip_ping_freertos example from the NXP SDK with the ping logic removed, keeping only the stack setup. Instead, I added an empty FreeRTOS task with the lowest priority (which only prints heartbeat log every second. The application works correctly under normal conditions, allowing me to successfully ping the board.

However, when a burst of UDP data is sent to the board, ICMP ping responses begin to experience packet loss or reordering. This behavior persists even after the burst has ended and does not recover until the board is reset. During the UDP burst with lwIP logs enabled, the system prints few "ethernetif_linkinput: RxFrameError" errors. The problem seems to manifest only when any other frfeeRTOS task (e.g., the one I added) is present. Without it, the issue does not occur.

Additionally, when a TCP handler is added to the application, similar issues are observed with TCP communication, including significant packet reordering and retransmissions.

The UDP burst is generated using a custom Python script, with the problem typically occurring after approximately 1000 packets have been sent. While some level of issues during high load is acceptable, I would like the system to recover and resume proper operation once the burst is completed.

I attached Wireshark logs.

[Pablo_Ramos]

Hi @Bartosz_Z,

Could you help me with the following question?

The number of packages sent before the error varies when adding an empty FreeRTOS task or a TCP handler?

At what speed do the packages are being sent?

Could you share with me the modifications that you made on the example?

Could you explain furthermore what you mean with empty FreeRTOS task?

Could you help me by adding a blinky led to the code? This in order to see if before the UDP burst FreeRTOS and the MCU is still working correctly

Thanks in advance.

[Bartosz_Z]

1) Yes, the number of packets sent before the error occurs does vary depending on whether an empty FreeRTOS task or a TCP handler is added. Without any tasks, application works correctly, with just the empty task, the issue manifests after approximately 1000 packets. With a TCP handler and business logic enabled, the error seems to occur even sooner (~50-100 packets). My main issue is after initial burst this issue persist until reboot.

2) The UDP burst is being generated using a Python script, sending packets without any timeouts. I attached Python script.

3,4) I started with the lwip_ping_freertos example from the NXP SDK.

I've changed ping_thread logic to simple, printing one.

-- sys_thread_new("ping_thread", ping_thread, NULL, DEFAULT_THREAD_STACKSIZE, 1);
++ sys_thread_new("ping_thread", simple_thread, NULL, DEFAULT_THREAD_STACKSIZE, 1);

Added a minimal FreeRTOS task with the lowest priority. This task logs a "heartbeat" message once per second. By "empty FreeRTOS task," I mean a task with minimal functionality. I see similar behaviour using my custom board with business logic implemented.

static void simple_thread(void *arg)
{
 while (1) {
   PRINTF("Heartbeat\n");
   vTaskDelay(1000);
}

5) I can observe board is operational, can trigger breakpoints and can observe heartbeats printed properly.