2023-01-31 08:25 AM
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
Solved! Go to Solution.
2023-04-10 05:47 PM
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.
2023-02-15 08:20 AM
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
2023-02-16 10:53 PM
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
2023-03-14 02:46 PM
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.
2023-04-10 05:47 PM
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.
2024-06-17 11:11 AM - edited 2024-07-29 12:33 PM
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:
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.
2024-07-29 11:59 AM
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
2024-07-29 12:18 PM
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;
}
}
2024-07-29 12:39 PM
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