For what reason can UART RX interrupt freeze ?

[Thomas LB]

Hi all,

In the past, I've used HAL_UART_Transmit() with HAL_UART_Receive_IT() which freeze RX interrupt in case of RX interrupt while TX is still processing (see https://community.st.com/s/question/0D50X0000AhPrkRSQS/haluarttransmit-with-haluartreceiveit-fails-if-rx-when-tx-not-completed for more details). Now I use HAL_UART_Transmit_IT() and HAL_UART_Receive_IT and have almost no problem.

On one device (among around 80), one time, the RX interrupt seems to be no more triggered (same behavior than before using interrupt for TX) after few weeks of good behavior. I've tried to reproduce the issue by flooding TX while RX or flooding RX while TX but nothing makes the RX interrupt freeze :(

There was also a GPIO interrupt triggered on the Device with issue. The GPIO interrupt was same preemption level as UART interrupt but the ISR is very short (just set a flag) so I don't see how this can be an issue.

See my RX and TX callback :

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)  
{
if (huart->Instance == LPUART1){ // Current UART
  if (Rx_indx + 1 > rx_buffer_size){
    Rx_indx = 0;
  }
  if (Rx_data != 0x0A){ // If received data different from LF
    Rx_Buffer[Rx_indx++] = Rx_data;    // Add data to Rx_Buffer
  }
else {
  Rx_indx = 0;
  Transfer_cplt++;//transfer complete, data is ready to read
  }
  HAL_UART_Receive_IT(&hlpuart1, &Rx_data, 1);   //activate UART receive interrupt every time          
}
}
 
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart)  
{
if (huart->Instance == LPUART1){ // Current UART
  transmit_done = 1;
}
}

In HAL_UART_Transmit_IT and HAL_UART_Receive_IT there is still "__HAL_LOCK(huart)" so maybe the same root cause (but far less likely to occur)?

If you have some idea, let me know :)

[Tesla DeLorean]

Several noise, framing, parity errors that will stick in the USART and need to be cleared/check manually.

Would also check return codes/statuses from functions which might flag other failures.

Might want to migrate data to a non-transient buffer after completion.

[Thomas LB]

Hey,

Thank you for answer,

can you tell me more about the last part "migrate data to a non-transient buffer after completion" ? I'm not sure what you mean by that.

[Tesla DeLorean]

Rx_Buffer[] is constantly active/live, it has the potential for the content to change due to interrupts when you are processing/parsing the data elsewhere. Can lead to unexpected behaviour if the data is a constant stream

[Sgsda.1]

When you say ''firmware must defer the timing to permit the NAKed channel review.'' do you mean that I need to simply wait until the following SOF after which do some thing has to be carried out? Is there a manner to set the Cube firmware to do that?