S32K148 lpuart receive issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K148 lpuart receive issue

Jump to solution
1,372 Views
JOE_1209
Contributor III

Hi

I am using S32K148 and got a problem with lpuart1 receving.
I use ProcessorExpert to generate code. Below is the UART setting

Transfer type: interrupt
Parity mode: disable
Stop bits: 1
Bits per char: 8


My below function keeps reading continuous bytes in a if statement in main thread.

LPUART_DRV_ReceiveData(INST_LPUART1,&Buffer[BufferCount],1);

The below isr indicates received data for the main thread, and increments the BufferCount.

void rxcallback(void *driverState, uart_event_t event, void *userData)
{
/* Unused parameters */
(void)driverState;
(void)userData;

/* Check the event type */
if (event == UART_EVENT_RX_FULL)
{
uart_flag = 1 // used for indication of rx received
BufferCount++;
}
}

When the LPUART_DRV_IRQHandler is called, it's occationally stuck in the line below for around 1 ms(in the function: LPUART_SetReceiverCmd(base, false);), which causes lost to a byte . (it usually takes 3us for the function: LPUART_SetReceiverCmd(base, false);)


while((bool)((base->CTRL & LPUART_CTRL_RE_MASK) != 0U) != enable) {}

When I comment out the line in lpuart_hw_access.h, the UART works just fine. UART can keep continuous reading steadily. What could be the cause for the mask operation to take this long?

static inline void LPUART_SetReceiverCmd(LPUART_Type * base, bool enable)
{
base->CTRL = (base->CTRL & ~LPUART_CTRL_RE_MASK) | ((enable ? 1UL : 0UL) << LPUART_CTRL_RE_SHIFT);
/* Wait for the register write operation to complete */
// while((bool)((base->CTRL & LPUART_CTRL_RE_MASK) != 0U) != enable) {}
}

an I found a similar problem in here: S32K146 LPUART EDMA failed - NXP Community

The difference is the transfer type only I guess

Best Regards,

Joe

0 Kudos
1 Solution
1,320 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @JOE_1209,

This can happen when the receiver is already receiving a new character.

danielmartynek_0-1650377365324.png

Can you tried with a lower baudrate?

Or can you increase the system clock frequency?

The SDK drivers have rather significant CPU load.

 

Regards,

Daniel

 

View solution in original post

0 Kudos
2 Replies
1,321 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @JOE_1209,

This can happen when the receiver is already receiving a new character.

danielmartynek_0-1650377365324.png

Can you tried with a lower baudrate?

Or can you increase the system clock frequency?

The SDK drivers have rather significant CPU load.

 

Regards,

Daniel

 

0 Kudos
1,269 Views
JOE_1209
Contributor III

Hi Daniel,

 

Thanks for the reply.

It has been fixed by putting LPUART_DRV_SetRxBuffer in the interrupt for UART receive. No need to change the frequency.

 

Regards,

Joe

 

 

 

 

0 Kudos