STM32WB: UART baud rate calculation ignores APB2 prescaler when using PLL clock source

[Menazaa]

Describe the bug

Environment

• Board: STM32WB5MMG-DK
• Zephyr version: v4.1.0
• SoC: STM32WB55
• Architecture: ARM Cortex-M4

Bug Description

When configuring the STM32WB55 with PLL as the system clock source at 64MHz, UART baud rate calculations are incorrect and don't respect the APB2 prescaler setting. The actual UART baud rate is double the configured current-speed value when cpu1-prescaler = <1>, and the apb2-prescaler setting has no effect on the actual baud rate.

Expected Clock Tree Configuration

According to STM32CubeIDE clock tree analysis, with the following configuration:

• SYSCLK: 64MHz (from PLL)
• HCLK1: 64MHz (cpu1-prescaler = <1>)
• APB2: 64MHz (apb2-prescaler = <1>)
• USART1 Clock: Should be 64MHz (from APB2)

Device Tree Configuration

&pll {
    div-m = <2>;
    mul-n = <8>;
    div-q = <2>;
    div-r = <2>;
    clocks = <&clk_hse>;
    status = "okay";
};

&rcc {
    clocks = <&pll>;
    clock-frequency = <DT_FREQ_M(64)>;
    cpu1-prescaler = <1>;
    cpu2-prescaler = <2>;
    ahb4-prescaler = <1>;
    apb1-prescaler = <1>;
    apb2-prescaler = <1>;
};

&usart1 {
    pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>;
    pinctrl-names = "default";
    current-speed = <115200>;
    status = "okay";
};

Problem Details

Current Behavior:

• With cpu1-prescaler = <1> and apb2-prescaler = <1>: Actual baud rate is ~230400 (double the configured 115200)
• With cpu1-prescaler = <2> and apb2-prescaler = <1>: Actual baud rate matches 115200
• Changing apb2-prescaler to <2>, <4>, etc. has no effect on actual baud rate

Expected Behavior:

• Changing apb2-prescaler should directly affect the UART clock and thus the baud rate
• The actual baud rate should match the current-speed property

Clock Tree Analysis

Expected clock flow:

PLL (64MHz) → SYSCLK (64MHz) → HCLK1 (64MHz ÷ cpu1-prescaler) → APB2 (HCLK1 ÷ apb2-prescaler) → USART1

Current (incorrect) behavior suggests:

PLL (64MHz) → SYSCLK (64MHz) → USART1 (ignoring APB2 prescaler)

Root Cause Analysis

The issue appears to be in the STM32WB clock driver where:

1. The UART clock calculation doesn't properly account for APB2 prescaler
2. The driver may be using SYSCLK or HCLK1 directly instead of the properly prescaled APB2 clock
3. This affects all APB2-connected peripherals, not just UART

Workaround

Currently, the only workaround is to adjust the current-speed to compensate:

&usart1 {
	pinctrl-0 = <&usart1_tx_pb6 &usart1_rx_pb7>;
	pinctrl-names = "default";
	current-speed = <57600>;  // The effective baud rate is 115200
	status = "okay";
};

Impact

This bug affects:

• UART/USART peripherals on APB2 bus (USART1)
• Potentially other APB2 peripherals that depend on accurate clock calculations
• System timing accuracy when precise baud rates are required

Additional Information

• The issue is specific to STM32WB series when using PLL clock source
• This suggests the bug is in Zephyr's STM32WB clock driver implementation

Files Likely Affected

• drivers/clock_control/clock_stm32_ll_wb.c
• uart_stm32.c (UART clock source selection)

Regression

• This is a regression.

Steps to reproduce

1. Configure STM32WB5MMG-DK with PLL clock source at 64MHz
2. Set cpu1-prescaler = <1> and apb2-prescaler = <1>
3. Configure USART1 with current-speed = <115200>
4. Measure actual baud rate - it will be ~230400 instead of 115200
5. Change apb2-prescaler to <2> - actual baud rate remains unchanged
6. Change cpu1-prescaler to <2> - actual baud rate becomes correct 115200

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

• Board: STM32WB5MMG-DK
• Zephyr version: v4.1.0
• SoC: STM32WB55
• Architecture: ARM Cortex-M4

Additional Context

No response

[github-actions]

Hi @Menazaa! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[kbidani]

The clock-frequency property should reflect the actual SYSCLK value, which must not exceed the device's maximum frequency (64 MHz).
For example, if you want HCLK1 to be 64 MHz with cpu1-prescaler = <2>, then SYSCLK would need to be set to 128 MHz, which is not supported by the hardware. You should set cpu1-prescaler = <1>.
Or, if you want cpu1-prescaler = <2> , you should set clock-frequency = <DT_FREQ_M(32>.

[Menazaa]

The clock-frequency property should reflect the actual SYSCLK value, which must not exceed the device's maximum frequency (64 MHz). For example, if you want HCLK1 to be 64 MHz with cpu1-prescaler = <2>, then SYSCLK would need to be set to 128 MHz, which is not supported by the hardware. You should set cpu1-prescaler = <1>. Or, if you want cpu1-prescaler = <2> , you should set clock-frequency = <DT_FREQ_M(32>.

Thank you for the clarification.

According to the STM32WB5MMG clock tree (as shown in the STM32CubeIDE and the reference manual), the cpu1-prescaler divides the system clock (SYSCLK) to generate the HCLK1 frequency. So when cpu1-prescaler = <2>, the resulting HCLK1 should be SYSCLK / 2. In the attached image, this results in 32 MHz when SYSCLK is 64 MHz, which aligns with the expected behavior from the hardware.

I haven’t tested the impact on other peripherals yet, but based on the reference manual and the current driver behavior, I'm not yet sure if the discrepancy is due to the driver itself or the upstream function that resolves the clock frequency. For context, the clock is configured correctly via the devicetree, and CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is set to 64000000, which reflects the intended SYSCLK value.

Additionally, I’d like to refer to the baud rate calculation for USART as described in RM0434 Rev 14, Section 33.5.7:

Baud Rate = usart_ker_ck_pres / USARTDIV (for oversampling by 16)
Baud Rate = 2 × usart_ker_ck_pres / USARTDIV (for oversampling by 8)

This equation shows that the baud rate depends directly on the peripheral kernel clock (usart_ker_ck_pres). Therefore, any mismatch in clock configuration—such as an incorrect prescaler—could directly impact communication timing. I included a snapshot from STM32CubeIDE to illustrate how this kernel clock is derived in the specific clock tree for STM32WB5MMG.

Let me know if there's anything specific I should verify further.

[Menazaa]

I’ll try to verify this behavior with the SPI clock as well to see if it's similarly affected, which should help narrow down the root cause. However, I’m currently in the middle of another task, so I may not be able to look into it until later this week. I'll follow up as soon as I have an update.

[Menazaa]

Surprisingly, it's working now. I started debugging the ST driver, and the data in the registers looks correct. Initially, I converted the ST-Link to J-Link, but even after reverting and updating the ST-Link firmware, it began working with the correct baud rate. This suggests the issue may have been related to the ST-Link firmware version.

[kbidani]

Great!