Ethernet Lose Connection in the Latest HAL version update

[Zainulabedeen]

I am using the STM32H733 controller along with the NetXDuo networking stack. The issue started after updating the HAL drivers in my project from version v1.11.0 to v1.16.0 (released on February 24, 2026).

After this update, I observed that when the device boots up and no network activity occurs for a certain period (for example, no ping requests are sent to the device or device sending any UDP packet), the Ethernet connection is eventually lost permanently. Once this happens, the device becomes unreachable over Ethernet, and neither a soft reset nor a hard reset restores the connection.

However, if the device receives a ping immediately after booting, or if it sends a UDP packet shortly after startup from the device, the Ethernet connection remains stable. In this case, normal operation continues without any issues until the device is reset again and no network activity is observed for a certain period as well.

This problem only appeared after updating the HAL drivers to version v1.16.0 and does not occur when using version v1.11.0.

Additionally, we are using the LAN89354 PHY layer instead of the LAN8742.

I would appreciate your guidance on how to resolve this issue so I can proceed with my project.

Many thanks.

[STackPointer64]

Hello @Zainulabedeen,

That is indeed an unusual issue. Could you please attach your project so I can review it? If your project is private, feel free to send me a private message, and I can provide a secure way for you to upload it.

Best regards,

[Zainulabedeen · Accepted solution]

Update on Ethernet connectivity issue observed after updating HAL drivers from v1.11.0 to v1.16.0 (STM32H7 + NetX Duo + external PHY LAN89354)

After debugging, the problem appears to be related to the MAC filter configuration, specifically the Broadcast Filter setting.

When the BroadcastFilter is enabled in:

• HAL_ETH_SetMACFilterConfig() in `stm32h7xx_hal_eth.c` file
• _nx_driver_hardware_initialize() in `nx_stm32_eth_driver.c` file

FilterConfig.BroadcastFilter = ENABLE;

the device is unable to establish proper network communication.

Observed behavior:

• arp -n shows incomplete entries (no MAC resolution)
• Ping/connectivity is unreliable or fails

When the BroadcastFilter is disabled:

FilterConfig.BroadcastFilter = DISABLE;

the issue is resolved:

• ARP resolution works as expected
• Stable communication is established

A similar issue has also been reported here as i have mDNS and DHCP client enabled as well:
https://community.st.com/t5/stm32-mcus-embedded-software/netxduo-mdns-and-dhcp-conflict-because-of-st-ethernet-driver/td-p/826677

It appears that enabling the BroadcastFilter blocks essential broadcast traffic (e.g., ARP), which prevents normal network operation.

Requesting clarification:

• Is this the intended behavior when BroadcastFilter is enabled? From the observed behavior, it appears that enabling this filter blocks essential broadcast traffic.
• Is disabling the BroadcastFilter a valid and recommended fix, or could this lead to any unintended side effects in other scenarios?
• If disabling the BroadcastFilter is only a workaround, is there a recommended configuration that allows required broadcast protocols while still keeping the filter enabled?

FYI: @STackPointer64  @sssooo 

[STackPointer64]

Hello @Zainulabedeen,

I have escalated the issue to the relevant team for resolution, as it is unusual behavior and should not happen. It is being tracked internally under ticket number CDM0061604.

Best regards,

[STackPointer64]

Hello @Zainulabedeen,

I just received confirmation from the development team. There was an API change in HAL_ETH_SetMACFilterConfig() in the ETH_MACFilterConfigTypeDef structure for the BroadcastFilter field.

With the new version, the BroadcastFilter field must be set to DISABLE to allow reception of broadcast packets. This is a valid fix, not a workaround.

Best regards,