NUCLEO-H753ZI: What is the difference between UART_Start_Receive_IT() & HAL_UART_Receive_IT()?

[I0nizer]

Hello,

I'm working with the NUCLEO-H753ZI dev board and I'm trying to understand how to set it up to both send and receive LIN messages. I want to have the board set up to have the USART1 interrupt trigger upon reception of a LIN message, but for some reason when I try to have the board set up in this manner, I can only see the message sent once before getting stuck in the UART_WaitOnFlagUntilTimeout() function. I have it set up with HAL_UART_Receive_IT set in a constant while loop in my code, but this causes the issue. However, without it there, I am never even able to trigger the interrupt. 

While looking through the code relating to UART, I see that there are two functions related to receiving UART data interrupts. What is the difference between the two of them?

Thanks & Regards

[TDK]

UART_Start_Receive_IT is used internally by the HAL library. It's not meant to be called directly.

The comments in the source code provide a useful amount of information about the functions.

/**
  * @brief  Start Receive operation in interrupt mode.
  * @note   This function could be called by all HAL UART API providing reception in Interrupt mode.
  * @note   When calling this function, parameters validity is considered as already checked,
  *         i.e. Rx State, buffer address, ...
  *         UART Handle is assumed as Locked.
  * @PAram  huart UART handle.
  * @PAram  pData Pointer to data buffer (u8 or u16 data elements).
  * @PAram  Size  Amount of data elements (u8 or u16) to be received.
  * @retval HAL status
  */
HAL_StatusTypeDef UART_Start_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size)

If HAL_UART_Receive_IT isn't receiving characters, perhaps none are coming in, or the clock is wrong, or it is misconfigured.

[Tesla DeLorean]

You're not supposed to call HAL_UART_Receive_IT() continuously, it returns immediately.

Check if it errors.

You're supposed to wait for the Callback function to be called when the data's actually received, and then you light off a new request, and process the data you've recovered.

[I0nizer]

So you're saying to only call the HAL_UART_Receive_IT() function once, and then call it again after the interrupt is triggered? Because that seems to also work in getting the interrupt to fire and allowing me to read the LIN message that is sent from another board. However, the issue remains in that I get stuck in a continuous loop when I try to enable the USART interrupt and continuously send LIN messages on the same board. 

I did some digging and looked at the status results from a bunch of key points and I eventually saw that after the first message is sent to the board, it gets trapped in the UART_WaitOnFlagUntilTimeout() function forever. This is why it only sends one LIN message, but never sends another. I looked into what flag was being passed to the function and it was the USART_ISR_RXNE_RXFNE flag. This says that the read data register is not empty, but I don't know why this is happening. It shouldn't be waiting until timeout to read only one message.

This error does not occur when I am not attempting to send any messages. It works perfectly fine when I am only attempting to receive messages. I only encounter the issue on a board both attempting to send and receive messages. Do you know where I should begin to look for the source of my error?

Thank you

[I0nizer]

I see that now. Thank you for pointing it out. However, I am also working on having another USART peripheral exchange serial communications with a custom Windows form app via micro-usb and it functions the best when continuously calling UART_Start_Receive_IT and not when calling HAL_UART_Receive_IT? Why would communication possibly be more reliable when using the function not meant to be called manually?

Thank you

[TDK]

> Why would communication possibly be more reliable when using the function not meant to be called manually?

Broadly, due to bugs in your program. Not sure it's worth much thought. Use functions as intended, chase down bugs as they occur using objective data and debugging techniques. Don't guess. Don't turn a knob just because you can.