Skip to main content
Engineer0815
Associate
August 20, 2026
Solved

STM32H563 Ethernet: TX Buffer fills up and drops initial UDP packets on startup

  • August 20, 2026
  • 2 replies
  • 85 views

Hello everyone,

I am currently evaluating the STM32H563 (using the NUCLEO-H563ZI board) with an application that sends a continuous UDP packet stream via 100 Mbps Ethernet.

I've noticed that right after startup (or after flashing the board), the MAC drops a number of packets. Upon closer analysis, the MAC's TX buffer fills up completely, causing all subsequent packets to be dropped. After about 1 second, the MAC seems to stabilize, adjusts to the continuous packet flow, and begins sending all packets without loss.

My questions:

  1. Why does this behavior occur?

  2. My suspicion is that the MAC might be operating in a low-power or standby mode initially, and takes a moment to ramp up to a continuous flow. Is this assumption correct?

  3. Is there a way to configure the MAC so that it operates at full speed right from initialization?

Thank you for your insights!

Best regards,

Engineer 0815

Best answer by sergey23

When your driver returns from init, there is some time - usually about a second or so, for Ethernet to initialise - sense the signal, autonegotiate speed, etc, then if you have DHCP, get the IP.  During that time, it can’t send and will drop frames.

You need to understand that Ethernet is always 2 controllers: MAC and PHY. A separate PHY controller is needed cause Ethernet can operate over very different medias - optic, copper, etc, that use vastly different way of dealing with frames. So you can init your MAC perfectly but it still can take time for PHY controller to initialise. More on Ethernet on STM32 is in this “STM32 Ethernet explained” video (the associated article is at https://mongoose.ws/articles/stm32-ethernet-explained/)  

 

Can you timestamp the events after boot, and print ticks on every UDP send, when driver returns from init, when PHY establishes mode and speed, and when you get an IP (if DHCP is used), and share those timestamped logs?

 

2 replies

sergey23
sergey23Best answer
Associate
August 20, 2026

When your driver returns from init, there is some time - usually about a second or so, for Ethernet to initialise - sense the signal, autonegotiate speed, etc, then if you have DHCP, get the IP.  During that time, it can’t send and will drop frames.

You need to understand that Ethernet is always 2 controllers: MAC and PHY. A separate PHY controller is needed cause Ethernet can operate over very different medias - optic, copper, etc, that use vastly different way of dealing with frames. So you can init your MAC perfectly but it still can take time for PHY controller to initialise. More on Ethernet on STM32 is in this “STM32 Ethernet explained” video (the associated article is at https://mongoose.ws/articles/stm32-ethernet-explained/)  

 

Can you timestamp the events after boot, and print ticks on every UDP send, when driver returns from init, when PHY establishes mode and speed, and when you get an IP (if DHCP is used), and share those timestamped logs?

 

    Engineer0815Author
    Associate
    August 31, 2026

    Thank you Sergey23!

      Terms & ConditionsAccessibility statement