Time become incorrect when enable bluetooth of board nucleo_wba52cg.

[2024markLuo]

Is your feature request related to a problem? Please describe.
I use board nucleo_wba52cg, When I call bt_enable(), then all k_msleep() become not correct.
for example: k_msleep(2000), it was supposed to delay for 2 seconds, but in fact it delayed for 12 seconds.

Describe the solution you'd like
After enabling bluetooth on board nucleo_wba52cg, k_msleep can be accurate and systick can also be accurate.

Describe alternatives you've considered

Additional context

[github-actions[bot]]

Hi @2024markLuo! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[carlescufi]

@erwango any ideas?

[asm5878]

Dear @2024markLuo,
Just for info I have made a test with nucleo_wba55cg board and peripheral_hr.
I have used a GPIO to test a k_sleep behavior and it was as expected.

Here a snippet of while loop:

	while (1) {
		k_sleep(K_SECONDS(1));
		gpio_pin_configure_dt(&tp1, GPIO_OUTPUT_ACTIVE);
		/* Heartrate measurements simulation */
		hrs_notify();
		/* Battery level simulation */
		bas_notify();
		gpio_pin_set_dt(&tp1, 0);
		gpio_pin_configure_dt(&tp1, GPIO_DISCONNECTED);
	}

Right now I haven't in my hands any nucleo_wba52cg to do the same test.
Maybe a mismatch between nucleo_wba52cg and nucleo_wba55cg clock configuration?

Thanks,
Alex

[erwango]

@2024markLuo Did you try to use clock configuration from nucleo_wba55 to nucleo_wba52?

[erwango]

Note that currently BLE support on nucleo_wba52 is not enabled in tree, so this is not technically a "bug".

Moving to discussion.

[stefanb2]

I just stumbled over this issue with the nucleo_wba55cg board when SYSCLK != 16 MHz: as soon as bt_enable() is called the system clock starts to diverge from the wall clock. Here are the wall clock times I observed for 10 seconds on the system clock for various SYSCLK settings:

SYSCLK [MHZ]	Observed Wall Clock [s]
10	6
16	10
20	12
40	24
80	48
100	60

The relevant clock tree changes from my nucleo_wba55cg.overlay devicetree file:

/*
 * reconfigure clock tree
 *
 * NOTE: 10, 16, 20, 32, 40, 64, 80 or 100
 */
#define __SYSCLK_MHZ 100

&clk_hse { // HSE == 32 MHz oscillator
  /delete-property/ hse-div2;
};

&pll {
  status = "okay";
  clocks = <&clk_hse>;

  // VCO configuration
#if   (__SYSCLK_MHZ == 100)
  div-m  = < 8>;
  mul-n  = <50>;
  // -> fVCO = HSE * N / M = 32*50/8 = 200 MHz
#elif (__SYSCLK_MHZ == 16) || (__SYSCLK_MHZ == 32) || (__SYSCLK_MHZ == 64)
  div-m  = < 2>;
  mul-n  = < 8>;
  // -> fVCO = HSE * N / M = 32* 8/2 = 128 MHz
#else // 10, 20, 40 or 80 MHz
  div-m  = < 2>;
  mul-n  = <10>;
  // -> fVCO = HSE * N / M = 32*10/2 = 160 MHz
#endif

  // PLLCLK = fVCO / R
#if   (__SYSCLK_MHZ == 10)
  div-q  = <16>;
  div-r  = <16>;
#elif (__SYSCLK_MHZ == 16) || (__SYSCLK_MHZ == 20)
  div-q  = < 8>;
  div-r  = < 8>;
#elif (__SYSCLK_MHZ == 32) || (__SYSCLK_MHZ == 40)
  div-q  = < 4>;
  div-r  = < 4>;
#else // 64, 80 or 100 MHz
  div-q  = < 2>;
  div-r  = < 2>;
#endif
};

&rcc {
  clocks          = <&pll>;
  ahb-prescaler   = <1>;
  // output -> SYSCLK
  clock-frequency = <DT_FREQ_M(__SYSCLK_MHZ)>;
#if   (__SYSCLK_MHZ / 1) <= 32
  ahb5-prescaler  = <1>;
#elif (__SYSCLK_MHZ / 2) <= 32
  ahb5-prescaler  = <2>;
#else
  ahb5-prescaler  = <4>;
#endif
  apb1-prescaler  = <1>;
  apb2-prescaler  = <1>;
  apb7-prescaler  = <1>;
};

I compiled my test applications against the Zephyr manifest branches v4.1.0, v4.1-branch & main. The result is always the same.

[stefanb2]

I just stumbled over this issue with the nucleo_wba55cg board when SYSCLK != 16 MHz: as soon as bt_enable() is called ...

I can also confirm the issue with a STM32WBA65I-DK1 (using board nucleo_wba65ri on Zephyr main branch).

So I assume this is a generic stm32wbaxx Bluetooth stack related issue. Maybe something related to the blob libraries that are linked in?

To the powers-that-be (@erwango, @asm5878, @carlescufi): can this conversation be converted back to an issue? Or do you want me to open a new issue?

[erwango]

Would be better to open a new issue and fill the dedicated bug template.

[stefanb2]

I think I'm finally zeroing in on the root cause:

[00:00:00.000,000] <inf> bt: BEFORE BT: running on board nucleo_wba55cg with CPU frequency: 100 MHz
[00:00:00.006,000] <inf> bt_hci_core: HCI transport: BT IPM                                                                              
[00:00:00.007,000] <inf> bt_hci_core: Identity: 00:80:E1:XX:XX:XX (public)                                                               
[00:00:00.007,000] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x8014, manufacturer 0x0030                                       
[00:00:00.007,000] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x6014                                                              
[00:00:00.007,000] <inf> bt: AFTER  BT: running on board nucleo_wba55cg with CPU frequency: 16 MHz                                       

I see two options:

• because of technical reasons the stm32wbaxx BT stack (blobs) only works with system clock @ 16 MHz. The BT initialization therefore switches the system clock to 16 MHz, but forgets to update the other parts required for Zephyr. I.e. Zephyr OS still thinks the system runs @ 100 MHz.
• there are no technical reasons for the stm32wbaxx BT stack (blobs) to switch the system clock to 16 MHz, but it incorrectly does so.

[stefanb2]

This also explains why on the GPIO output pin that I configured to MCO = SYSCLK / 2 I measured 8 MHz with the oscilloscope. So the system is really running @ 16 MHz when BT gets enabled.

[stefanb2]

FYI: created new issue #91409