Skip to main content
GStou
Associate II
April 17, 2026
Solved

LwIP not completing the DORA-DHCP schedule

  • April 17, 2026
  • 4 replies
  • 372 views

Added "DHCP" in the title to give the context.

Using an STM32H7S78-DK I try to set up the network to join an IPv4 network through DHCP.

I did set up the board using CubeMX, standard configuration, MPU activated.

FreeRTOS + LwIP

Removed all other interfaces I don't need.

Made sure the Ethernet clock shows 50MHz

The LED's on the RJ45 start to blink (Orange LED blinks with packets exchanged)

but I get no IP address.

digging in the possibilities I added a simple routine to monitor the DHCP advancements.

 struct dhcp *dhcp_data = netif_dhcp_data(&gnetif);
	 if (dhcp_data != NULL) {
	 printf("[DHCP] State: %d, Retries: %d\r\n", dhcp_data->state, dhcp_data->tries);
	 }

this shows I get stuck in state 6: waiting for an ACK

-> what could be behind this?

can someone share an .ioc file that sets everything correctly in MX?

Best answer by GStou

Some extra experimenting: changed the MCU voltage to 1.8V and the network behaves exactly as with the -DK board: DHCP-Timeout

Back to 3V3 an the DHCP process is successful.

Went back to the original board and found no option to alter the MCU Vdd.

But I found a header jp6, which I was not really getting any wiser on what it does.

search through the schematics relates it to the RMII, what if?

Tried to alter this setting and the DHCP server is responding.

-> JP6 needs to be in position PC1

4 replies

mƎALLEm
Technical Moderator
April 17, 2026

Hello,

What do you mean by "DORA" in the title?

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
GStou
GStouAuthor
Associate II
April 17, 2026

Discover

Offer

Request

Acknowledge

The packet exchange procedure of the DHCP proces

ST Employee
April 17, 2026

Hello @GStou,

First things first, could you please answer the following questions to help me better understand the issue?

  • Have you tried capturing the network traffic using Wireshark?
  • Was an ARP announcement packet sent?
  • Are you certain that your DHCP server is functioning correctly?
  • Could you also attach your STM32CubeMX configuration (.ioc file) so I can review it?

Best regards,

To improve visibility of answered topics, please click 'Accept as Solution' on the reply that resolved your issue or answered your question.
GStou
GStouAuthor
Associate II
April 21, 2026

I tried to reproduce the situation, as I was not trusting the waiting for ACK situation.

If true, the IP address should have been listed on the router DHCP server.

Now the board doesn't even identify the presence of the Ethernet cable anymore. LED's are on.

LED's could simply be the driver chip identifying the electric status of a connected Ethernet cable.

Can it be that I changed bit's on the board/µC that make things go bad?

Settings that remain over reprogramming?

ST Employee
April 21, 2026

Hello @GStou,

Have you tried inspecting the following project available in our GitHub repository? Please focus on the LwIP configuration and the DHCP implementation in the application, as the issue may be related to a misconfiguration in DHCP or the descriptors:

Best regards,

To improve visibility of answered topics, please click 'Accept as Solution' on the reply that resolved your issue or answered your question.
Andrew Neil
Super User
April 17, 2026
A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
GStou
GStouAuthor
Associate II
May 12, 2026

Took the liberty to acquire a second board: NUCLEO-H7S3L8

Loaded the demo "LwIP_TCP_Echo_Server" application: the board got a reply from the DHCP almost immediately.

Remains my question: is there something wrong with the STM32H7S78-DK board I have?

How can I be sure?

GStou
GStouAuthorAnswer
Associate II
May 12, 2026

Some extra experimenting: changed the MCU voltage to 1.8V and the network behaves exactly as with the -DK board: DHCP-Timeout

Back to 3V3 an the DHCP process is successful.

Went back to the original board and found no option to alter the MCU Vdd.

But I found a header jp6, which I was not really getting any wiser on what it does.

search through the schematics relates it to the RMII, what if?

Tried to alter this setting and the DHCP server is responding.

-> JP6 needs to be in position PC1