BLE advertisnig and power save mode

[harelTur]

We have a issue with non-working BLE advertisement after exit from Sleep mode.

Our procedures of enter to and exit from sleep mode looks more or less like that:

// turn on powersave mode (enter to sleep mode)

wiced_wlan_connectivity_deinit();                     // WIFI module deinitialization

wiced_gpio_init( WIFI_EN, INPUT_HIGH_IMPEDANCE );     // WIFI module power off (LDO disable)

wiced_platform_mcu_enable_powersave();             // enable MCU sleep mode

// here we have very nice power consumption, about 500uA

// device sleep

// device wakeup

// turn off powersave mode (exit from sleep mode)

wiced_platform_mcu_disable_powersave();               // disable MCU sleep mode

wiced_gpio_init( WIFI_EN, OUTPUT_PUSH_PULL );         // WIFI module power on (LDO enable)

wiced_gpio_output_high ( WIFI_EN );

wiced_wlan_connectivity_init( );                      // WIFI module initialization

// enable BLE advertisement after exit from sleep mode

wiced_bt_start_advertisements( BTM_BLE_ADVERT_UNDIRECTED_HIGH, 0, NULL );

Deinitialization WLAN connectivity only (without turning off WiFi power cause high power consumption, above 10mA).

Turning OFF WiFi RF power (by external LDO) decrease power consumption below 500uA which is expected.

Reintialization everything in a clear way, together with turning ON WiFi RF works well until start BLE advertisement.

Starting BLE advertisement causes continuous periodic (every 8.5s) receiving BLE_ENABLE_EVT events from bluetooth stack.

And advertisement doesn't work, we are not able to see any advertisement packets.

We definitely would like to turning off/on WiFi power by external LDO, because it gives us additional 1mA of power savings in compare to powersave only without WiFi deinitialization.

What could be a reason for this behaviour?

Are our enter/exit sleep mode procedures correct?

[BragadeeshV]

Hi @harelTur ,

Can you please give us details of your setup? What is the host and the combo chip you are using? Is it a custom hardware or any Eval board?

Please let us know which WICED SDK version you are using.

[harelTur]

Hi 

I use sdk 6.6

Chip :  Laird Connectivity Sterling™-EWB base on Cypress’s CYW4343W (inside the MCU ofST Micro STM32F412 Cortex M4 MCU).

We check it on our board(not eval board)

[BragadeeshV]

Hi @harelTur ,

Can you share the HCI logs when the issue occurs? Could you please clarify if you are referring to BTM_ENABLED_EVT? If yes, what is the value of p_event_data->enabled.status when it is getting called. If possible, you can try to enable low power in the hello sensor app and see if works correctly in your hw setup. 

Also please refer our WICED low power app note for reference

https://community.infineon.com/t5/Public-Archive/WICED-Development-System-Powersave-Application-Note...

[marcinbor85]

tnx. good point.

Yes, its a BTM_ENABLE_EVT.

I checked the status. After first BLE Enable (before first power save mode on) its 0.

When the issue appears, the status is 2:

In documentation, we can read that "2" means WICED_TIMEOUT.

[BragadeeshV]

Hi @harelTur , @marcinbor85 ,

Thanks for the update. Could you please get us the HCI logs to debug this issue further?

[marcinbor85]

I would like to get some HCI logs, but I don't know how to get them. Can you give us some tips about it?

[BragadeeshV]

Hi @harelTur ,

Add the following line to the application makefile (.mk) to enable BT SPY logs.

GLOBAL_DEFINES += ENABLE_BT_PROTOCOL_TRACES

[marcinbor85]

00:00:16.947000 --
00:00:16.949000 --
00:00:16.951000 SENT Command to HCI. Name: HCI_LE_Read_Buffer_Size (Hex Code: 0x2002 Param Len: 0) Ctrl(0)
00:00:16.961000 --
00:00:16.965000 --
00:00:16.966000 RCVD Event from HCI. Name: HCI_Command_Complete (Hex Code: 0x0e Param Len: 7) Ctrl(0)
00:00:16.976000 Parameters
00:00:16.978000 Num HCI Cmd Packets : 1 (0x01)
00:00:16.985000 Cmd Code : 0x2002 (HCI_LE_Read_Buffer_Size)
00:00:16.993000 Status : Success (0x00)
00:00:17.000000 Data Packet Length : 251 (0x00fb)
00:00:17.006000 Number of Data Packet : 8 (0x08)
00:00:17.013000 --
00:00:17.015000 --
00:00:17.016000 SENT Command to HCI. Name: HCI_LE_Read_Local_Feature_Supported (Hex Code: 0x2003 Param Len: 0) Ctrl(0)
00:00:17.027000 --
00:00:17.031000 --
00:00:17.033000 RCVD Event from HCI. Name: HCI_Command_Complete (Hex Code: 0x0e Param Len: 12) Ctrl(0)
00:00:17.043000 Parameters
00:00:17.045000 Num HCI Cmd Packets : 1 (0x01)
00:00:17.052000 Cmd Code : 0x2003 (HCI_LE_Read_Local_Feature_Supported)
00:00:17.061000 Status : Success (0x00)
00:00:17.068000 00
00:00:17.070000 : LE Encryption
00:00:17.076000 : Connection Parameters Request Procedure
00:00:17.085000 : Extended Reject Indication
00:00:17.093000 : Slave-initiated Features Exchange
00:00:17.101000 --
00:00:17.103000 --
00:00:17.105000 SENT Command to HCI. Name: HCI_LE_Set_Event_Mask (Hex Code: 0x2001 Param Len: 😎 Ctrl(0)
00:00:17.115000 Parameters
00:00:17.118000 ff
00:00:17.120000 --
BLE Enabled: 0

0235 00:00:17.134 [Debug|SB2 | 209] ======> powersave_on

...

<EVERYTHING IS OK HERE SO FAR, PROBLEM IS AFTER EXIT FROM POWER SAVE AND START ADVERTISE>

...

0299 00:00:37.015 [Debug|SB2 | 227] ======> powersave_off
0300 00:00:37.020 [Debug|WIFI |1082] ======> WIFI_API_PowerTurnOn

Initialising NetX v5.12
Creating Packet pools
IOCTL failed
WLAN MAC Address : C0:EE:40:72:EE:C9
WLAN Firmware : wl0: Jun 18 2020 08:48:22 version 7.45.98.102 (r726187 CY) FWID 01-36dd36be
WLAN CLM : API: 12.2 Data: 9.10.39 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2020-06-18 08:36:02

...

00:00:37.729000 --
00:00:37.731000 SENT Command to HCI. Name: HCI_LE_Write_Advertising_Data (Hex Code: 0x2008 Param Len: 32) Ctrl(0)
00:00:37.742000 Parameters
00:00:37.744000 Data Length : 24 (0x18)
00:00:37.751000 61
00:00:37.753000 00
00:00:37.755000 --
0304 00:00:37.757 [Debug|BLE | 300] --> BLE advertising data set. err = 0
BTM_BLE_ADVERT_STATE_CHANGED_EVT : 3
0305 00:00:37.767 [Debug|BLE | 304] --> BLE started advertising. err = 0
0306 00:00:37.774 [Debug|BLE | 311] --> BLE adv timer started. err = 0

...

BLE Enabled: 2
00:00:46.358000 --

00:00:46.365000 --
00:00:46.365000 SENT Command to HCI. Name: HCI_LE_Set_Scan_Response (Hex Code: 0x2009 Param Len: 32) Ctrl(0)
00:00:46.367000 SENT Command to HCI. Name: HCI_Reset (Hex Code: 0x0c03 Param Len: 0) Ctrl(0)
00:00:46.377000 Parameters
00:00:46.386000 --
00:00:46.389000 Data Length : 27 (0x1b)
00:00:46.397000 00
00:00:46.399000 00
00:00:46.401000 --

...

00:00:50.757000 --
00:00:50.758000 SENT Command to HCI. Name: HCI_Reset (Hex Code: 0x0c03 Param Len: 0) Ctrl(0)
00:00:50.767000 --
00:00:54.757000 --
00:00:54.759000 SENT Command to HCI. Name: HCI_Reset (Hex Code: 0x0c03 Param Len: 0) Ctrl(0)
00:00:54.767000 --

[BaRu_3629256]

@BragadeeshV
I am trying to enable BLE HCI debug on my platform as well, but I don't seem to be getting anything when adding the mentioned define. Should this flag enable output on STDOUT (serial port), or is this a different type of logging mechanism?

I was under the assumption that the BT library would need to be recompiled for this to take effect. Any advise would be great.

-Barron

[BragadeeshV]

Hi @BaRu_3629256 ,

Yes, it is expected to put the output to the std OUT (such as tera term etc). Please create a new thread if you are still facing issues.

[BragadeeshV]

Hi @marcinbor85 ,

Thanks for the reply. Looks like there is some issue in the HCI communication itself due to sleep mode. Can you share with us a stripped down version of your project that will help us reproduce the issue at our end?

Also, did you take care of the BT sleep portion before entering MCU sleep mode. ie did you check the status of  HOST_WAKE pin before entering sleep mode (wiced_bt_dev_allow_host_sleep) . See the implementation of BT sleep mode in here (WICED-Studio-6.6\43xxx_Wi-Fi\apps\snip\bluetooth\ble_hello_sensor\ble_hello_sensor.c))

[marcinbor85]

Thanks for the "wiced_bt_dev_allow_host_sleep" suggestion.

I checked it and this function always return FALSE, even when the app works fine.

Additional, I cannot found the source code of wiced_bt_dev_allow_host_sleep to my platform. So probably it is linked with some static library. I assume that if the function returns FALSE, then the implementation from wiced_hci_bt is not valid...

Additionally, i try to find the GPIO number where the BT_HOST_WAKE is connected on the STM32F412 side.

Unfortunately there is no info about in anywhere. Do You have more details about it?

[BragadeeshV]

Hi @marcinbor85 , I don't find this information in the schematics as well. Can you check with the vendor LAIRD if they can provide the pin no.? 

Can you check if you are receiving BTM_LPM_STATE_LOW_POWER event? This means that  BT device wake up pin is deasserted and you are ready to enter low power mode in the module side (4343) and the host side (STM) can also enter sleep since it has nothing to send.  

Also, can you check what is the status of wiced_bt_dev_get_low_power_mode()? Can you try enabling low power of the device by using wiced_bt_dev_set_low_power_mode(enable)?  This API will enable low power mode in the combo device. After this, can you see if  wiced_bt_dev_allow_host_sleep is returning true? wiced_bt_dev_allow_host_sleep will return false if wiced_bt_dev_set_low_power_mode is disabled.

[marcinbor85]

Thanks for extensive reply and suggestions.

So some facts. Summary of investigation...

1. Indeed, wiced_bt_dev_get_low_power_mode returned "0" so thats why wiced_bt_dev_allow_host_sleep return always false. this is correct according to Your description.

2. Even with disabled low power, I got the BTM_LPM_STATE_LOW_POWER events normally. I using this event to turn on sleep mode.

3. After turning on low power by call wiced_bt_dev_set_low_power_mode(true), indeed wiced_bt_dev_allow_host_sleep starts to return "true" sometimes, so we have got correct behaviour of this function.

4. Turning on low power mode by wiced_bt_dev_set_low_power_mode doesnt have any impact on BTM_LPM_STATE_LOW_POWER events. They still occure in the same moments.

5. After the BLE Enable status return 2 (original still unresolved issue), the BTM_LPM_STATE_LOW_POWER is reported every few seconds.

[BragadeeshV]

Hi @marcinbor85 ,

Thanks for the test. Is the issue reproducible even when you enter low power mode for host after checking the status of wiced_bt_dev_allow_host_sleep ()?

Turning on low power mode by wiced_bt_dev_set_low_power_mode doesnt have any impact on BTM_LPM_STATE_LOW_POWER events. They still occure in the same moments.

->BTM_LPM_STATE_LOW_POWER this indicates that the BT_DEV_WAKE pin has been deasserted and the combo controller is safe to go to sleep. In other words, it also means that the host has nothing to send to the controller and host can be put to sleep after checking the status of the BT_HOST_WAKE pin. That is why this event occurs whether or not you enable low power mode in the controller (combo chip).