2021-01-08 06:55 AM
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:
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.
Solved! Go to Solution.
2021-01-29 01:29 PM
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
2021-01-08 10:57 AM
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.
2021-01-17 12:14 AM
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).
2021-01-17 01:27 PM
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...
2021-01-21 11:26 AM
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.
2021-01-22 12:17 PM
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...
2021-01-22 12:32 PM
hi @wastl,
before ordering a new board, could you share why the application below is not compiling?
regards
Haithem.
2021-01-22 12:57 PM
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
2021-01-22 08:09 PM
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
2021-01-22 11:33 PM
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.