LARGE UDP Reception delays!!!

[uTasker]

Hi

We have designed an ESP32C3 into a motion control device but have a BIG problem with delays when receiving UDP frames.

There is a UDP frame received every 50ms consisting of 1024 bytes of data which then controls a motion output. Jitter in the UDP reception of 10s of ms is acceptable but sometimes we get delays of over 300ms!!!!!

We are using the ESP32C3 with the latest ESP-AT release binary and have one UDP socket listening and the UART speed is set to about 450kBaud. Each UDP reception takes about 23ms to be received on the UART, which represents about 50% of the time RXD being used. At the end of each data reception we toggle an LED and therefore, when everything is operating smoothly, this LED toggles consistently once ever 50ms as seen in the recording 1.

Recording1.JPG (39.69 KiB) Viewed 188 times

There is never TXD activity so nothing is ever commanded during the operation.

Much of the time this works fine and everything operates correctly. However every now and then there is a freeze in the output due to the fact that the ESP32C3 doesn't send received UDP data out for a long time (more that 300ms delays are quite common).

Recording 2 shows such a case.

Recording2.JPG (80.33 KiB) Viewed 188 times

Here it is seen that there is a pause and following this pause queued UDP reception is send out until it recovers back to its 50ms rhythm.

The UDP frames are numbered and so we can see that none are lost, but they are delayed and queued until it recovers.
We monitor the WIFI from the PC sending the motion control data and can see the same UDP frames being sent at the expected 50ms rate, showing that the delays in the overall system are inside the ESP32C3 itself. Using the same data send from the PC with a competitor's solution doesn't show any such issues.

Obviously with such delays it is impossible to use the ESP32C3 for motion control as when this takes place it results in serious output errors.

How can these sporadic delays (typically every 20 .. 50s) be explained?
- is it a bug (eg. a task being blocked unintentionally so that the data is received but not sent out)? If so, how can a fix be made?
- is it due to another function inside the ESP32C3 that is executed occasionally with a higher priority that intentionally blocks the UDP to UART operation during that time? If so, is there a way to disable this (through AT command commands)?

Please note that this is a very serious issue as customer trials need to start shortly and at the present these will fail with the experienced behavior. A solution needs to be found to solve the issue as soon as possible.

Thanks in advance.

Regards

Mark