cancel
Showing results for 
Search instead for 
Did you mean: 

UART TEACK flag stays reset at the end of HAL_UART_Init() - STM32U073

StefanInfi
Associate II

Hello, during my tests I have come across a strange issue. During the initializing phase, my application was hitting a WWDG reset (after ~400ms) constantly. This only happened after a couple resets (toggling the NRST pin LOW). 

I have concluded during debugging, that when this repeated resetting of the WWDG state occured, it is because the program is hanging on the autogenerated (via STM32CubeIDE) init function:

 

HAL_UART_Init(&huart2)

 

Looking further, it actually finishes most of the function code but hangs on the last function:

 

return (UART_CheckIdleState(huart));

 

It specifically hangs when doing the below check:

 

if (UART_WaitOnFlagUntilTimeout(huart, USART_ISR_TEACK, RESET, tickstart, HAL_UART_TIMEOUT_VALUE) != HAL_OK)

 

What baffles me, is how this is not repeatable behaviour. Most of the times I restart the MCU, it proceeds as intentioned. But sometimes it starts doing this infinite game of checking TEACK so long that WWDG resets it.

Before this code is executed, only other peripheral initilaization code is performed.

Any ideas?

Edit: Adding my current auto-generated USART parameters from the usart.c file

 

void MX_USART2_UART_Init(void) { /* USER CODE BEGIN USART2_Init 0 */ /* USER CODE END USART2_Init 0 */ /* USER CODE BEGIN USART2_Init 1 */ /* USER CODE END USART2_Init 1 */ huart2.Instance = USART2; huart2.Init.BaudRate = 1000000; huart2.Init.WordLength = UART_WORDLENGTH_9B; huart2.Init.StopBits = UART_STOPBITS_1; huart2.Init.Parity = UART_PARITY_EVEN; huart2.Init.Mode = UART_MODE_TX_RX; huart2.Init.HwFlowCtl = UART_HWCONTROL_NONE; huart2.Init.OverSampling = UART_OVERSAMPLING_16; huart2.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE; huart2.Init.ClockPrescaler = UART_PRESCALER_DIV1; huart2.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_RXOVERRUNDISABLE_INIT; huart2.AdvancedInit.OverrunDisable = UART_ADVFEATURE_OVERRUN_DISABLE; if (HAL_UART_Init(&huart2) != HAL_OK) { Error_Handler(); } if (HAL_UARTEx_SetTxFifoThreshold(&huart2, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK) { Error_Handler(); } if (HAL_UARTEx_SetRxFifoThreshold(&huart2, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK) { Error_Handler(); } if (HAL_UARTEx_DisableFifoMode(&huart2) != HAL_OK) { Error_Handler(); } /* USER CODE BEGIN USART2_Init 2 */ /* USER CODE END USART2_Init 2 */ }
View more

 

:)

10 REPLIES 10
ESawa.1
Associate III

Hey @Guenael Cadier,

we have exaclty the same behaviour. We use an STM32H750IB with multiple UARTs. Our firmware is splitt into 2 different parts (our custom bootloader, application firmware). From the application firmware we have a GPIO PD3 which is used to indicate if we run in the bootloader or application firmware. 

In the application firmware HAL v1.11.1, bootloader HAL v1.11.0. 

The application code runs in XiP from the external flash while the BL runs in the internal flash. In XiP we use Cache as well as a well configured MPU. 

To jump into the bootloader we simple set PD3 high and then reset the H7. From time to time we have the problem that the MX_USART2_UART_Init() stucks in the line: 

/* TEACK and/or REACK to check before moving huart->gState and huart->RxState to Ready */ return (UART_CheckIdleState(huart));

TEACK and REACK are just not set. But I would say this is only the case in 10% of the cases. 

Interesstingly this can also happen when we hold the RST by hand down, set PD3 high and let the system run. So it is not related to the PD3, it seems to be related to the time when we push the RST button. If we completly power cycle the chip this issue does not happen. But when we check the UART RX and TX lines they look completly normal. What could be the reason for it? Or do you have any idea of what we can try? 

Best regards,

Eric