Restart HAL_UART_Receive_IT

[yuri CH]

Posted on May 09, 2018 at 14:37

Hi!

in my program i am using the 'HAL_UART_Receive_IT' function, it is first called when i initialize my app.

There comes a moment during the run of the program when the pointer to buffer given to the function expires and is no longer valid, this is when i want to call this function again with new parameters.

The problem is that the operation doesnt succeed and the HAL_BUSY retval is returned.

please advise on how to restart this function properly after it has already been used.

thanks alot!

[Nesrine M_O]

Posted on May 09, 2018 at 14:50

Hi

yuri.cherniakov

,

Please have a look to this example it may help you :

STM32Cube_FW_L4_V1.0\Projects\STM32L476G-EVAL\Examples\I2C\I2C_TwoBoards_RestartComIT:

This example describes how to perform a single I2C data buffer transmission/reception

between two boards in Interrupt mode and with a restart condition.

-Nesrine-

[yuri CH]

Posted on May 09, 2018 at 15:18

Hi Nesrine,

Thanks for responding. unfortunetly this doesnt help since i'm using UART communication.

[Tesla DeLorean]

Posted on May 09, 2018 at 15:35

Reflect on the library code provided, and write something better. There is no value to building a fine house on a poor foundation. I prefer a clean/elegant approach over an abstracted/obtuse one.

With the HAL you'd likely need to transition the object's buffer state in the IRQ Handler prior to calling into the HAL layer, or lock down the interrupt/structure to reconfigure it.

[T J]

Posted on May 09, 2018 at 15:53

this seems to be the problem:

'There comes a moment during the run of the program when the pointer to buffer given to the function expires'

this is an architectural issue. imho

[Tesla DeLorean]

Posted on May 09, 2018 at 16:07

Yeah, I don't like the use of auto/local variable for DMA or IRQ buffers.

If the scope is finite, manage it with a timeout. As I've observed before the HAL often get's in its own way, and has a paradigm that frequently doesn't fit what people are used to, or is 95% complete.

[Pavel A.]

Posted on May 10, 2018 at 02:59

This is likely because the HAL function checks 'busy' flag set by it's previous call.

If the flag is set it immediately fails.

https://github.com/pavel-a/stm32f4_libs/blob/db5c1ad80b84837d8c52efabd071e1e65811a340/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_usart.c#L707

.

So you need to let the HAL function complete, or call

https://github.com/pavel-a/stm32f4_libs/blob/db5c1ad80b84837d8c52efabd071e1e65811a340/STM32Cube_FW_F4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_usart.c#L1193

.

-- pa

[Daniel Glasser]

Posted on May 12, 2018 at 00:08

You should either use a statically or dynamically allocated buffer for the UART or use an automatic (stack allocation) buffer that is declared at a scope that does not 'expire'.  Static allocation of buffers is easier to debug, though other schemes are possible.  Stack allocation is particularly hard to debug because the interrupt callback functions don't have the stack variables from the non-interrupt thread in their scope.  The buffer is still there, but there's no really good way to get the address of it using the array name for the buffer.

In any case, I recommend not calling the 'HAL_UART_Receive_IT()' function in your initialization routine.  You can set up the interface there without calling the receive function.  Instead, make the receive call at the top of a main loop where the buffer does not go out of scope until the program exits.  You can cancel any pending IO on the way out.  Having the input pending before you are prepared to process the data then switching to a new buffer will cause any data received up to that point to be lost anyway, so it's best to wait to make the receieve call until you're ready to process the data.

[yuri CH]

Posted on May 13, 2018 at 07:18

Thaks everyone for your responses,

I understand that the 'expiration' of the pointer to the buffer is an architechtural issue that has to be dealt with.

unfortunetly, i have inhereted some code that can not be changed at this part of the project.

I am particularly intrested in the HAL_UART_Abort function, this would help me solve the probem, i was unable to find it in the HAL functions.

i am working on the STM32F7 , is the set of the abort commands is not yet implemented for the F7?

[Pavel A.]

Posted on May 14, 2018 at 02:05

> 

i am working on the STM32F7 , is the set of the abort commands is not yet implemented for the F7?

Have you looked? Have you downloaded the F7 libraries? 

-- pa