STM32H75x LwIP Implementation Failing

[CMHenway]

Hello,

I have been following a few different Ethernet tutorials for my MCU (STM32H750VBT6TR) I have on a dedicated PCB. Thus far, I have been unable to get a simple ping test working. For reference, I am mostly using this tutorial in combination with this one, but I am not using freeRTOS at this time. I simply want to get LwIP to set up correctly and ping the board so I can then adapt it to a UDP server.

I know my memory locations for the rx/tx designators, and rx pool base, and the LwIP heap are in the right locations (assuming they are as the tutorial states), but my code fails when the LwIP.c file calls netif_add(), which makes me think the issue does not lie within the memory.

Can anyone who is more experienced in simple LwIP implementations help me out here? I am not sure where to turn at this point, as it does not seem people on other posts are having the same issues. I will attach my project files, namely the IOC, so anyone can look to see if there are any issues.

Thanks in advance! 

[Pavel A.]

So, what is your hardware? Is it a ST evaluation board or a custom board with custom PHY?

[CMHenway]

I am using a custom PCB with a DP83825IRMQR PHY IC. This uses the RMII interface. See below for the connections. 

I'm not sure how relevant the PHY IC is at this stage, as I cannot get the LwIP to initialize itself correctly as is. Does it need to communicate with the PHY at this stage, and is that a potential source of issues? I have the Platform Settings as the following currently: 

[LCE]

netif_add() calls the MCU's internal ETH peripheral inits, which includes the first communication to the PHY, so it is relevant.

Find out where exactly the problem occurs. I like UART debug messages for that.

Typical failure reasons:

- the DMA software reset fails because it might expect to be clocked from PHY, but there's no clock:

/* SoftWare Reset */
	/* set SWR bit: resets all MAC subsystem internal registers and logic
	 * 	NOTE: the SWR is not performed if the ETH_RX_CLK or the ETH_TX_CLK are
	 *			not available -> check external PHY or IO configuration
	 */
	ETH->DMAMR |= ETH_DMAMR_SWR;

 - other problems concerning PHY connections, because it is checked if the PHY is connected to something

So find out if you actually read and write correctly the most important PHY registers (link status. auto negotiation, ...).

Good luck hunting! It's not as easy as it looks, like click a little bit through CubeMX and get a working ethernet interface. And now you even changed the PHY... :D

[CMHenway]

Thank you for your reply!

You were correct in that the software reset was failing, as my PHY IC was not providing a reference clock. This is because of my reset logic for the PHY IC not actually agreeing with the GPIO level that was initialized. After fixing that, the PHY IC put out the reference clock, and the code executes correctly.

I now see status LEDs on the RJ45 port, but my board is failing to ping correctly. I have made sure my subnet masks match on the board and my PC. See the below images for my configuration. Any tips to get this to ping correctly would be much appreciated. Thanks!

[LCE]

Have you checked all other pins / GPIOs ? Selected the correct Alternate Function, highest speed, ...

Otherwise:

- observe network with Wireshark

- check / read the PHY registers - did it complete auto neg. ? what's the result ?

- UART debug messages - there's some lwIP #define option somewhere in some lwip / include / opt.h file to activate (LWIP_STATS_DISPLAY = 1)

/**
 * LWIP_STATS==1: Enable statistics collection in lwip_stats.
 */
#if !defined LWIP_STATS || defined __DOXYGEN__
#define LWIP_STATS                      1
#endif

#if LWIP_STATS

/**
 * LWIP_STATS_DISPLAY==1: Compile in the statistics output functions.
 */
#if !defined LWIP_STATS_DISPLAY || defined __DOXYGEN__
#define LWIP_STATS_DISPLAY              1
#endif

[STackPointer64]

Did you remember to uncomment the following two lines in your while loop? They are necessary for polling:

ethernetif_input(&gnetif);
sys_check_timeouts();

Also, as mentioned by LCE, check Wireshark traffic for ARP announcement packets. Additionally, run your app in debug mode when you ping it; the app could be hardfaulting when it receives or constructs a packet.

[CMHenway]

Quickly setting up wire shark, I am getting the ARP packet from my PC (192.168.0.100), but there is seemingly no acknowledgement from the STM. I will work to see if I can find a place to breakpoint a received packet and see if it calls.

FYI, I will attach the current project files, as the lines mentioned above are no longer commented out, and I am using USER_PHY under Platform Settings for LwIP.

Edit: To add to this, I am not getting my breakpoint within ethernetif_input that checks if the packet is not null to call. So, this is saying to me that there is a breakdown in the receiving of packets. I will start looking into probing the PHY IC to see if it gives data on its receive lines.

[STackPointer64]

You are not receiving any frames because you are using a custom PHY but have no drivers that allow your MCU to communicate with the PHY, which in your case is DP83825I. You need to find the drivers (source and header files) and include the header in the ethernetif.h file so that when the board is initializing, sending, or receiving data, the appropriate PHY functions are called.

[CMHenway · Accepted solution]

That is a very good point. I found a driver for a similar TI PHY IC that works with the one I have on my board. I ended up using the Undefined component for my Platform Settings in LwIP, as it gave the best prototype code. It was a little hacky for the ethernet_link_check_state() function, as there was no user code block, but I now have it where generated code will not override any changes.

All this to say that pinging my boards works now! The only odd behavior I notice is that if I leave the board for tens of seconds and then ping it, there is no reply for the first packet or two. Is this normal and maybe due to the PHY entering a waiting state? Of course, it would be optimal if all packets were responded to without a wakeup needed.

I will dump my project files and place a Wireshark capture of this behavior for those playing at home.