SRM32WB55 junk data over LPUART in interrupt mode

[APort]

Hello,

We came across a strange problem with LPUART on STM32WB55 chip.

When using FIFO in interrupt mode (receiving data), if you use FIFO depth more than 1 byte (even 2 or 8) you will occasionally (one out of ~1000 reads) get complete junk bytes (not always first byte of transition); If everything is the same, and you use 1byte FIFO (HAL_UARTEx_SetRxFifoThreshold(UART_RXFIFO_THRESHOLD_1_8))- it always works fine.

Obviously the other (sender) side never changes, it is always sending in junks of 4-8 bytes.

Note that we use flow control.

Apparently this is coming directly from RDR register in UART_RxISR_8BIT_FIFOEN.

Below is the init code. LPUART running on 32Mhz system clock - it never changes.

P.S. This issue is not mentioned in errata

P.P.S. We would sniff the data to make sure its not line issue, but it is a IPC lines berried deep inside the PCB.

Anyone came across something like this before?

Thanks in advance

hlpuart1.Instance = LPUART1;
hlpuart1.Init.BaudRate = 1000000;
hlpuart1.Init.WordLength = UART_WORDLENGTH_8B;
hlpuart1.Init.StopBits = UART_STOPBITS_2;
hlpuart1.Init.Parity = UART_PARITY_NONE;
hlpuart1.Init.Mode = UART_MODE_TX_RX;
hlpuart1.Init.HwFlowCtl = UART_HWCONTROL_RTS_CTS;
hlpuart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
hlpuart1.Init.OverSampling = UART_OVERSAMPLING_16;
hlpuart1.Init.ClockPrescaler = UART_PRESCALER_DIV1;
hlpuart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
hlpuart1.FifoMode = UART_FIFOMODE_ENABLE;
HAL_UART_Init(&hlpuart1);
HAL_UARTEx_SetRxFifoThreshold(&hlpuart1,UART_RXFIFO_THRESHOLD_1_2);
HAL_UARTEx_EnableFifoMode(&hlpuart1);

[TGUCL.1]

Hi

Not exactly but had a problem with similar symptoms with USART1 a while ago when enabled together with LPUART1.

Every now and then usart data was getting corrupted.It would sometimes taje 10 mins and sometimes > 4 hours

I came to realise LPUART interrupts had a higher priorirty. To fix the issue I have manually set HAL_NVIC_SetPriority

May be this can help

[Tesla DeLorean]

I think you'd need to demonstrate on a proxy board where you can get to the pins. Ideally an ST dev board.

Reviewing the registers in a debugger would cause issues, so you'd need to instrument you're own implementation to get visibility internally.

Watch for using auto/local variables for a buffer, and make sure to move data to a holding buffer and out of the active buffer if the reception continues while the data gets processed. Use volatile where appropriate, and double check if functionality changes with/without optimization enabled.

Does DMA show the same issues?

[APort]

Thanks for the ideas.

@TGUCL.1

We do not use USART1 in addition to LPUART1. I did check for nested interrupts - it was not the issue.

@Community member​ 

I did a simple debug code that checks the value returned from RDR inside UART_RxISR_8BIT_FIFOEN - since pattern is sent its easy trap. I don't think its compilation/buffer/etc issue.

We do not use DMA at all (sending 4-8 bytes at a time on that direction - FIFO should do the trick), I guess we can try it.

One important thing we did noticed debugging this, is that lowering the baud rate by half solves the issue (or at least lowers its frequency significantly).

The 1Mbaud used is far from documented limit of LPUART .. but maybe with combination of FIFO its lower?