Bytes lost when reading using LPUart1 (MB1641 - WB15CC) in STOPx Mode

[Wiliam]

Dear ST professionals,

Continuing the previous problem reported at https://community.st.com/t5/stm32-mcus-products/mb1641-nucleo-stm32wb15cc-slowness-between-ble-and-uart/td-p/603759, I have problems when use LPUart to wake up from STOP Mode. I tried with STOP0, STOP1 and STOP2 Mode with the LPUart1_IRQHandler() interrupt. Most bytes of the response (RX) are lost. I can only wake up the MCU when I use Sleep Mode.

I based it on the application of ST LPUART WakeUpFromStop_Init. I carried out all the clock steps deemed necessary.

In the LPUart1_IRQHandler() function I call the LPUART_CharReception_CallBack() function. In this callback function, I perform the reading using the LL_LPUART_ReceibeData8(LPUART1) function, assembling the buffer within a while loop.

I think it's very likely that the problem is related to the clock used, but I didn't find the solution in several tests carried out in different ways.

Thank you in advance for your attention, and I can provide further technical details as you deem necessary.

Thank you for your continued attention,

William

[Wiliam]

In addition, I use 9600bps 8N1.

[STOne-32]

Dear @Wiliam ,

When the USART/LPUART kernel clock is OFF during stop mode, the maximum baudrate to correctly wake up the MCU from stop mode depends on the following criteria:

• tWUUSART (or tWULPUART) specified in the datasheet.
• USART/LPUART receiver tolerance (as described in the USART/LPUART chapters).

So, it might be in your application  case, to do a correct wakeup with USART/LPUART (i.e. without loosing data) is to keep the kernel clock ON during stop mode, with the induced extra consumption. 
For more details, you can refer to the application note AN4991 How to wake up an STM32 microcontroller from low-power mode with the USART or the LPUART.

Hope it helps you !  If Yes, you can push again the « Feedback yellow button » 🙂 with 5 stars. 
Ciao

STOne-32

[Wiliam]

Dear STOne-32,

Firstly, thank you very much for your immediate response.

I could visualize it at the moment when I would notify them that the problem was resolved.

I will experiment with your suggestions, but for now, the solution adopted was the following, and you can correct me if something doesn't agree:

SystemClock_Config(void)
{
.
.
.
    RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;
.
.
.
}

void PWR_ExitStopMode(void)
{
.
.
.

 /* Configure the system clock for the RUN mode */
 SystemClock_Config();

 /* Ensures that the clock will be the HSI upon return from Stop Mode. */
 LL_RCC_SetLPUARTClockSource(LL_RCC_LPUART1_CLKSOURCE_HSI);
}

Perhaps it was not yet the best (most optimized) solution, but so far, it was the best result obtained, allowing to work in Stop1 Mode with a consumption of 4.7uA when the system is off, 58uA in fast advertising (BLE) and 74uA when connected to a mobile device (BLE).

I will implement the suggestions presented to experience the differences and understand it all better!

Thank you for your valuable help!

Wiliam