Losses the bytes of data in LPUART IRQ HANDLER?

[vitthal muddapur]

I have configured LPUART with 9600 baud rate and enable receiver interrupt with MCU 65Khz low power mode and my uart handler like

void LPUART1_IRQHandler(void)

{

uint32_t isrflags  = READ_REG(hlpuart1.Instance->ISR);

 uint32_t cr1its   = READ_REG(hlpuart1.Instance->CR1);

 uint32_t errorflags;

 /* If no error occurs */

 errorflags = (isrflags & (uint32_t)(USART_ISR_PE | USART_ISR_FE | USART_ISR_ORE | USART_ISR_NE));

 if (errorflags == RESET)

 {

  /* UART in mode Receiver ---------------------------------------------------*/

  if(((isrflags & USART_ISR_RXNE) != RESET) && ((cr1its & USART_CR1_RXNEIE) != RESET))

  {

 UART_RX_Buffer[UART_Buffer_Counter]=LPUART1->RDR;

  UART_Buffer_Counter++;

if(UART_Buffer_Counter==UART_RX_BUFFER_LENGTH)

UART_Buffer_Counter=0;

   return;

  }

 }

}

and 200ms sytem tick interrupt,

• Some time losses the uart receiver byte data.
•  

[Tesla DeLorean]

Make sure the interrupt grouping/priority is such that this routine preempts others that can run excessively. ie SysTick or others doing a whole bunch on ancillary things.

Don't do any additional processing in the handler beyond filling the buffer.

[vitthal muddapur]

Thank you

When UART communication only Systick interrupt enable with 200ms.

[Bob S]

So the CPU is running at 65KHz. That means that you have approx 67 CPU clock cycles to respond to each UART interrupt (presuming 8-bit data, no parity which gives 960 bytes/sec). And that includes the exception setup/cleanup and stacking and unstacking registers. Going with what ​ @Community member​ said, and presuming that your ISR uses fewer than that many clock cycles (it looks like it should), then that doesn't leave a whole lot of time for anything else to preempt the LPUART_IRQHandler().