Stuck in UART_WaitOnFlagUntilTimeout HAL lib

[kecskesgery]

Posted on January 04, 2016 at 18:38

Hello there!

I'm trying to communicate with the STM spwf01sa wifi module via UART. At first, it works for about 10-15 minutes, then the software stucks, right after the HAL_UART_Receive, in theUART_WaitOnFlagUntilTimeout function. What is actually happening, is that it never quits the while loop, because, for some reason, the HAL_GetTick()'s value wont change (HAL_Init gets called up uppon software start).

static HAL_StatusTypeDef UART_WaitOnFlagUntilTimeout(UART_HandleTypeDef *huart, uint32_t Flag, FlagStatus Status, uint32_t Timeout)
{
uint32_t tickstart = 0;
/* Get tick */ 
tickstart = HAL_GetTick();
/* Wait until flag is set */
if(Status == RESET)
{
while(__HAL_UART_GET_FLAG(huart, Flag) == RESET)
{
/* Check for the Timeout */
if(Timeout != HAL_MAX_DELAY)
{
if((Timeout == 0)||((HAL_GetTick() - tickstart ) > Timeout))
{
/* Disable TXE, RXNE, PE and ERR (Frame error, noise error, overrun error) interrupts for the interrupt process */

See, because the last IF condition never recieves true value, the whole wait cycle wont quit this way. My question is that, is it a known issue, a bug in the Cube lib? Or can I bypass it somehow? Also, why does not work the HAL_GetTick function? Thanks for the help in advanced! #uart #irq #clive1 #uartwait

[kecskesgery]

Posted on January 06, 2016 at 11:50

Hi!

Can somebody give me an idea at least? Still waiting for reply....

Clive?

[Tesla DeLorean]

Posted on January 06, 2016 at 15:10

HAL isn't my thing.

The tick here depends on SysTick firing and a variable incrementing. If the interrupt is not enabled, or you are running in an interrupt context already that might block the SysTick, the count will not advance. It might be better to use a free running HW timer, or not dwell in interrupt context. You could check the preemption level and priority assigned to the SysTick.

[kecskesgery]

Posted on January 06, 2016 at 17:34

Hi!

Thanks for the respone clive! That was my first thought, I have already changed the SysTick IRQ prio from 0x0F (for some reason, that was the default value), to 0x0, and also the group prio to 0. But still, I get stuck in the same cycle, and the SysTick wont increment. Also, I notice, that the software ends up a lot of times, in the mentioned wait cycle, but quits it by reading the RXE UART flag.

while(__HAL_UART_GET_FLAG(huart, Flag) == RESET)

So this brings me the question, if I can do something about the SysTick issue, by checking maybe the given flag in my code in advanced? I really dont know... BTW, yes, I'm running the UART code in a IRQ. Ideas are still appreciated!

[dvd]

I have the same problem, does someone managed to solve it?

I found also these two topics about this issue:

https://github.com/particle-iot/firmware/issues/776

https://github.com/micropython/micropython/issues/3375

but I can't find an exact solution

[Tesla DeLorean]

Make sure that the tick interrupt ​has the highest priority and can preempt, so it advances in interrupt and callback contexts.

[SPren]

What was the solution in the end? Having the same issue.

[CiuppaPT]

What was the solution in the end? I have the same issue. I have tried to set TIMEOUT at 0 instead of 1000

AL_UART_Receive(&huart3, (uint8_t *) pucByte, 1, 0 /*1000*/);

In my case only the receive are affected from this issue.

[KWu.12]

Anyone find a solution to this? I'm not even using interrupts but getting the same issue trying to use printf with a Nucleo board...

[lm.1]

Hi Team,

I have also faced the same issue with some of my MCU "STM32L412R8T"

I sat for 3 days with all the possible ways. End of the day i have updated the software package version, The issue is been solved.

Thanks.

[al.1]

Disable overrun. That solves it. This bug is still in the most recent version.

[D.Heink]

Hi, how do i disable overrun?

[al.1]

Sorry, don't know this for HAL, but for LL it's: LL_USART_DisableOverrunDetect(USARTx)