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]

Just more details to the memory sequence shown in the screenshot above (starting at address 0x2007D8D0):

The first six byte (0xA8, 0x1E, 0x84, 0x6E, 0xEE, 0x82) represent the MAC address of the ping request sender (my laptop), the next six byte represent the MAC address of my Nucleo board which responds to the ping (0x00, 0x80, 0xE1, 0x00, 0x00, 0x00). The next two byte define the ethertype (0x0806 for ARP). All following bytes until address 0x2007D8EF contain the ARP request answer, ending with the IP address of my board 0xAC, 0x16, 0x50, 0x02 (equals to 172.22.80.2).

As addition to the first question: during debugging, I also checked the DMACHTBAR register (ethernet DMA current host transmit buffer address register) points to my buffer address 0x2007D8D0.

I have no idea, why there is this sequence of 55:d5:... as the sender's MAC address, I can not explain how my memory data get corrupted.

[wastl]

Here is some more information (but the problem itself is not resolved yet)...

I wrote a script (Python) to read out the complete SRAM data (address range 0x20000000 - 0x2007FFFF) via UART to see if the data sequence seen in Wireshark (55555d55 57555557 55d5f555 5555fd57 5557fd5f d57fffd7 fd575557 55555555 55555555) is located anywhere in the SRAM.

Result: This sequence or a even a single 8 byte packet like 55555d55 is NOT located anywhere in the SRAM. So maybe it is a hardware problem. Investigations are going on. Another possible reason is that the PHY on the Nucleo board is configured wrong, but I can not see such a problem at the moment (initialization process of the STM32 Cube IDE HAL driver seems to be OK as there are only a few registers written (Basic Control register and Interrupt source flag register).

[Piranha]

Disable the D-cache, DHCP client, link detection and maybe it will somewhat "work". Yes, it's ridiculous. ;) ST doesn't provide a working network stack...

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

[wastl]

Just an update...

Debugging (logic analyzer) showed that the data transferred via the RMII (TXD0, TXD1) is correct. So I think the error is caused either by a kind of wrong PHY configuration or a broken PHY.

[wastl]

Just another update...

As described above, the seems to transmit always the same data via ethernet cable, regardless of the data send by the STM32F7 via the RMII. The length of the data packet on RMII for the ping response (ARP reply) is 72 bytes which is the correct number as far as I understand the ARP reply message (this 72 bytes contain the preeamble, SDF and CRC checksum).

However, I tried this example here: https://community.st.com/s/question/0D50X0000AhNBoWSQW/actually-working-stm32-ethernet-and-lwip-demonstration-firmware

I programmed my Nucleo-board, connected it to a DHCP server (FritzBox, because the example implements a DHCP client) but even this example does not work. The link is established, an IP address can not be assigned to the Nucleo board. I think there is a hardware problem with the Ethernet transmit path (only the transmit path, data are received correctly).

Maybe I have to order another Nucleo-board...

[Haithem Rahmani]

hi @wastl​,

before ordering a new board, could you share why the application below is not compiling?

https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F767ZI-Nucleo/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS

regards

Haithem.

[wastl]

Hi @Haithem Rahmani​ ,

as described above I use the STM32CubeIDE (1.5.1) and I just imported the LwIP_HTTP_Server_Netconn_RTOS.

Compiling the project fails with the console output

21:49:58 **** Build of configuration Debug for project LwIP_HTTP_Server_Netconn_RTOS ****

make all

arm-none-eabi-gcc "A:/ST_Mikrocontroller/STM32CubeIDE_Workspace/workspace_1.5.0/LwIP_HTTP_Server_Netconn_RTOS/Middlewares/Third_Party/LwIP/src/apps/http/fs.c" -mcpu=cortex-m7 -std=gnu11 -g3 -DSTM32F767xx -DUSE_HAL_DRIVER -DUSE_STM32F7XX_NUCLEO_144 -c -I../../../Inc -I../../../Src -I../../../Drivers/CMSIS/Device/ST/STM32F7xx/Include -I../../../Drivers/CMSIS/Include -I../../../Drivers/STM32F7xx_HAL_Driver/Inc -I../../../Drivers/BSP/STM32F7xx_Nucleo_144 -I../../../Drivers/BSP/Components/Common -I../../../Drivers/BSP/Components -I"../../../Middlewares/Third_Party/LwIP/src/include/                                                       " -I../../../Middlewares/Third_Party/LwIP/system -I../../../Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM7/r0p1 -I../../../Middlewares/Third_Party/FreeRTOS/Source -I../../../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -I../../../Middlewares/Third_Party/FreeRTOS/Source/include -O1 -ffunction-sections -Wall -fstack-usage -MMD -MP -MF"Middlewares/LwIP/apps/http/fs.d" -MT"Middlewares/LwIP/apps/http/fs.o" --specs=nano.specs -mfpu=fpv5-d16 -mfloat-abi=hard -mthumb -o "Middlewares/LwIP/apps/http/fs.o"

A:/ST_Mikrocontroller/STM32CubeIDE_Workspace/workspace_1.5.0/LwIP_HTTP_Server_Netconn_RTOS/Middlewares/Third_Party/LwIP/src/apps/http/fs.c:33:10: fatal error: lwip/apps/httpd_opts.h: No such file or directory

 #include "lwip/apps/httpd_opts.h"

         ^~~~~~~~~~~~~~~~~~~~~~~~

compilation terminated.

make: *** [Middlewares/LwIP/apps/http/subdir.mk:21: Middlewares/LwIP/apps/http/fs.o] Error 1

"make all" terminated with exit code 2. Build might be incomplete.

21:50:00 Build Failed. 2 errors, 0 warnings. (took 1s.855ms)

So, the httpd_opts.h file is not found.

I also attached a screenshot of the "Problems" output.

Regards

wastl

[Andrei Chichak]

The 55 55 55 data that you are seeing is normal.

Ethernet will listen to the wire to see if anybody is sending, and when there is a gap in the conversation will start talking (much like a cocktail party conversation).

The first thing it sends out is 7 octets of 0x55, which in binary is 0b0101 0101 on and off. It finishes this stream with 0xd5 == 0b1101 0101. Now, this is all sent LSB first, so the preamble bit stream looks like:

...10101010101010101010101011

This is sent so that the various receivers on the wire can tune their electronics using auto-gain control. Remember, this all came out of a time when everybody was listening to a piece of thumb-thick coax cable.

Then the real information starts to flow, the destination and sender MAC address and flags, etc. etc.

Andrei from The Great White North

[wastl]

Hi Andrei,

I know about the 7 0x55 octets ("preamble") and the 0xd5 octect ("SDF") of the ethernet communication. But I do not expect this to see this 8 octets in Wireshark as source or destination MAC address or part of the data (which by the way it is not, there are too few 0x55 octets before the 0x5d octet).

As mentioned above, I can see the correct data transferred via the RMII interface (7x055 and 1x0x5d followed by the MAC address of the ping sender 0xA8, 0x1E, 0x84, 0x6E, 0xEE, 0x82, ...) but the data on the Ethernet lines do not seem to correspond to the data on the RMII interface. Unfortunately, I do not have the tools to directly debug on the cable itself.

I agree that the data sequence and MAC addresses captured in Wireshark look like (at least a part of) the Ethernet preeamble and SDT packets.

I thought that the ping response packet itself was too short and so the preeamble/SDF is interpreted as part of the MAC addresses, but the packet size transferred via RMII is 72 byte which is OK in my understanding. Maybe the PHY sends a longer preeamble or repeats it (which it should not) for some unknown reason. The PHY on my Nucleo board is LAN8742A from Microchip. I also did a dump of all PHY register, the contents are correct as far as I understand:

BasicControlRegister: 0x1100

BasicStatusRegister: 0x782d

PHYIdentifier1Register: 0x7

PHYIdentifier2Register: 0xc131

AutoNegotiationAdvertisementRegister: 0x1e1

AutoNegotiationLinkPartnerAbilityRegister: 0x1100

AutoNegotiationExpansionRegister: 0xcde1

AutoNegotiationNextPageTXRegister: 0x2001

AutoNegotiationNextPageRXRegister: 0x4000

MMDAccessControlRegister: 0x0

MMDAccessAddressDataRegister: 0x0

EDPDNLPCrossoverTimeRegister: 0x41

ModeControlStatusRegister: 0x2

SpecialModesRegister: 0x60e0

TDRPatternsDelayControlRegister: 0x9b9d

TDRControlStatusRegister: 0x0

SymbolErrorCounterRegister: 0x0

SpecialControlStatusIndicationsRegister: 0xa

CableLengthRegister: 0x3000

InterruptSourceFlagRegister: 0xc8

InterruptMaskRegister: 0x0

PHYSpecialControlStatusRegister: 0x1058

However, maybe I will try to the get the LwIP_HTTP_Server_Netconn_RTOS example compiling and running.

I will let you know as soon as there are some news.

Kind regards.