2017-11-13 01:41 AM
Hi
basically I tried to set up LWIP and freertos on a F429ZI nucleo board. everything went fine, unless: I observed the following bug:
Bug description:
1. start FW with ethernet cable disconnected
2. wait for 10 secnds
3. plug ethernet cable
4. ping board
-> board wont reply to ping.
I also went to ST's official example projects under.
STM32Cube_FW_F4_V1.17.0\Projects\STM32F429ZI-Nucleo\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS
In this code I had to diable DHCP, but then: same problem.
Any idea what to do ?
Thx
#lwip2017-11-13 01:48 AM
That's a known 'feature' of the example code.
You should poll the PHY's connection state and start/stop lwip accordingly.
JW
2017-11-13 02:17 AM
Interesting! Is there a reason behind that?
Is there an example code for the polling? I would really appretiate it, if you could gve me some more details about what needs to be done!
Thx
2017-11-13 03:39 AM
Interesting! Is there a reason behind that?
Yes, it's easier to program.
gve me some more details about what needs to be done!
I don't Cube. It appears that it's implemented in Cube for the EVAL boards - search for ethernetif_set_link() - note that they may have a different PHY, and your board may not have the interrupt signal from PHY connected, so you might need to cope with that by polling.
JW
2017-11-14 03:05 AM
Hi
actually it would be pretty easy to do it.
::::::::quick hack 1: takes 1 minutes
increase ETH_TIMEOUT_LINKED_STATE to a longer time: drawback still at some point it will time out!
::::::::quick hack 2 : takes 1 minutes
in HAL_ETH_Init() comment out the return condition in 'while (((phyreg & PHY_LINKED_STATUS) != PHY_LINKED_STATUS));'
Now firmware will wait for ever till ethernet cable gets connected. Drawback will be that remaining firmware will not be executed till cable is connected.
::::::::clean solution: takes 20 minutes
put LWIP initialization in a low prio thread and continue init as soon as cable is connected.
So is this a BUG in CUBEMX then?
Thx
2017-11-14 04:19 AM
Hi
st.mcu
Is this start up issue which exists in cube as well as in many LWIP official ST example projects , a bug or is this desired behaviour/feature?
Thx
2017-11-14 04:39 AM
So is this a BUG in CUBEMX then?
A bug is a mismatch between specified behavior (requirements) and observed behavior.
What is specified ... ? :\
2017-11-14 05:57 AM
To state my personal experience and opinion, this is a prototype and showcase project, like most other free examples accompanying MCU development hardware. The intention is to show that, yes, this hardware/MCU is capable of performing a certain task.
Such example often use to leave out certain aspects of error handling, configuration handling, and robustness.
In other words, it is D.I.E. - code (Debugged Into Existance).
If it passes a two-minutes smoke test of the developer, it's usually assumed fine and shipped.
Not that other vendors are different in this regard - you can even get intentionally crippled stuff elsewhere.
I learned to treat example that way, and fared well.
2017-11-14 08:26 AM
Demo code is to allow a proof-of-concept to be demonstrated, it is not, and should not be treated as, production ready code.
2017-11-14 10:33 AM
Hi, the issue exists in CUBEMX Autogenerated code as well. Or do you want to say Cube is not production ready code either?