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
