STM32F767ZI + lwip + FreeRTOS: no ping response / can not compile LwIP_HTTP_Server_Netconn_RTOS example

[wastl]

Dear all,

first I have to say that I am new to STM32F7 mirocontrollers, but I am not new to ARM-Cortex M4/M7 based controllers in general, nor the lwIP stack nor FreeRTOS.

I have the following two problems:

• SMT32F767ZI + lwIP + FreeRTOS: I tried to build a simple application using the lwIP+FreeRTOS (on a Nucleo-F767ZI board) using STM32CubeIDE (1.5.1). I set up a new project, configured my MCU and tried to ping my board. This, indeed, does not really work. There is a reply to the ping response, but it is a kind of "mysterious" data (a lot of 5s, which looks like a part of the synchronization sequenz of ethernet frame, but this should not be catched by Wireshark, see the attached file). I debugged the lwIP stack down to the point, where the response is sent and I have to say that even the data, which are referenced by the DMA transmit descriptors, seem to be OK (it is not the sequenz of the 5s, which is seen in Wireshark). Is there anybody, who has ever encountered such a problem? As PING packets are received and processed, I assume the basic configuration is OK. FreeRTOS and lwIP are included via the GUI (.ioc) file in STM32CubeIDE, the lwIP settings are nearly unchanged, the settings are: ICMP, TCP and UDP modules are enabled, checksum calculation is done by hardware.

• The second problem: I tried to set up my application on the LwIP_HTTP_Server_Netconn_RTOS example, imported into STM32CubeIDE workspace. But I can not build the example as a lot of files are missing (e.g. httpd_opts.h) and the directory structure of the example seems completely different than as it should be (e.g., there is no path "lwip/apps/httpd_opts.h). Does anybody know how to fix this problem (get the missing files)?

My application from the first question is configured like the LwIP_HTTP_Server_Netconn_RTOS example (MPU, fixed sections in memory), as far as I can reengineer it from the LwIP_HTTP_Server_Netconn_RTOS source files.

Kind regards and thank you for your help.

[wastl]

Hi @Haithem Rahmani​ ,

compiling the example works now, thanks for the tip.

Unfortunately, I still can not ping the board. I connected it to my Fritz.box to test DHCP, but the DHCP server can not assign an IP address (application then gets the static IP address 192.169.0.10). I also connected the Nucleo board directly to my notebook, configured my network card with 192.168.0.9 and tried to ping the Nucleo board - no success.

The ping response given by the board is the same as in my code, still contains a lot of 0x55 octets. I attached a screenshot, ping request is line 39, the reply given by the Nucleo board is line 40, the data section is also shown in the screenshot.

I think I am going to order a new board (just to be sure, the board is not that expensive) and some other "interesting stuff" to avoid the shipping costs.

Kind regards.

Wastl

[wastl]

Hi @Haithem Rahmani​ ,

thanks for the tip, the project compiles now without problems.

Unfortunately, I still can not ping the board. I tried two setups:

1. Connect the Nucleo board to my Fritz.Box (which is the DHCP server). Result: The Ethernet link itself is established (as a result of the autonegotiation I think), but the board can not be found. Debugging the application shows that the DHCP server can not assign an IP address to the board. As a result, the board gets the static IP address 192.168.0.10.
2. So I connected the board directly to the Ethernet card of my PC, assigned the address 192.168.0.9 to my Ethernet card and tried to ping the board again. Result: no ping response.

Find attached a screenshot of the Wireshark capture of setup 2 (ping request line 39, response line 40 e.g.). As you can see, the data section still contains a lot 0x55 octets.

However, I think I am going to order a second board (it is not that expensive) with some other "interesting stuff" to avoid the shipping costs ;-).

Kind regards.

wastl

[wastl]

​Dear @Haithem Rahmani​ ,

today my new Nucleo-F767ZI board arrived.

For a first test, I just flashed the LwIP_HTTP_Server_Netconn_RTOS example and tried to ping the board (IP address 192.168.0.10 and see there... It works!!! I don't know why but it seems to be an hardware related issue with my old board. However, further tests with my application are not done yet, I will let you know about the results.

Kind regards.

Wastl

[Haithem Rahmani]

great news!

just to let you know, the AzureRTOS is available on github for the STM32H7 it comes with a full featured TCP/IP stack the NetXDuo.

it supports the STM32H723Nucleo-ZG it is worth trying :)

regards

Haithem.

[wastl]

Dear @Haithem Rahmani​ ,

my FreeRTOS + lwIP application also works. As I did not change anything in the code, I would say that it can be confirmed that my first Nucleo-Board has a hardware issue.

Thanks for the help.

By the way: Is there a button (or something else) to mark my problem as resolved?

Kind regards.

Sebastian Reichhold

[Haithem Rahmani]

@Imen DAHMEN​  could you please update this post as resolved?

regards

Haithem.

[Piranha]

> However, I tried this example here... but even this example does not work.

As everything, that firmware also is not absolutely perfect and has some issues. After some time I will update it to even better performing and more polished one. :) That said, the issues are minor and not a showstoppers. It's probably useful to try with another network equipment and DHCP server just to be sure. Does the new board work in same conditions?

> Is there a button (or something else) to mark my problem as resolved?

Press "Select as Best" under the specific post.

[wastl]

I do not expect the firmware to be perfect ;-). My problem was that I could debug the signals the whole way from the microcontroller memory to the PHY and I could not find anything wrong. That is why I decided to order the new board to exclude a hardware problem on the old board.

I just tried the new board with the LwIP_HTTP_Server_Netconn_RTOS example, getting the IP address via a DHCP server (still my Fritz.Box). Worked very well, there were no problems pinging the board or visiting the webserver site with a browser (Firefox).

So I guess there is a hardware problem with the old board.

I marked my post with the result that there most likely is a hardware problem with the old board as "Select as Best".

Regards.