netxduo link state not initialized properly

[stst9180]

Dear Community,

We're just building up a product with NetXDuo on a STM32H563 having some issues with the Link-Establishment.

We use newest CubeMX (6.11.0) with newest Firmware-Package (1.2.0) to generate the init-code and use the same PHY as in the Eval-Board (lan8742).

If a link is not available on boot, because auto-neg takes a while the network will never come up. In this case dhcp tries to sent a request again and again and will be blocked at _nx_driver_packet_send because link is not established (nx_stm32_eth_driver.c @757 )

As I can follow the code, the NetXDuo IP thread will only call the driver with NX_LINK_ENABLE on the first initialization before the thread-loop ( nx_ip_thread_entry.c @207 ) which will call "_nx_driver_enable" ( nx_stm32_eth_driver.c @494 ).

There is only a way to call the NX_LINK_ENABLE again with a call to nx_interface_attach ( which is the wrong way I think as the interface is already attached ).

For my opinion "_nx_driver_enable" needs to be called again on a l8er link-establishment. I'm still wondering if this is a thing that should be done in either the driver, the NetXDuo stack or the application.

Doing this in the driver may not be triggered by the driver itself, as we don't have a "timebase" for polling the phy-state here. Nevertheless we could poll the phy-state by the application using "nx_ip_interface_status_check". Then the driver could enable itself when a link is established. For my opinion there is no direct nx-api call to re-issue a NX_LINK_ENABLE to the driver.

Another option would be to report a bug to the NetXDuo to re-call the NX_LINK_ENABLE when a phy-link is established (which is difficult as ST is using a rather old version of AZURE).

Nevertheless I'm missing examples or some hints how to do so.

Providing an example .ioc file would be hard work at this point because we're working on custom hardware here. Hopefully one can reconstruct the problem theoretically with a code-walk along the given lines.

Regards Pascal

[Pavel A.]

This looks like a general NetX issue, not specific to STM32. DHCP should not send anything while physical link is down.

> Another option would be to report a bug to the NetXDuo

If you can verify that the L2 driver correctly reports the link state and the system timer is sane, then please do this.

https://accounts.eclipse.org/mailing-list/threadx

 

[stst9180]

I've also posted this issue to threadx mailing list (reference follows).
Nevertheless I created an .ioc that directly shows this issue with the STM32 NUCLEO-H563ZI board as I also need this for another Issue.

I just generated the Init code and pushed software to the board (no user-defined code at all).

LinkStatus is only pushed up when I do a breakpoint at lan8742.c @261 to "wait" for the phy coming up after init.
Otherwise no network-functionality is given.

Again: As ST is using an rather old version of threadx, I'm not sure if Threadx mailing list is the right address. Maybe some ST-employee may also have a look here to fix this in the init code.

For My project I fixed this by the following patch AND periodically calling:

 

UINT result = nx_ip_interface_status_check(&NetXDuoEthIpInstance, 0, NX_IP_LINK_ENABLED, &status, TX_NO_WAIT);

 

Patch:

diff --git a/CubeMX/BK_SM/Middlewares/ST/netxduo/common/drivers/ethernet/nx_stm32_eth_driver.c b/CubeMX/BK_SM/Middlewares/ST/netxduo/common/drivers/ethernet/nx_stm32_eth_driver.c

index a037879..78ec1bd 100644

--- a/CubeMX/BK_SM/Middlewares/ST/netxduo/common/drivers/ethernet/nx_stm32_eth_driver.c

+++ b/CubeMX/BK_SM/Middlewares/ST/netxduo/common/drivers/ethernet/nx_stm32_eth_driver.c

@@ -1880,11 +1880,19 @@ static UINT _nx_driver_hardware_get_status(NX_IP_DRIVER *driver_req_ptr)

{

/* Update Link status if physical link is down. */

*(driver_req_ptr->nx_ip_driver_return_ptr) = NX_FALSE;

+

+ if(nx_driver_information.nx_driver_information_state >= NX_DRIVER_STATE_LINK_ENABLED) {

+ _nx_driver_disable(driver_req_ptr);

+ }

}

else

{

/* Update Link status if physical link is up. */

*(driver_req_ptr->nx_ip_driver_return_ptr) = NX_TRUE;

+

+ if(nx_driver_information.nx_driver_information_state == NX_DRIVER_STATE_INITIALIZED) {

+ _nx_driver_enable(driver_req_ptr);

+ }

}

 

/* Return success. */

 

[Pavel A.]

Aha, now this is understandable. Looks like the ST board does not have the PHY status interrupt, or it is not configured. So the default generated code has no means to detect link status change, unless user adds polling code. 

The link polling code maybe should be added to the template, similar to LwIP projects. At very least, add a note about link status update in the README's or generated source. In LwIP & FreeRTOS examples there was a dedicated task to poll the link, in real life this can be done in any low prio periodic task.

 

 

[mkrk]

Hit the same issue with STM32H573, LAN8742 and NetXDuo. DHCP client did not get IP and did not even send out any packets. The solution / workaround was like @Pavel A. said - periodically check if link is up with this:

nx_ip_interface_status_check(&NetXDuoEthIpInstance, PRIMARY_IF, NX_IP_LINK_ENABLED, &actual_status, 10);

And if it is up (and stays up) then (re)enable the driver with direct command:

nx_ip_driver_direct_command(&NetXDuoEthIpInstance, NX_LINK_ENABLE, &actual_status);

Looks odd but I can't tell what is the nice solution.