[FreeRTOS+TCP] problems with IP assigning

Libraries
1

Using Freertos+tcp v4.2.4 (from LTS)

in some network I have a strange issue:

  • DHCP ON
    the device never complete the lease of address, continue to send discover and never complete the ip address assignement
    [IP-Task] vDHCPProcessEndPoint: enter 0
    [IP-Task] DHCP-socket[32-00]: DHCP Socket Create
    [IP-Task] prvCreateDHCPSocket[32-00]: open, user count 1
    [IP-Task] prvInitialiseDHCP: start after 100 ticks
    [IP-Task] vDHCP_RATimerReload: 100
    [IP-Task] vDHCPProcessEndPoint: exit 1
    [IP-Task] vDHCPProcessEndPoint: enter 1
    [IP-Task] vDHCPProcess: discover
    [IP-Task] vDHCPProcessEndPoint: exit 2
    [IP-Task] vDHCPProcessEndPoint: enter 2
    [IP-Task] vDHCPProcess: discover
    [IP-Task] vDHCPProcess: timeout 1000 ticks
    [IP-Task] vIPSetDHCP_RATimerEnableState: Off

and repeat this sequence infinite times

If i put a breakpoint after sending the “discover” the sequence end and I receive the IP address

  • DHCP OFF
    same issue, I can’t assigne a static IP, and passing from network down and network up, if I put a breakpoint in network up event the ip is correctly assigned

It’s strange that with a breakpoint I can receive/assign the ip, seem to be a timing issue or something not setted propertly

the config modify this values

#define ipconfigMAXIMUM_DISCOVER_TX_PERIOD ( 120000U / portTICK_PERIOD_MS )
#define dhcpINITIAL_TIMER_PERIOD ( pdMS_TO_TICKS( 1000U ) )
#define ipconfigUSE_DHCP_HOOK ipconfigDISABLE

2

that looks as if your DUT does not receive any packets, can you put a breakpoint into the Rx flow chain to see if anything reavhes your unit?

Also, what is your hardware?

3

My hardware is a custom board based on STM32F767 with RMII LAN8742a
the rx flow seem to be ok

Update:
I think could be a issue related to the version I’m using, I just move to 4.3.3 (latest official release) and the problem disappear.

I don’t know how is the fix that solve the problem, in my opinion is something reletated to timeout calculation, version 4.2.4 always 1000 tick, this one fail the first time but the second time timeout is 2000 tick and it’s work…
maybe related to timeout calculation but I’m not sure about this part

4

Which network interface implementation are you using with v4.3.3?
Is it the legacy interface or the unified STM32 interface?

5

unified STM32 Interface

6

Are you keeping the definition of ipconfigETHERNET_DRIVER_FILTERS_PACKETS same in both the versions?

7

yes, default value, ipconfigDISABLE

8

Is it possible to capture the DHCP packets under same subnet and share with us?

9

Update,

first of all I have a issue with systick configuration, now it’s fixed

But now DHCP doesn’t work at all (version 4.3.3)

Here Is a wireshark capture, the discover and the reply with the offer

686 17.507461 0.0.0.0 255.255.255.255 DHCP 300 DHCP Discover - Transaction ID 0x700bdb19
687 17.510991 192.168.10.1 255.255.255.255 DHCP 342 DHCP Offer - Transaction ID 0x700bdb19

but the board never accept the incoming packet. Seem to be a rx issue but if I wait and I assign a fixed IP I can ping the board successfully and I can start a Mqtt connection sending and receiving packets… only dhcp process doesn’t work

xApplicationDHCPHook_Multi is called only sending the discover packet whit argument eDHCPPhasePreDiscover and no more call after that

10

Maybe I found a possible problem,

I’ve compiled my project using the official ST HAL driver stm32f7xx_hal_eth.c (shipped with Hal packet 1.17.3 (may 2025))

instead using the file located in Driver/F7

with ST’s file I have the problems described in previous post.

with FreeRTOS’s file the problems seem to be solved…

I must use the file provided in freertos packet?

11

Yes, the drivers provided along with the FreeRTOS+TCP are tested with the unified network interface; other versions of the driver are yet to be tested.