System Workbench for STM32

STM32CubeMX LWIP not working

I have just started experimenting with ST products. I have a STM32F4 Discovery board. I bought a DP83848 PHY on Ebay and connected it to the Discovery board. I downloaded a hex file from here:http://blog.tkjelectronics.dk/2012/08/ethernet-on-stm32f4discovery-using-external-phy/Question

I am able to ping the board and access the web page with no issues.

I then used CubeMX to create a project with nothing but LWIP and two GPIO pins. I figured I would start out simple. The goal was to see if I could get LWIP working. I generated the code and imported it into System Workbench and used STLink to program the board.

I cannot ping the board (I enabled ICMP in CubeMX) and it does not make a DHCP request. I know the request is not being made because Wireshark never sees it.

Do I have to put anything in the main() while loop for lwip to work? Do I need to make any modifications to use the DP83848? I noticed in CubeMX that in the Ethernet Settings, it states LAN8742A for the PHY. Maybe this is my issue? If so, what modifications need to be made to tell CubeMX to use the DP83848?

I have been working on this for two days and making zero progress. I am using Windows XP and the latest versions of CubeMX and System Workbench

Hi rcbuck,

Check if the configuration of GPIO clocks are suitable.
The following 3 functions must be called for enabling ethernet clock:

Furthermore, you may verify if the following GPIO pin are configured in Input mode



I confirmed all of the clocks are enabled and the GPIO pins are in Input mode. So ST32CubeMX generated that code properly.

If I modify the code to put in the MAC address that is used by the Hex code(that works) that I downloaded from the other website, Wireshark sees the board when it is started:
2 12.739183 DHCP 350 DHCP Discover - Transaction ID 0x5851f42d
3 12.740327 44:8a:5b:d3:4c:8b Broadcast ARP 60 Who has Tell

But the board doesn’t respond when the DHCP server asks “who has”. That is the IP address that the server assigns to the Hex file that does work. The DHCP entry is still in the lease table of the server, so the server knows that MAC address is supposed to be

I’m sure the problem is related to me using the DP83848 instead of the LAN8742A PHY. But I don’t know what to modify to correct the problem.


I am also facing similar issue, its been an year since your last post,. I hope you might have got it working. If so, can you pls post the solution that you had found. That would be useful for newbies of STM32F4-Discovery like myself.

Thanks in advance


Yes, I got it working. I zipped up my code and you can download it from this link:


The name of the file is STM_Ethernet.zip. The link will remain valid for 7 days.

I presently do not have any STM development tools installed on my computer so I cannot be of further assistance. Hopefully my source code will help you to solve your problem.


Thanks a bunch.

I know its been a year after your initial post. However, do you remember what was the solution that you found? If so, i request you to post it here, so that it might be beneficial for others as well.

I am having the same issue.
Do you mind sharing the code once again?



Unfortunately I do not remember what the solution was. After I got it working I put everything away and haven’t worked with the STM32 parts since then. I may do some work with STM parts in the future, but at this point I have moved onto other projects.

You can compare my code to your code and possibly find what makes your project work. As a first test, you could load my hex file that is in the Release folder into your board and see if it works.


I could finally solve the issue with my TCP IP connection.

In the new version of STM32F4-Discovery which is now known as STM32F407G-DISC1, it looks like PHY chip seems to be LAN_8742A instead of LAN_8720 as it was in earlier version.

STMCube selection of LAN_8742A “did not” set the right set of External PHY configuration parameters. For example, when we select ETH in STMCUBE for STM32F4-discovery board selection, the default selection of PHY was LAN_8742A_PHY and with PHY address as 1 and other values set accordingly.

With those values, the issue found was the HAL_ETH_GetReceivedFrame function always failed to pass through the following statement if(((heth->RxDesc->Status & ETH_DMARXDESC_OWN) == (uint32_t)RESET)) returning HAL_ERROR everytime.

When I had changed this PHY_ADDRESS to 0 and few other PHY parameters in accordance with 8742A registers, we could get the TCP communication working..

Thanks for your support and taking your time in digging and sharing out your old code :-)

- Srinivasan

I’m also have the same problem as you did.
I have tried with PHY_ADDRESS 0, but no luck.
Can you please share what other PHY parameters you changed.

Thanks in advance

I’m also have the same problem as you did.
I have tried with PHY_ADDRESS 0, but no luck.
Can you please share what other PHY parameters you changed.

Thanks in advance