Skip to main content
Graduate II
August 27, 2024
Solved

Basic UDP Echo server works in debug, but not run mode NUCLEO-F746ZG

  • August 27, 2024
  • 2 replies
  • 1943 views

I have a Nucleo F746ZG board and I've implemented a small UDP echo server in LwIP standalone mode. (No RTOS)

If I hit 'debug' and as soon as the code stops on the first instruction hit 'continue' then it works perfectly.

If however I just run the code, (no debugging) or reset the board it does not work. It sits in a loop patiently waiting for a DHCP address. I know this because I use the three LEDs to show status. 

Here is my main loop code:

 

int main(void)
{
 /* USER CODE BEGIN 1 */
 /* USER CODE END 1 */

 /* Enable the CPU Cache */
 /* Enable I-Cache---------------------------------------------------------*/
 SCB_EnableICache();

 /* Enable D-Cache---------------------------------------------------------*/
 SCB_EnableDCache();

 /* MCU Configuration--------------------------------------------------------*/

 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();

 /* USER CODE BEGIN Init */
 /* USER CODE END Init */

 /* Configure the system clock */
 SystemClock_Config();

 /* USER CODE BEGIN SysInit */
 /* USER CODE END SysInit */

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_USART3_UART_Init();
 MX_USB_OTG_FS_PCD_Init();
 MX_LWIP_Init();
 /* USER CODE BEGIN 2 */

 HAL_GPIO_WritePin(LED_GREEN_PORT, LED_GREEN_PIN, GPIO_PIN_RESET);
 HAL_GPIO_WritePin(LED_BLUE_PORT, LED_BLUE_PIN, GPIO_PIN_RESET);
 HAL_GPIO_WritePin(LED_RED_PORT, LED_RED_PIN, GPIO_PIN_SET);

 while(dhcp_supplied_address(&gnetif)==0) {
	 ethernetif_input(&gnetif);
 	 sys_check_timeouts();
	 HAL_Delay(100);
 }

 HAL_GPIO_WritePin(LED_BLUE_PORT, LED_BLUE_PIN, GPIO_PIN_SET);

 udpServer_init();

 HAL_GPIO_WritePin(LED_GREEN_PORT, LED_GREEN_PIN, GPIO_PIN_SET);
 HAL_GPIO_WritePin(LED_RED_PORT, LED_RED_PIN, GPIO_PIN_RESET);


 /* USER CODE END 2 */

 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 while (1)
 {
 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */
	 ethernetif_input(&gnetif);
	 sys_check_timeouts();
 }
 /* USER CODE END 3 */
}

 

As you can see it's reasonably straightforward. I turn on the RED led, wait for a DHCP address (pumping the LWiP timeouts as required) and when it comes in switch on the BLUE led, and then when everything is running, switch off the RED and turn on the green. 

In debug this works fine, even without stepping.

In run time it stops after the red led comes on.

I'm guessing timing issue, or HAL_Delay() is hanging up? 

Any ideas?

    This topic has been closed for replies.
    Best answer by ASEHST

    Hello @KMill,

    It appears that is a timing or synchronization issue. Debug mode can introduce additional delays that allow certain components to initialize correctly. Please try adding a delay after the initialization of the peripherals.

     

    With Regards,

    2 replies

    ASEHSTAnswer
    ST Employee
    August 27, 2024

    Hello @KMill,

    It appears that is a timing or synchronization issue. Debug mode can introduce additional delays that allow certain components to initialize correctly. Please try adding a delay after the initialization of the peripherals.

     

    With Regards,

    KMillAuthor
    Graduate II
    August 27, 2024

    Hi @ASEHST 

    Thanks for your suggestion.

    If I add 1800ms of delay after SystemClockConfig() then it all works.

    I tried 1500ms too, but it was too little. I would love to understand what is happening here, but for now I'll just include that delay. I have placed it inside the USER CODE BEGIN SysInit block.

    Thanks again.

    Super User
    March 4, 2025

    @KMill wrote:

    I would love to understand what is happening here


    Yes, that would be better than just inserting an arbitrary, "blind" delay!

    See also:

    https://community.st.com/t5/stm32-mcus-embedded-software/stm32f767-lwip-tcp-client/m-p/778561/highlight/true#M60716

    ST Employee
    July 7, 2025

    Hello @KMill ,

    During the initialization process, the ETH MAC must be configured with the correct Ethernet link speed and duplex mode after the auto-negotiation process is completed, which can take up to few seconds (see the API HAL_ETH_SetMACConfig).

    To resolve the issue, a call to the API Ethernet_Link_Periodic_Handle in your both loops (dhcp_supplied_address & main) must be added.

    This API will periodically polls the PHY status and updates the MAC configurations if any changes occur to the Ethernet link.

    An example can be retrieved in "STM32F769I_EVAL\Applications\LwIP\LwIP_HTTP_Server_Raw" application in STM32CubeF7 v1.17.0 package.

    Note: There is no need to add an additional HAL_delay().

    Best regards.