cancel
Showing results for 
Search instead for 
Did you mean: 

NetX Duo driver & link-down state

JDosp.1
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

8 REPLIES 8
MSG_ST
ST Employee

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
Associate III

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

GreenGuy
Lead

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.

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.

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.

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

Hi Rob,

The Ethernet PHY I'm using has a dedicated interrupt output that I have hooked up to the STM32 as GPIO EXTI line.  I've enabled the link down & up interrupts on the PHY.  So, when the link status changes, the GPIO EXTI interrupt fires.  The default handler defined by ST's HAL has a callback that can be defined: HAL_GPIO_EXTI_Callback().  In this function (still in the interrupt), I added a call to _nx_ip_driver_link_status_event().  Here's the whole function:

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
    switch (GPIO_Pin)
    {
        case GPIO_PIN_6:
            // Notify NetX of the link status change
            _nx_ip_driver_link_status_event(&NetXDuoEthIpInstance, 0);
            break;

        default:
            break;
    }
}

 

This call informs the NetX system of the link status change.  This will trigger the NetX IP thread to wake and check on the link status.  I think this is important, because then the link check occurs on the NetX IP thread, rather than potentially contending with it for access to the PHY.
 
Hope that helps!

Hi Elliott,

Thanks.  That makes a lot of sense.  I'm using the LAN8742.  It looks like signalling link status will require re-purposing one of the LED outputs.

-rob