STM32WB09: Cannot build BLE project

[s215477]

I cannot build a simple BLE project using the newest version of STM32CUBEIDE (1.16.1) for the STM32WB09KE.

Steps taken:
Create new project for the STM32WB09KE.
Enable all dependencies needed for RADIO, RADIO_TIMER and STM32_BLE, and enabled those.

When trying to build the project after generating code at this stage, i get an error for "fatal error: stm32wb0x_ll_rng.h: No such file or directory".

This can be resolved by enabling the RTC in the device configuration tool.

When trying to build now, i get he following warning, and error:

C:/ST/STM32CubeIDE_1.16.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.12.3.rel1.win32_1.0.200.202406191623/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:/ST/STM32CubeIDE_1.16.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.12.3.rel1.win32_1.0.200.202406191623/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/thumb/v6-m/nofp/crtn.o: missing .note.GNU-stack section implies executable stack

C:/ST/STM32CubeIDE_1.16.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.12.3.rel1.win32_1.0.200.202406191623/tools/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld.exe: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

I cannot seem to find a way to resolve this error, but i am able to build the project if i add "-z noexecstack" to properties -> c/c++ build -> settings -> MCU/MPU GCC Linker -> Other flags.

Now the project will build, but if i try to upload this to a stm32wb09KE nucleo board, the code gets stuck in the MX_RADIO_TIMER_Init function, at 

/* Wait to be sure that the Radio Timer is active */

while(LL_RADIO_TIMER_GetAbsoluteTime(WAKEUP) < 0x10);

So it seems like the radio timer is never initialized.

If i try to build the example "BLE_HeartRate" that goes with the STM32WB09 nucleo board, i can upload the project perfectly fine, and the device shows up in the BLE toolbox app for smartphone.
I am unable to figure out why i cannot make a project that works myself. What am i missing?

[STTwo-32]

Hello @s215477 

Could you please try to follow the recommendations of the AN5977 that can guide you to build a working app (specially chapter 5). Also, you can refer to one of our Examples and changes so it can suit to your use case.

Best Regards.

STTwo-32

[s215477]

Hello STTwo-32, and thank you for your reply.

The application note you referred to provides alot of insight, thank you for that, i had not seen that before.

After reading the note and trying to build a project with it as my guide, i still get the same warning as previously described, "missing .note.GNU-stack section implies executable stack" followed by the error. I still dont know what causes this.

When bypassing the error with the "-z noexecstack", i still get stuck in waiting for the radio timer to initialize, bummer.

If i try modify the BLE_HeartRate example, it seems like minor changes can make the build fail at the radio timer initialization, but i guess i just have to tinker with it some more untill i find out what im doing wrong.

Another issue im facing is when trying to run the BLE_HeartRate example on my own pcb design. It fails to initialize the PLL64M clock (used in the RC64MPLL MUX), as it times out while waiting for the RC64MPLL is ready. Modifying the clock configuration to use the HSE for the system clock mux works just fine, and i can get the example running on my pcb with this configuration. Any ideas as to what can cause the RC64MPLL to not get ready?

[s215477]

It seems i have some clock issues resulting in inaccurate timings. This is most likely the cause of PLL64M not working, and i will have to resolve that issue first.

EDIT: It seems like the HSI RC clock source is way off.

When outputting the HSI as masterclock (with 32 divider) i meassure 2.14 MHz on one of my pcb's, and 2.12 MHz on another one. When measureing on the nucleo board i get 2MHz clean as expected (all meassured with the same build and equipment). I would assume these were factory calibrated, and  6-7% deviation from the expected output seems way off. I guess i need to recalibrate them somehow.