cancel
Showing results for 
Search instead for 
Did you mean: 

HSE with PLL for STM32WB at 64MHZ

lastMcu
Associate II

There doesn't seem to be any project in the whole STM32CubeWB package that uses the HSE with PLL. At least I couldn't find any with a .IOC file. Most samples in the package use the MSI clock, except, of course, for the wireless projects that use HSE for better accuracy. But in all those projects that use the HSE, they use the clock directly, not through the PLL, and then they clock the main CPU at 32 MHz, not at 64 MHz.

 

Of course it is possible to modify the configuration to use the HSE with the PLL. But it is rather strange that with all the projects in the package, everyone that do use the HSE, doesn't use the PLL and chooses to configure the CPU at a lower frequency. To be honest, it makes one suspicious that it could be a problem and it might not work reliably if one try to use the HSE with the PLL.

 

Anybody has any actual experience with a wireless project using the HSE and clocking the CPU at 64 MHz through the PLL?

 

Thanks

1 ACCEPTED SOLUTION

Accepted Solutions

I can't see any potential problem in running the STM32WB with a HSE PLL frequency of 64 MHz. It should work fine.

Best Regards.

STTwo-32 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

6 REPLIES 6
Remy ISSALYS
ST Employee

Hello,

You can find BLE_HeartRate_PLL example in STM32CubeWB package witch used the PLL as system clock.

Best Regards


@Remy ISSALYS wrote:

You can find BLE_HeartRate_PLL example in STM32CubeWB package witch used the PLL as system clock.

Are you sure it uses the PLL as system clock? I can see that the PLL is configured to use HSE. But I don't see that the PLL is connected to the system clock:

 

 RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSE;
 ...
 if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)

 

As you can see, HSE is connected to the system clock directly, not through the PLL. Also, the configured flash latency would be too low for a 64 MHz clock.

Hello @lastMcu 

I suggest you take a look at this example stm32-hotspot/WB55Gimbal-6steps: An example demonstrating how to spin a gimbal motor using STM32WB55 and ST's MCSDK v6 sensorless six-step algorithm (github.com).

Best Regards.

STTwo-32

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.


@STTwo-32 wrote:

Hello @lastMcu 

I suggest you take a look at this example stm32-hotspot/WB55Gimbal-6steps: An example demonstrating how to spin a gimbal motor using STM32WB55 and ST's MCSDK v6 sensorless six-step algorithm (github.com).

Best Regards.

STTwo-32

 


Thanks STTwo-32, but as far as I can see, that sample doesn't use HSE at all. The PLL source in that sample is HSI, not HSE. HSE is not even turned on at the RCC configuration.

 

The whole point is using HSE at 64 MHz. We need HSE because an RF application requires the precision provided by an external oscillator.

 

Note that it is not too difficult to modify any of those samples to use HSE at 64 MHz. The point is that since there doesn't seem to be such a sample whatsoever in the whole firmware package, I'm wondering if there is any kind of problem running HSE with the PLL at 64 MHz. Otherwise why all the samples that do use HSE, use HSE at 32 MHz?

 

Thanks,

 

I can't see any potential problem in running the STM32WB with a HSE PLL frequency of 64 MHz. It should work fine.

Best Regards.

STTwo-32 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello,

The BLE_HeartRate_PLL example starts using HSE as system clock and then switch the system clock to PLL using SHCI_C2_SetSystemClock command (after CPU2 started). All the information regarding PLL management is described in AN5289 part 6. 

Best Regards