USART_WakeUpFromStop1 leads to lost characters

[BErik.1]

While experimenting[*] with the USART_WakeUpFromStop1 example on my NUCLEO-L496ZG I noticed that repeatedly entering STOP1 mode leads to dropped character if running with a baudrate > 4800 bps. I'm using STOP1 mode in a different project and I hoped to find a way to correctly communicating on 115200.

Any pointers on how to achieve this?

[*] I had to some minor modifications to STs example

* Rewrote the reception callback to store the received bytes in an array and printout in main() instead of echoing them in the handler

void USART_CharReception_Callback(void)
{
  /* Read Received character. RXNE flag is cleared by reading of RDR register */
  ubReceivedChar = LL_USART_ReceiveData8(USART1);
  rx_buff[rx_buff_i++] = ubReceivedChar;

  /* Check if received value is corresponding to specific one : S or s */
  if ((ubReceivedChar == 'S') || (ubReceivedChar == 's'))
  {
    ...

* Removed everything not related to STOP mode from the main loop

while (ubFinalCharReceived == 0)
{
  PrepareUSARTToStopMode();
  EnterStop1Mode();
}

[TDK]

What characters are dropped? If you wake it up by sending "Hello world" with no breaks between characters, what ends up in the rx_buff buffer after the full string is received?

[BErik.1]

Duplicate due to moderation delay removed

[BErik.1]

It's a bit random and varies with the baud rate. Repeatedly sending the string "abcdefghijklmnopqrs" can yield:

abcegiklnoqs
abceghjlnprs
abcefhikmnpqs
abdegiklnoqs
abdfhjlmnoqs

We didn't notice this problem until we began automating some processes with pyserial and nothing worked. Turns out my standard terminal, minicom, paste so slow[*] that no characters gets lost.

[*] With inter-character delay set to 0

[TDK]

Looks like a slight mismatch in baud rate.

If you have a way of measuring the clock with any precision, perhaps do that. Or increase/decrease baud rate by about 3% to see if it works. If you are using HSI, it can be trimmed to be more accurate.

[BErik.1]

Thanks. Changing the baud rate helps the 9600 case but at 38400 and upwards no tweaking helps. And the reception works fine if I don't enter STOP1.

I've also tested an optimal calibration value using AN4736 but without success.

[Carl_G]

Are you changing clocks in and out of STOP?

[BErik.1]

Not as far as I can tell. I've never worked with the LL HAL.

The code is in https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Projects/NUCLEO-L496ZG/Examples_LL/USART/USART_WakeUpFromStop1/Src/main.c with a couple of minor changes as described above.

[TDK]

I'm not so sure this is a baud rate issue anymore. Do you get an error flags like frame error, noise error, or parity error?

Characters are dropped, but never corrupted.

Could be code going too slow to capture everything, but the drop pattern is odd.

I'm assuming the examples you sent above are actual observed results.

[Carl_G]

What's your clock config for the USART? Clocks do change when you enter STOP. But it might not matter. I changed my clock config so stop mode would not affect the USART.

And you're not using the DMA?