Shutting down BLE support

[zephyrbot]

Reported by Geoff Gustafson:

Sorry if there's already been a request for this, I couldn't find it.

Use case 1: I'd hope it would be possible to have a bt_disable function? For a single application, the use could be to be able to shut down the radio and everything and only occasionally turn it on when a user interacts with the device, or for a nightly sync or something. It seems that could save a lot of power?

In ZJS, we have an off-the-beaten path reason. We support loading different JavaScript apps sequentially with our "ashell" environment. So we prefer to cleanly release all resources / hardware we connected to in one application before starting the next. If one app used BT and the next didn't, we'd like to turn it off, and then turn it back on again if needed for another app. This is useful for development purposes.

Maybe this is nuts and we should just reboot in this case. :) I guess obviously it would add overhead.

(Imported from Jira ZEP-1741)

Use case 2: I'm trying to find a way to turn off/disable bt functionality(i.e. like bt_disbale) and restart it later on, but it looks like no such of API has been provided. Any hints will be appreciated.

To Reproduce Steps to reproduce the behavior:

Call bt_enable Turn off hci controller Power on hci controller Trying to enable and use bt again See error In our case, we have a host and a controller, both of them are running zephyr with HCI H:4 and we want to cut off power of controller to save power sometime, then enable it again when needed. Then we found that we can't use any bt functionalities after re-powered HCI controller.

[dhananjaygj]

There is also a scenario where this might be useful. I am currently facing a scenario where connected peer continuously NACKs at some point due to compatibility problems. If we send too many packets within a connection interval this can occur on some chipsets. If we again access the gatt_notify then it blocks forever since the last PDU is still being retried. So for error scenarios like this BLE stack reset option might be useful.

[jhedberg]

@dhananjaygj disabling Bluetooth completely sounds a bit overkill for something like that. In the absence of a timeout, wouldn't just disconnecting the problematic connection be enough? For that we already have an API: bt_conn_disconnect().

[baw-serafin]

As far as I understood @jhedberg this should be handled by zephyr itself at least for nordic chips. If there is no scan job or connection the subsystem should be deactivated. (That's what I understood at least)

[jhedberg]

@baw-serafin yes, that's what I've understood as well. A bt_disable() API would be mostly beneficial for platforms where the HCI transport itself consumes power even when the controller and host are otherwise completely idle.

[amitrajrd]

This may be a repeat reporting (or request).

As @jhedberg says, and as the time and applications have moved on towards more possibilities, a bt_disable() seems helpful.

In the simplest case of "advertising without connection" (bt_le_adv_start(BT_LE_ADV_NCONN, <>, <>, <>);), I suggest a workaround for developers - use "bt_le_adv_stop()" to stop advertisement, wherever required as per application needs. I have seen a a considerable power consumption difference, in this case. However, i am not sure if not advertising is equivalent to something like bt_disable(). Mostly, they are not same, conceptually.

A bt_disable() will actually help a lot when the need of bt_enable is over and the application still needs to run other things OR mcu needs to sleep (be idle) for a long time.

[jhedberg]

In the simplest case of "advertising without connection" (bt_le_adv_start(BT_LE_ADV_NCONN, <>, <>, <>);), I suggest a workaround for developers - use "bt_le_adv_stop()" to stop advertisement, wherever required as per application needs.

@amitrajrd why do you call that a workaround? A workaround for what? The appropriate way to stop advertising is bt_le_adv_stop().

have seen a a considerable power consumption difference, in this case.

Of course. Any activity, such as advertising, that you ask the controller to perform will consume power. That's unavoidable.

However, i am not sure if not advertising is equivalent to something like bt_disable(). Mostly, they are not same, conceptually.

I'm not sure what you're trying to say with that above. Yes, they are not the same, however I'm still struggling to understand the use case for which you think a bt_disable() is needed?

[marshed18]

I am in need of this function too is it out there?

[codingspirit]

I'm coming from #20651

@jhedberg One of possible scenario to use bt_disable is HCI controller was powered off by hardware for better power saving. I believe this kind of scenario is quite common in power sensitive IoT devices since it only need BT connection in a short window, but most of time BT can be switched off.

Please let me know if I can help on this.

[joerchan]

@codingspirit That is a good point. In your setup which HCI driver do you use? ~~Do you have multi-chip solution where host is on one chip and the controller on the other? In which case which HCI driver do you use? Or do you have a combined build with host and controller. Using the zephyr software controller?~~ Nevermind I see you use H4. :)

[M1cha]

anonther usecase would be to allow the user to disable bluetooth on devices where that functionality is not essential(like you do on smartphones). If you just stop advertising, other devices could still connect if they know your MAC.

[joerchan]

If you just stop advertising, other devices could still connect if they know your MAC.

That should not be possible, atleast not with LE connections, is this a BR/EDR problem?

[Trubochkin]

I not understand... I develop device on nrf52840, and when I call bt_le_adv_start(...) the current consumption is equal about 500-700uA, and when I call bt_le_adv_stop() I have current about 5mA. I expected that the current will be less, but no... ((( Who know how to resolve this problem?

[jhedberg]

If you just stop advertising, other devices could still connect if they know your MAC. That should not be possible, atleast not with LE connections, is this a BR/EDR problem?

BR/EDR has the concept of page- and inquiry scanning. If both of those are disabled then you're neither connectable nor discoverable. So same thing - simply knowing the MAC doesn't allow you to connect through LE or BR/EDR unless the device is actually configured to receive connections (page scanning with BR/EDR or connectable advertising with LE)

[erwango]

@jhedberg, @joerchan For my information, are there any blockers on this issue?

On some platforms, bt_disable sounds like the best approach to properly achieve shutdown. For instance, on STM32 we've implemented https://github.com/zephyrproject-rtos/zephyr/pull/38980, but we're reaching limits of the approach (https://github.com/zephyrproject-rtos/zephyr/issues/41944). On STM32WB, A bt_disable functionality would allow to properly shutdown the M0 core before completely shutting down the main core.

[joerchan]

I am not aware of any blockers.

[jhedberg]

@erwango I'm also not aware of any blockers. As long as there's a good use case, I'm fine with adding a close() callback to HCI drivers and a bt_disable() public API.

[erwango]

Thanks, I'll take a stab at this.

[jori-nordic]

Seems to be addressed by #42409 . Should we close this @carlescufi ?

[jhedberg]

Closing since #42409 took care of this.