cancel
Showing results for 
Search instead for 
Did you mean: 

Help: bug in official ST nucleo LWIP Project

dieter 123
Associate III
Posted on November 13, 2017 at 10:41

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

#lwip
15 REPLIES 15
Posted on November 13, 2017 at 10:48

That's a known 'feature' of the example code.

You should poll the PHY's connection state and start/stop lwip accordingly.

JW

dieter 123
Associate III
Posted on November 13, 2017 at 11:17

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

Posted on November 13, 2017 at 11:39

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

dieter 123
Associate III
Posted on November 14, 2017 at 12:05

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

dieter 123
Associate III
Posted on November 14, 2017 at 13:19

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

Posted on November 14, 2017 at 12:39

So is this a BUG in CUBEMX then?

A bug is a mismatch between specified behavior (requirements) and observed behavior.

What is specified ... ?  :\

AvaTar
Lead
Posted on November 14, 2017 at 14:57

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.

Posted on November 14, 2017 at 16:26

Demo code is to allow a proof-of-concept to be demonstrated, it is not, and should not be treated as, production ready code.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..
Posted on November 14, 2017 at 18:33

Hi, the issue exists in CUBEMX Autogenerated code as well. Or do you want to say Cube is not production ready code either?