NetX Duo driver & link-down state

[JDosp.1]

Hi All,

I am working at project with STM32H7 and NetX Duo. At current version of Ethernet driver from ST (X-CUBE-AZRTOS-H7 v3.0.0) is not handled by any way state when link is disconnected. Link status variable nx_interface_link_up is set at "Enable Link" (nx_ip_driver_command=NX_LINK_ENABLE) and "Disable Link" (nx_ip_driver_command=NX_LINK_DISABLE). But there is no modification of this variable when phy-link goes down.

Should be control of this variable implemented into driver, when I detect link down via MDIO interface? Or it is OK do not set nx_interface_link_up when link is physical down (e.g. disconnected Ethernet cable)? In case of control of nx_interface_link_up should be implemented, what is best place inside driver (NX_LINK_GET_STATUS, NX_LINK_USER_COMMAND, etc.)?

Thank for answer

Regards,

Jan

[MSG_ST]

Hi,

In NetXDuo interface we have just to fill the _nx_driver_hardware_get_status() which will be called by _nx_driver_get_status().

After that NetXDuo offers an API to get the link status from the application: nx_ip_interface_status_check() with argument “NX_IP_LINK_ENABLED�? in this case

_nx_driver_get_status() will be called.

Below, the implemented architecture in X-Cube Azure H7 3.0.0:

_nx_driver_hardware_get_status() is filled in “nx_stm32_eth_driver.c�? and it is called by _nx_driver_get_status().

nx_ip_interface_status_check() is called with argument “NX_IP_LINK_ENABLED�? in “app_netxduo.c�?.

I hope my answer help.

Regards

Mahdy

[JDosp.1]

Hi Mahdy,

Thank you for your answer. What did you described is a structure of Ethernet driver which I know already.

I asked same question to Microsoft directly. Answer was to call _nx_ip_driver_link_status_event() API when link state change is detected. I haven't opportunity yet implement this into my code. I think ST should change Ethernet examples with NetX Duo by same way.

Regards,

Jan

[elliott]

Thanks for the pointer on that function, @JDosp.1 .  This was helpful for me to understand how to dynamically manage link status.  I ended up using this approach:

1. Register link status change callback with nx_ip_link_status_change_notify_set()
2. Call _nx_ip_driver_link_status_event() in interrupt handler when link status changes
3. Call nx_ip_driver_direct_command(), passing NX_LINK_ENABLE if the link is up, or NX_LINK_DISABLE otherwise (see below)

This seems pretty solid based on my limited testing.  The link handling here is done on the NetX IP thread.

 

 

static VOID nx_app_link_status_change_notify(NX_IP *ip_ptr, UINT interface_index, UINT link_up)
{
 ULONG result;

 /* Send command to Enable/Disable Nx driver. */
 nx_ip_driver_direct_command(&NetXDuoEthIpInstance,
 link_up ? NX_LINK_ENABLE : NX_LINK_DISABLE,
 &result);
} 

 

 

EDIT:  Updated above with call to nx_ip_driver_direct_command(), replacing the manual call to the driver interface.

[robmilne]

Hi Elliott,

I would like to implement your callback scheme rather than having a thread that periodically calls nx_ip_interface_status_check().  Could you please explain point #2 in more detail so that I may try this method?

Thanks,

-rob

[GreenGuy]

Mahdy Sghaier,

What will cause a link to be established? I am trying to get the nx_server example working using the same version referenced, but so far no luck and calls to nx_ip_interface_status_check() with “NX_IP_LINK_ENABLED�? is returning 0x43, which I understand to be a time out condition indicating that the link is not up and did not come up during the period given. I have tried setting the wait condition to WAIT_FOREVER, and, of course, the call never returns. There must be a call missing when bringing up the nx server to establish a connection with the default IP set when not using DHCP.

[GreenGuy]

I finally got resolution on why I could not get the link to be established. STM found a bug in the BSP package code related to the lcd driver. I am using the lcd on the STM32H743i-eval board as a trace tool. Apparently, the BSP code for initializing the screen tries to drive a reset using PA2 which is being used by the ethernet (MDIO pin). The LCD does not need a reset and the schematic does not show reset lines driving out to the LCD. So this is a bug. Commenting out the reset call fixes the problem.

In stm32h743i_eval_lcd.c:

find:

int32_t BSP_LCD_InitEx(...

and comment out:

   /* Toggle Hardware Reset of the LCD using its XRES signal (active low) */

   //BSP_LCD_Reset(Instance);

I also went the extra step and found the function definition and commented out the source.