No UDP packets transmitted after ARP reply

[Armageddon]

Hello,

I'm using the STM32F767ZITx MCU and the lwIP library to transmit and receive UDP packets every 1 ms.

Everything works fine but sometimes, after the ARP table has expired, UDP packets are no longer transmitted for several seconds even though my STM has received a response to its ARP request (as seen with Wireshark).

What solutions are there to avoid this scenario? Is this normal lwIP behavior?

Thanks for your help.

 

[Andrew Neil]

Have you enabled LwIP diagnostics, and/or added your own diagnostics, to see what's going on - in particular, what changes when this problem occurs?

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-activate-debug-messages-for-lwip/m-p/234163/highlight/true#M15389

 

[Armageddon]

 

With my current system, I don't have a UART link available, I'm not on a proto board but a custom one.

What I'm seeing is that when I stop sending frames, the ARP table is empty, even though I'm receiving replies to ARP requests. It's as if it doesn't process replies.

 

 

[Andrew Neil]

---

@Armageddon wrote:

With my current system, I don't have a UART link available

---

That's a major oversight!

Can you use SWO instead?

Can you reproduce the problem on a board which does have suitable access?

[Armageddon]

You don't have all the ins and outs to tell me it's an oversight.
We have our constraints, and that's the way it's done. It would have been simpler to have it, but I'll do it with the classic probe debugging.

If I really can't do it, I'll consider moving my program to a proto to find a solution more easily.

I may have an idea, given that the system keeps receiving frames every 5ms, maybe the input buffers are saturated.

Thanks for your feedback, I'll keep you posted.

 

[STea]

Hello @Armageddon 

you could visualize throw the SWD if you have STlink available throw the SWV(serial wire viewer) console print if you can use UART to redirect the print logs of LWIP this is documented in the following article Using the ITM console for printf redirects and LWI... - STMicroelectronics Community  now regarding this statement:

 "given that the system keeps receiving frames every 5ms, maybe the input buffers are saturated."

if it were to be saturated by receiving frames every 5ms why it didn't saturate before the ARP event happened, I don't think this is the case.
Regards

[Armageddon]

 

Thanks for your feedback, I'll follow your link to learn more and use it.

I'm about to do the test on a NUCLEO board after all, as I think I'm starting to point the problem and I'd like to see if I get the same behavior on the latter.

 

If I've understood correctly, the “MX_LWIP_Process” function ends up calling “HAL_ETH_ReadData”, which returns whether packets are ready to be read or not.

However, during the time when I'm no longer sending UDP frames because the ARP table is empty, this HAL_ETH_ReadData function returns “HAL_ERROR”, whereas with Wireshark, I'm seeing responses to ARP requests (I'm using a switch with a mirrored port).

I don't know why, but I'll try the test on a NUCLEO before going any further.

[Armageddon]

Hello, I'm coming back to you with more information about the problem.

As a reminder, my problem is that sometimes the ARP table expires and it can take several seconds before it is updated again.

I tested my software on the NUCLEO-F767ZI, and didn't encounter any problems. Note that the NUCLEO has a LAN8742A.

Back on my system, which uses a DP83848YB, I purified the communication so as to have only ARP frames (no more UDP frames in reception).
To do this, I set the ARP_MAXAGE constant to 31, so that my system would send an ARP request every second.

I also modified the “HAL_ETH_ReadData” function to change the state of a GPIO depending on whether a packet is to be read or not. Here's my modification:

 if (rxdataready == 1U)
 {
 /* Return received packet */
 *pAppBuff = heth->RxDescList.pRxStart;
 /* Reset first element */
 heth->RxDescList.pRxStart = NULL;
 HAL_GPIO_WritePin(GPIOD, TEST_1_Pin,GPIO_PIN_RESET); // <-- HERE
 return HAL_OK;
 }

 HAL_GPIO_WritePin(GPIOD, TEST_1_Pin,GPIO_PIN_SET); // <-- HERE
 /* Packet not ready */
 return HAL_ERROR;

 

Finally, I monitored the GPIO, the RXD0 signal from the PHY driver, and the call frequency of the “MX_LWIP_Process” function on an oscilloscope.

 

Here's the result:

• On my RXD0, I observe every 2 seconds (sometimes 1s) the response to the ARP packet requested by my system. Note that on the NUCLEO, it was stable every 1 second.
  I monitored in parallel with Wireshark on a mirror port of my switch and the reception frequency on RXD0 was consistent with what I observed on Wireshark.
  I conclude that I'm receiving all the driver's frames.
   .
• On my GPIO, I can see that my ARP table is always updated when my GPIO switches to the low state (frame received).
  I can see that, despite ARP packets being received every second, the function only occasionally returns a packet that has been received.
   .
• MX_LWIP_Process is called each 1ms.

 

 

So I think, there are packets arriving at the MCU at a targeted frequency but the HAL library doesn't return that a packet is available.

I haven't checked the UDP packets, but I suspect I'm having the same problem with UDP packets received but over a shorter period of time (or on fewer packets).

I hope I've made a complete return that might allow you to help me. Is this a consequence of something else I haven't checked, or is there a problem with the library?

Thanks in advance for your help.

 

 

 

[STea]

Hello @Armageddon ,

Thank you for your explanation. I get that on your hardware you are using DP83848YB as a PHY and the Nucleo board uses the LAN8742 so I'm a little bit confused as to how you did test the same code on you Nucleo board and your own PCB?

the only thing that might get you this kind of behavior is the only thing that changed between you proper design and Nucleo design is the PHY.

is your firmware adapted for the LAN8742 PHY or DP83848YB ?

you can have same reference implementations of DP83848YB with our Eval board maybe test it on your PCB and tell us what you get.
see reference example in STM32Cube_FW_F7_V1.17.2/Projects/STM32F769I_EVAL/Applications/LwIP/LwIP_HTTP_Server_Raw

available also on GitHub .

Regards

[Armageddon]

Hello @STea,

Thank you for your help, I didn't say sorry, but of course I made the necessary changes. To use LAN8742, there is a ‘Platform Settings’ tab in the lwIP configuration tool on STM32CubeIDE.
On my board I've set it to DP83848 and for the NUCLEO to LAN8742.

So I would say that my firmware is adapted to DP83848YB PHY.

Regards,

[Armageddon]

I was able to solve the problem.
Although I don't have a powerful enough tool to see the problem, I think that the ETH_REF_CLOCK signal (RMI only) used as a reference clock at 50MHz was not clean enough.

The clock was indeed at 50MHz but with another signal on it probably, because after a little filtering my problems disappeared.

Sorry to have involved you, thank you for your time.