2017-01-05 06:52 AM
I am currently working on a project that uses Etherne with CubeMX and lwIP.
During the development, I found rather difficult to manage the cases when the physical link becomes invalid (e.g. cable unplugged), or it is not valid at startup.
In theory, lwIP offers the functions netif_set_up() and netif_set_down() that inform the stack of the link state. In practice, this seems not to always work.
I'd like to share my experience if someone else is interested:
0) comment out the standard CubeMX initialisation MX_LWIP_Init(). This is of paramount importance!
1) add a network interface by calling netif_add(). You need it to check the link state in the next step.
2) call
HAL_ETH_ReadPHYRegister(&heth, PHY_BSR, &phyreg);
where heth is the CubeMX-generated instance of Eth, and phyreg is an uint32_t
3) if (phyreg & PHY_LINKED_STATUS) is not zero, then the link is valid and you can proceed with other operations:
netif_set_up()
dhcp_start()
...
then jump to 5)
4) If the link is not valid, don't proceed with network initialisation!! Instead, repeat the test periodically until the link is found valid. At this point, you need to remove the existing network interface and create a new one:
netif_remove()
netif_add()
... and so on
5) once the initialisation is completed, you should still monitor the link state. In case the link went down, call netif_set_down(). When the link returns up, call netif_set_up(). Don't remove/add the network interface or your connection will no longer work!
2017-01-05 08:04 AM
Hi
Scarpi.Giuseppe.002
,Thanks for sharing your experience.
In fact the idea behind the STM32 forum
(and any other forum I think) is to look for help and share experiences/solutions.
-Nesrine-
We are looking for your wishes about our STM32 products,ecosystem and community:
https://community.st.com/community/stm32-community/stm32-forum/blog/2016/12/30/2017-stm32-wish-list
2017-01-05 09:18 AM
Hi Nesrine, thank you for your kind comment!
One of your colleagues told me that integration of lwIP 2.0.0 in the Cube is on its way.
Perhaps this could be the occasion to review the auto-generated initialisation code, and make it resilient to link/cable events.
Giuseppe
2017-02-09 01:31 PM
I guess that you had solved the problem - but i would answer this rotten thread because others will find a solution too.
In LWIP there is an API called 'LWIP_NETIF_LINK_CALLBACK (Callback Function on Interface Link Changes)'
where is defined 'weak' and will called if the interface link state is changed. This could be used to handle the link state change by a user code. This function must be generaly enabled before this works. I had done this generaly and just do nothing if none action is required.
My solution is, to wait if the link is working again and start the dhcp client again to get an ip-address and send a message to the application to do what ever needs to do if the ip address is renewed.
2017-02-10 01:34 AM
Thank you for you answer, I will try this alternated approach.
Checking the source, I see a function
ethernif_update_config()
(part of Cube-generated code, not lwIP), which in turn calls :
__weak ethernif_notify_conn_changed()
I have to check if using this function completely solves the problem. In my experience, the case when the board turns on with the cable unplugged requires a special handling.
2017-02-10 01:33 PM
Giuseppe,
yepp, you're right in that point that an unplugged and replug or if the line characteristics are changed.In my cases, i restart the checkup of IF setup and let the dhcp client reassign the ip-address.
If the api should be used, this must be enabled in the config file.