STM32WL33CC LPUART setting incorrect baudrate

[ola]

Hi All,

1. [Part Number] STM32WL33CC1
2. [Environment] Windows OS, STM32CubeIDE version 1.17.0, Firmware package STM32Cube FW_WL3 V1.0.0
3. [Schematics] STM32 Nucleo-64 development board
4. [Details] See below.
5. [Expected behavior] Data sent at 115200 from a remote terminal should be received by the STM32WL33 using the same baudrate
6. [How to reproduce] Build the LPUART_TwoBoards_ComIT example by ST and connect terminal program and set baudrate to 115200. 
7. [Occurrence] Consistent
8. [Sanity checks] What are the checks that you have already performed (example: Have you reviewed the existing examples - GitHub, Cube...).

Details

I imported an old UART driver from a previous project that I had successfully used for many years on STM32 microcontrollers. However, I noticed it wasn’t functioning as expected on the STM32WL33. Specifically, when I sent a command from Tera-Term, the received data on the STM32WL33 appeared corrupted, as if a different baud rate was being used.

To clarify, I’m not concerned with the low-power features of the STM32WL33’s LPUART. My project requires two UARTs, so I decided to use LPUART1 as the second COM port.

I’m running the system using an HSE clock at 48 MHz.

After performing basic sanity checks, I suspected the issue might stem from my inexperience with the LPUART. To investigate further, I decided to test the LPUART functionality using one of ST’s example projects, specifically the LPUART_TwoBoards_ComIT example.

Following the example instructions, I flashed two boards: one as a transmitter (Tx) and the other as a receiver (Rx). The two devices successfully communicated with each other. However, when I connected a logic analyzer to observe the data transmission at 115200 baud, I found that the data was garbled. Surprisingly, both boards appeared to accept the transferred data without issue.

Using the logic analyzer, I measured a bit width of 13 µs, corresponding to a baud rate of approximately 76923.077—significantly different from the expected 115200 baud. When I set the logic analyzer to 76923, I could correctly interpret the transmitted data.

This led me to debug the driver in-depth, where I eventually identified the root of the problem in the stm32wl3x_hal_rcc_ex.c file.

uint32_t HAL_RCCEx_GetPeriphCLKFreq(uint32_t PeriphClk)
{
  uint32_t frequency, spiFreqValue, krmValue;

  /* Check the parameters */
  assert_param(IS_RCC_PERIPHCLOCK(PeriphClk));

  /* No if clausule is covered */
  frequency = 0;

  switch (PeriphClk)
  {
     //
	 // Ohter code removed for brevity
	 //
#if defined(RCC_CFGR_LPUCLKSEL)
    case RCC_PERIPHCLK_LPUART1 :
      switch (__HAL_RCC_GET_LPUART1_CLK_CONFIG())
      {
        case RCC_LPUART1_CLKSOURCE_LSE:
          frequency = LSE_VALUE;
          break;
        case RCC_LPUART1_CLKSOURCE_16M:
          frequency = 16000000;
          break;
        default:
          frequency = HSE_VALUE / 2;
          break;
      }
      break;
#endif /* RCC_CFGR_LPUCLKSEL */
    default :
      break;
  }
  return (frequency);
}

The case RCC_LPUART1_CLKSOURCE_16M was missing setting the frequency as well as a break statement so it was automatically going to the default case. Adding the following line

frequency = 16000000U;
break;

Seem to have solve the problem. Unfortunately every time I change the ioc file. This gets overwritten by the default code with the bug so I thought to notify ST in order to see if the fix can be incorporate in the new build of the IDE and/or if there is a work around that can be suggested

Ola