Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


changing DHCP usage in runtime when using FREERTOS+TCP

Posted by beaker1969 on April 24, 2015


I have managed to port over the FREERTOS+TCP for the STM32F429 (and have a simple webserver going.... am now going to implement your new webserver) but needed to be able to change if the DHCP is used or not in runtime and not at build level.

I managed to get it going by a few minor changes to the void 'vDHCPProcess' function in FreeRTOS_DHCP.c

if the DHCP is to be run i set the default IP address to

in the 'vDHCPProcess' routine it detects if the IP address is, if so it lets the routine continue as before. If not then DHCP state is set to a state where it thinks it has failed and therefore uses the default settings.

if the DHCP fails then the it is presumed that the default IP address is not be used and therefore fails to configure. I believe in a future release there will be mechanism for when a DHCP server fails, an IP addresses is allocated in the private range to

overall i find FreeRTOS+TCP much easier to use than my old lwip setup.


here are my changes.

void vDHCPProcess( BaseType_t xReset ) { /* Is DHCP starting over? */ if( xReset != pdFALSE ) { xDHCPData.eDHCPState = eWaitingSendFirstDiscover;

	// START OF added code
	if(xNetworkAddressing.ulDefaultIPAddress != 0x00)
			xDHCPData.eDHCPState = eWaitingOffer;
			xDHCPData.xDHCPTxTime = 0;
			xDHCPData.xDHCPTxPeriod = 0;
	// END of added code


//if( xDHCPData.xDHCPTxPeriod <= ipconfigMAXIMUMDISCOVERTX_PERIOD) // original.

if( xDHCPData.xDHCPTxPeriod <= ipconfigMAXIMUMDISCOVERTXPERIOD && (TickTypet)xNetworkAddressing.ulDefaultIPAddress == 0x00 ) //new version


had to modify last statement. needed to add (TickType_t) to xNetworkAddressing.ulDefaultIPAddress as it didn't work without it.

changing DHCP usage in runtime when using FREERTOS+TCP

Posted by rtel on April 25, 2015

Great info - thanks.

changing DHCP usage in runtime when using FREERTOS+TCP

Posted by heinbali01 on April 25, 2015

Hi Alan,

I have managed to port over the FREERTOS+TCP for the STM32F429

Glad to hear that.

am now going to implement your new webserver

The HTML/FTP servers depend on the new +FAT library. +FAT can either use a RAM disk or an SD-card (or any other memory).

At this moment the HTML server is quite simple: it only serves the GET requests. The FTP server, on the contrary, is very complete already.

An update of the HTML-server is planned quite soon: it will be extended with HEAD/POST/PUT and also there will be support for (CGI-style) requests from JavaScript.

For example:

GET /tcp_info?dhcp=? HTTP/1.1

which may trigger a typical JSON answer like this:


The FTP and HTML server are extremely 'cheap' in the sense that they do not create any new task. They have a common "work" function which can be called like this:

const TickType_t xInitialBlockTime = pdMS_TO_TICKS( 200UL );
for( ;; )
    FreeRTOS_TCPServerWork( pxTCPServer, xInitialBlockTime );

overall I find FreeRTOS+TCP much easier to use than my old lwip setup.

+TCP has a big advantage, it is based on FreeRTOS. LWIP has the difficult task of being compatible with any OS on any platform. The dependencies of +TCP are much smaller: it uses the standard types (uint32_t and so), and it uses all great features of FreeRTOS (queues, events, semaphores).

In fact there are only two dependencies on the hardware:

  • send and receive Ethernet packets, as implemented in: FreeRTOS-Plus-TCP/portable/NetworkInterface//NetworkInterface.c
  • endianness: big or little endian, which is just a switch defined as: #define ipconfigBYTEORDER pdFREERTOSLITTLE_ENDIAN

All other dependencies are already "covered by" FreeRTOS.

if the DHCP is to be run I set the default IP address to

I'm trying to get clear what it is that you want to add?

As you will understand, xNetworkAddressing.ulDefaultIPAddress will be used as The IP address in case DHCP has failed.

I made an embedded device which has these user options:

1) Use DHCP
2) Use DHCP as an advice
3) Do not use DHCP at all

Most people make the easiest and safest choice 1). DHCP dictates all data and the device just follows. The device will always store the latest:

- IP address
- Netmask
- Gateway

Now in case a device boots and does not get a DHCP response, it will use the last known settings. This works very well in most cases.

Option 2) the device gets a fixed IP address and netmask. Now only if the DHCP offer is incompatible with the currently used settings, the offer will be used. This will happen if the IP address is 192.168.1.xxx and DHCP comes with a 10.x.x.x address.

Option 3) use fixed settings. That would be OK if the situation never changes, each devices has its fixed place and IP address.

I must say that I miss a possibility to stop the DHCP negotiation. In the third case (ignore DHCP), there is no way to avoid the DHCP negotiation.

In the seconds case (advisory), I would like to have a callback, in which my application is asked for a confirmation:

BaseType_t xApplicationDHCPConfirmHook( struct XDHCP *pxData )


I keep on stressing, if possible: give your embedded devices a FIXED name and a VARIABLE IP address.

I make audio amplifiers with a HTML interface. The amplifier on my desk has 2 nicknames: e.g. "amplifier" and "ampli_lab".

Enable two protocols in your "FreeRTOSIPConfig.h":

#define ipconfigUSE_LLMNR    ( 1 )
#define ipconfigUSE_NBNS     ( 1 )

and define a callback:

BaseType_t xApplicationDNSQueryHook( const char *pcName )
        stricmp( pcName, "amplifier" ) == 0 ) ||
        stricmp( pcName, "ampli_lab" ) == 0 );

With this your devices can be found by ping, FTP-clients and browser. Windows XP will only use NBNS, whereas Linux and Win7 prefer to use LLMNR.

Regards, Hein

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner