Skip to main content
dieter 123
Associate III
November 13, 2017
Question

Help: bug in official ST nucleo LWIP Project

  • November 13, 2017
  • 15 replies
  • 2788 views
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
This topic has been closed for replies.

15 replies

waclawek.jan
Super User
November 13, 2017
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
November 13, 2017
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

waclawek.jan
Super User
November 13, 2017
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
November 14, 2017
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

AvaTar
Senior III
November 14, 2017
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 ... ?  :\

dieter 123
Associate III
November 14, 2017
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

AvaTar
Senior III
November 14, 2017
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.

Tesla DeLorean
Guru
November 14, 2017
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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
dieter 123
Associate III
November 14, 2017
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?

Oussema Hajjem_O
Visitor II
November 15, 2017
Posted on November 15, 2017 at 18:01

Hello

dieter.dieter

,

This is not a bug, the auto-detection of the Ethernet cable is notimplemented for all boards,

In your case you need to reset the board after cable connection.

If you want you can send me your application and will implement this features for you

Best regards,

Oussema.

AvaTar
Senior III
November 15, 2017
Posted on November 15, 2017 at 18:41

This is not a bug ,...

That would be debatable.

A real, paying customer would have specified and demanded such a thing ...

Luckily it is not difficult to implement.