search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.44k stars 6.4k forks source link

STM32WL does not support HSE as RCC source and HSEDiv #37260

Closed honestech74 closed 3 years ago

honestech74 commented 3 years ago

Describe the bug STM32WL does not support HSE correctly as RCC clock source. Also STM32WLxx has two div option for HSE, but there is not way to select HSEDiv. I have tested on my STM32WL55CC custom board using 32MHz crystal, and it worked with HSI, but not with HSE. For the STM32CubeWL project, I was using HSEDiv = 2.

To Reproduce Steps to reproduce the behavior:

  1. Update the board dts as following. 
    &clk_hse {
// 32MHz external crystal
status = "okay";
};
&pll {
div-m = <2>;
mul-n = <6>;
div-p = <2>;
div-r = <2>;
div-q = <2>;
clocks = <&clk_hse>;
status = "okay";
};
  2. build blinky sample

Expected behavior It should blink but didn't at all. Anyway, I set the mul-n bigger than 32, it was blinky and the blinky frequency is about 3 times and can see the corrupted log. Also there is no difference between 32 and 127 of mul-n By RM0453 7.2.4 PLL, "The PLLQCLK and PLLRCLK output frequency must not exceed 48 MHz. The PLLPCLK output frequency must not exceed 62 MHz.", So it's not the right configuration.

Environment

erwango commented 3 years ago

@honestech74 Thanks for reporting that. We'll get the HSE Div2 implemented.

Though, looking to your dts configuration, Using PLLM Div = 2 and HSE Div = 1 should be equivalent to PLLM Div = 1 and HSE Div = 2 when using PLL as SYSCLK source. And this allows to acheive 48MHz SYSCLK Did you try this configuration using STM32CubeWL project ?

honestech74 commented 3 years ago

Yes, I checked it with HSE Div = 1 and PLLM Div = 2 using STM32CubeWL project and it worked. But it still didn't work with same configuration in Zephyr v2.6.99.

erwango commented 3 years ago

Yes, I checked it with HSE Div = 1 and PLLM Div = 2 using STM32CubeWL project and it worked. But it still didn't work with same configuration in Zephyr v2.6.99.

Ok, thanks for the info. This confirms there's a least something to fix here. Once done, we'll see if it gets better on your initial issue.

erwango commented 3 years ago

I have tested on my STM32WL55CC custom board using 32MHz crystal,

@honestech74, by default current code will enable TCXO, and crystal won't be used. So I guess this is the issue you're seeing here.

Would you mind checking if disabling the line below and have a try ? https://github.com/zephyrproject-rtos/zephyr/blob/1a4015f28da7cb25de0f9652a00ded17ce23d84d/drivers/clock_control/clock_stm32_ll_common.c#L498-L500

FYI, I had a try using the dts clock config you mentioned above on nucleo_wl55jc and it's working as expected

honestech74 commented 3 years ago

@erwango You are right, it works now after commented those lines. I guess there is TCXO property in SubGHz node and commented it for my custom board not having TCXO.

&subghzspi {
    status = "okay";
    lora: radio@0 {
        status = "okay";
        antenna-enable-gpios = <&gpiob 0 GPIO_ACTIVE_HIGH>;
        tx-enable-gpios = <&gpioc 13 GPIO_ACTIVE_HIGH>;
        rx-enable-gpios = <&gpioc 13 GPIO_ACTIVE_LOW>;
        // dio3-tcxo-voltage = <SX126X_DIO3_TCXO_1V7>;
        // tcxo-power-startup-delay-ms = <5>;
    };
};

I am not sure whether it can be used for TCXO or not. Maybe any Kconfig?