2024-10-08 09:09 PM
Hi.
In my system, the opposing device sends TCP data at 20ms intervals,
and the microcontroller receives the TCP data non-blocking at 20ms intervals.
Therefore, the ethernetif_input() function of LWIP is supposedto be called at 20ms intervals and store data in the receive buffer.
However, as the operation continues, the calls to ethernetif_input() gradually delay by 1ms, 2ms, and so on.
(After 18 minutes, the calls are delayed by 10ms.)
As a result, there are moments when the receive buffer is empty, causing failures in receiving data at 20ms intervals.
I tried the following, but the call to ethernetif_input() is still gradually delayed:
・Changing the data transmission interval of the counterpart device (20ms → 10ms or 100ms)
・Adjusting the CPU clock (168MHz → 216MHz)
・Changing ETH_RX_DESC_CNT (4 → 8)
・Changing INTERFACE_THREAD_STACK_SIZE (350 → 500)
・Changing TCPIP_MBOX_SIZE (6 → 1000)
・Changing DEFAULT_TCP_RECVMBOX_SIZE (6 → 1000)
How can the microcontroller successfully receive TCP data in every cycle?
Test environment:
Microcontroller : STM32 NUCLEO-F767ZI
Counterpart device : Ubuntu 22.04, ROS2 (C++)
STM32Cube IDE : 1.15.0
STM32 Firmware : STM32_Cube FW_F7 V1.17.1
STM32Cube MX : 6.11.0
LWIP : v2.1.2_Cube
Best regards.
2024-10-08 09:23 PM
If the receiving side is setting a 20ms delay for next reception, that might be the cause. Since the reception routine takes some time to process.
2024-10-08 10:40 PM
Hi, @rakib2023
Thanks for your reply.
Since the process is implemented with a 20ms cycle using osDelayUntil(),
I believe it is not a problem if the reception process takes a little time.
If you have any other ideas, I would appreciate it if you could let me know.
Regards,
delta_s
2024-10-10 09:35 PM
Here is the additional information.
In my system, in addition to TCP communication (The counterpart device → The microcontroller),
UDP transmission (The microcontroller → The counterpart device) is also performed at a 20ms cycle.
By obtaining the tcpdump of the counterpart device, I found the following:
・The timestamp of the TCP packet transmission is almost maintaining a 20ms cycle.
・The timestamp of the UDP packet reception is gradually getting faster by 1ms, 2ms, and so on.
(in contrast to the delay in the call of ethernetif_input()).
From these observations, I suspect that 20ms for the microcontroller is shorter than 20ms for the counterpart device.
Based on the above, we would appreciate it if you could share any ideas to ensure successful TCP data reception in each cycle.