Is it possible to run at 64 MHz in RF application? (STM32WB55)

[azzurri]

Hi, I am trying to set a 64 MHz max frecuency for my RF application (STM32WB55). To do so, I switch from default MSI to HSE with PLL. The System Core Clock updates well to 64 MHz.

However, when I start the MAC layer and RF subsystem on CPU2 by calling SHCI_C2_MAC_802_15_4_Init(), the SystemCoreClock goes down to 32 MHz.

Is there any way to avoid that decrease in frecuency?

Thank you.

[Remi QUINTIN]

​Unfortunately not as all the calculations done in the RF stack is based on the assumption that the RF part is clocked at 32MHz.

[Remi QUINTIN]

​Just checking again, it is in fact possible to set the clock frequency to 64 MHz for the M4 core and use a divider by 2tp clock the M0+ core at 32 MHz.

Regarding your case, the point is when a STM32 exits from STOP mode, the clock configuration is not completely restored and should be set up again.

The M4 has to do it.

[azzurri]

Hi @Remi QUINTIN​ ​ Thank you for the update. However, I am not using the STOP mode in my application. My problem is that when I use the M0+ (eg: every time I send or receive data), the SysClkSource automatically changes from PLL (64 MHz) to HSE (32 MHz). Consecuently, my clock configuration gets messed up.

¿Is there any way to avoid that automatic change? Thanks again.

[Remi QUINTIN]

​ The only condition for the CM0+ to force the change of the source clock of the sysclock is the selection of the HSI internal clock for that source. HSI48 MHz cannot be divided to support the 32MHz clock required for the CM0+ to support the RF activity. So at its wakeup, the CM0+ change the source clock from HSI48 MHz to HSE32 MHz.

In your case, I don’t see any reason for such change as you are using HSE + PLL.

Are you using  the SEM4 semaphore in your application? This semaphore is used to prevent a race in between the 2 cores when existing from stop mode. If you use it, it may delude the M0+ core and lead him to think the M4 core is exiting from STOP mode, forcing this change.

I will check with the 802.15.4 team if the function you are calling is not too low in the layers. You may have to call a zigbee or thread function to keep the control of the source clock.

[Remi QUINTIN]

Could you also let me know which CubeWB FW version you are using? and also the name of the RF stack (.bin)?

[Remi QUINTIN]

It seems to be a known issue for the stm32wb5x_Mac_802_15_4_fw.bin binary.

A fix will be included in the next CubeWB FW v1.11: No modification of the RCC_CFGR register value when the user wants to use PLL for CM4 64MHz.

[azzurri]

Thank you for the triple update. We will be expecting that new version then.