BLE causes system sleep before main

[r2r0]

Describe the bug
When the BLE subsystem is enabled (CONFIG_BT=y) then system enters idle thread (sleep) before main function is invoked.

Tested on blinky sample with CONFIG_BT=y and with small code changes as described below.
main.c

...
volatile uint32_t idle_counter = 0;

void main(void)
{
        if (idle_counter > 0) {
                printk("idle_entry: %u", idle_counter);
        }
...

idle.c

...
	while (true) {
	    extern volatile uint32_t idle_counter;
	    idle_counter++;
...

Target (board) is nucleo_wb55rg.

To Reproduce
Steps to reproduce the behavior:

1. Modify blinky sample and idle.c as described above.
2. west build --board=nucleo_wb55rg
3. west flash
4. See output on console: idle_entry: 2

Expected behavior
System should not sleep before entering main or this behavior should be documented.

Impact
annoyance

Environment (please complete the following information):

• OS: Linux
• Toolchain Zephyr SDK 0.13.1
• Commit SHA: 4446272

[erwango]

It seems that this problem is not STM32 specific.
I had a try to prevent system to enter PM_STATE_SUSPEND_TO_IDLE during HCI driver init _bt_ipm_init, but this had no effect on the issue.

@jhedberg Would you mind having a look on BLE stack side?

[jhedberg]

@erwango there is no PM related code on the host side of the Bluetooth stack, so not sure what you’re requesting.

[erwango]

@erwango there is no PM related code on the host side of the Bluetooth stack, so not sure what you’re requesting.

Sure, but maybe the point is that there are sleep intervals during BLE stack initialization that let the PM subsystem going into PM state while it should prevent it (using pm_constraint_). This could also be a larger system issue, applicable to all stacks and in that case, this should be fixed directly by PM subsystem. I hope @ceolin may give directions.

[ceolin]

From the pm subsystem there is nothing preventing it from put the system to sleep. We can ensure that the system does not go to sleep before reach the main, this seems very reasonable. Though, there is a thumb rule where anyone doing an operation that the system shouldn't sleep has to set constraints.

[erwango]

Though, there is a thumb rule where anyone doing an operation that the system shouldn't sleep has to set constraints.

This seems logical but:

• would we be able to enforce that ?
• how can this be technically applied? (how a driver or a subsystem would know that main was entered yet or not. In some cases (init functions), it is simple, but in some subroutines used widely, response is not that easy.

[erwango]

@r2r0 I just had a debug session in this use case here are my observations:

• No k_sleep is done anywhere before main is reached
• When going step by step into STM32 IPM HCI driver, the issue disappear > Root cause is around this

I think what we're seeing is normal here, and not a bug.
According to @andyross:

In a technical sense yes: on a SMP system the extra CPUs will likely reach idle (each has its own idle thread obviously) before system initialization is complete and the application main() function is entered. But that's not your platform.

This is actually our case here. Well, this is not a SMP but we do have a second core (M0), which is initialized during main core boot process (as part of ipm hci driver init). During M0 initialization, main core is waiting (a semaphore to released by a message coming from M0) and then idle thread is entered. This seems actually normal to me and I don't see a specific bug to fix here.

What is strange is that I had a try to prevent to block idle entry (using pm_constraint_set around whole driver init), this had no effect. But this could be expected. @ceolin could you help clarifying this ?

[ceolin]

Hi @erwango, constraints don't prevent the system to goes idle, they prevent the system of suspending, aka going to "deep" sleep.

[erwango]

Hi @erwango, constraints don't prevent the system to goes idle, they prevent the system of suspending, aka going to "deep" sleep.

Ok, so I think there is nothing that can be done and I'd say there is nothing to fix here.
@r2r0 is it fine with you ?

[erwango]

Reopening as #41935 doesn't solve issue reported.
Though, I think that there is no issue to be solved.
Waiting @r2r0 to confirm.

[ceolin]

yep. I had removed the linkage between the pr and the issue, also removed the "fixes" from the commit message, but somehow the issue was automatically closed

[r2r0]

Ok, it is clear now to me that system behaior is correct. Thanks a lot for fast proceeding.
I wonder if it should be somehow documented - mainly in context of PM notifiers.
I.e. what is the lowest system initialization level/priority when PM notifiers can be called.
User hooks usually will need some context initialization and it will help users to know when it should be done.

[carlescufi]

I wonder if it should be somehow documented - mainly in context of PM notifiers.

@ceolin @r2r0 please open an Enhancement issue for documenting this behaviour if you want to.