STM32WB LSE vs LSI2

[LSpad.1]

Hi!

I am using a STM32WB for a bluetooth very low cost application. Right now i have ported in my board with STM32WB50CGU the example P2P server and the Android application ST BLE Sensor connect and communicate with it. I am using the LSE clock (32.768kHz).

Now, according with datasheet of the STM32WB50CG, paragraph 3.10, point 3, the LSI2 can be used by the RF subsystem, so, in order to reduce the cost of the board, i tryed it.

I can see the advertising with the mobile app (it appears in the research), but unfortunately i cannot connect and exchange data with the board. I attach the cube clock configuration.

Am i doing something wrong? How can i solve this problem?

Thank you in advance

Best regards

Lorenzo

[Remi QUINTIN]

LSI2 is not stable enough to guarantee a stable connection. This is mentioned in the errata sheet.

Please try with the LSI1 internal clock.

[LSpad.1]

Hi Remi,

thank you for the answer!

We tryed also LSI1, unfortunately with the same result.

Do you think that is possible that the external crystal is mandatory for the BLE application?

Thank you in advance

Lorenzo

[Remi QUINTIN]

LSI1 does not need any external crystal as it is using its own internal oscillator.

LSE needs one of course.

[LSpad.1]

Yes, of course.

But do you think that is possible that LSE is mandatory for the BLE application? Because with the LSI1 and LSI2 configured from Cube it is not working.

Thank you in advance.

[Remi QUINTIN]

In fact LSI clock exceeds 500 ppm maximum frequency deviation specified in the Bluetooth® Low Energy standard for low-speed clock.

So indeed LSE oscillator is mandatory to clock the Bluetooth® peripheral.

[RPowe.9.306]

Hi, I would like clarification on the 32.768kHz LSE. On the project that I am working on, they have made a board without 32.768kHz LSE, as they were led to believe it wasn't necessary. I read a few posts that said ti was essential, but after much panicking, I found an example that used RFWakeUpClockSelection set to HSE/1024, (PeriphClkInitStruct.RFWakeUpClockSelection = RCC_RFWKPCLKSOURCE_HSE_DIV1024;). I've tried this and it works! Not being a BLE expert, I need to ask whether HSE/1024 is an acceptable solution for production? If it isn't, why? If 32.768kHz is needed, why? Sorry if this is obvious to a BLE expert, but it isn't to me.

Thanks

[LSpad.1]

Hi,

i am using this solution for production. But for RTC (necessary switched on to compile WPAN with CubeMX) i think you have to use the LSE, or I think it does not work anymore the HW_TimerServer. If you try to use it in these conditions, randomically the application stops in some while in the RTC interrupt routine forever. I think you can disable the timerserver via code if you do not use it, but be careful with regenerations.

[Christophe Arnal]

​Hello,

You may use  HSE/1024 as RF clock source as you did and the product will be working perfectly but in that case, you shall not enter deeper than Sleep mode ( No Stop Mode) to keep HSE running. If you get into Stop Mode, HSE is switched OFF during RF Idle and you will lose your BLE timing.

LSE is used as low power clock when in low power mode in order to keep the BLE timing and wakeup on time to synch with the remote.

Regards.

[Christophe Arnal · Accepted solution]

​Hello,

By default, we are using LSE as source clock for RTC because anyway, LSE is mandatory to be there for BLE.

However, it is possible to use LSI/LSI2 or HSE/1024 for RTC with no probleme but

• There is no added value to use LSI/LSI2 versus LSE
• When you use HSE/1024, you will not be able to enter lower than Sleep mode to keep the BLE Timing

Note that the HW_TimerServer is not a mandatory component for BLE. It is used only for the application as we need some timeout to be running in low power mode to take some actions. It is perfectly possible to remove it and use your own timer server if you have one based on either RTC or LPTimer.

There is nothing related to BLE but only to the application.

Now, as long as we are providing a HW_TimerServer that does the job and which has been running fine for several years, I would recommend to just keep it.

Regards.