On STM32WB55CG, after sending "RX_start 1" to coprocessor CM4 threads starts to respond significantly slower. Can this issue be caused by stm32wb5x_Phy_802_15_4_fw.bin itself?

[Gennadii_Votiov]

We have human interface board based on STM32WB55CG with planned possibility to communicated with other nodes via ZigBee. Now we have to pass the RF certification for which specific driver communicating with coprocessor was implemented. Most of commands sent to CM0+ running stm32wb5x_Phy_802_15_4_fw.bin are executed without any issues, but after sending "RX_start 1" UI and other threads start to respond with significant delay (e.g. UI scrolling works like 3x times slower). This behaviour continues even if send "RX_stop" or "InitLLD" to CM0+ core. Note that there is no CM0+ response printing (like it is done via UART in PHY CLI sample), driver dealing with coprocessor only sends commands and parses response.

What can cause such a behaviour? Is it possible to configure IPCC or stm32wb5x_Phy_802_15_4_fw itself to avoid this side effect?

[Lubos KOUDELKA]

First idea, what could be impacted on CPU1 by CPU2 are shared resources. Could you please check your clock setting and verify intended setting and frequencies are valid also after RX_start 1 or other commands where you see troubles?

Is CPU1 using any other shared peripheral, for which it would need to wait?