Achieving Lowest Power Mode with a persistent BLE Connection

The best way to manage this for now is to stay in STOP2 mode where both CPU are stopped but the BLE connection is not lost.

Now the constraint comes from the BLE specifications that set the maximum connection interval duration to 4s.

So this means having 7 intermediate connection events with no data exchanged (1TX,1RX empty packet) in between 2 connections with real data transfers. But no new advertising and scanning phase as the connection interval would remain and ensure both devices would awake at the same time.

The other way you are looking for is to enter the standby mode. But in that case the connection is lost and the device would have to reinitialize the BLE stack, reactivate the RF part, start advertising with a potential new request from the central client about services and characteristics. All this would be quite power consuming. This would be the best choice for a device requiring a communication once a day. For a communication every 32s, I think the best choice is the STOP2 mode.

I am working on a similar project, where the battery power has to be consumed. I am using STOP2 mode for both CPUs. However, I am losing the BLE connection in this mode as well.

However, this is just a small part of my application. I am also, de-initializing the COMP, RTC,RNG,TSC and GPIOs before entering low power mode & re-initializing them at exit. I am guessing the re-initializing of CPU, AHB and APB bus clocks and configuring the SYSCLKSource, HCLK, PCLK1 and PCLK2 clocks dividers at exit is causing the BLE connection to break. Can you please give me more insight on where to look to debug this issue.

@Remi QUINTIN​ Also can you elaborate what you mean by the below statements in your previous answer:

So this means having 7 intermediate connection events with no data exchanged (1TX,1RX empty packet) in between 2 connections with real data transfers. But no new advertising and scanning phase as the connection interval would remain and ensure both devices would awake at the same time.

The first use case was requiring one effective data exchange every 32 seconds.

The BLE specifications set the maximum connection interval duration to 4s.

This would means at least 8 connection events of which seven would have no data exchange, which is not possible.

The only to implement such configuration is to use the Conn_Latency parameter of the HCI_LE_CREATE_CONNECTION function (see AN5270). This specifies the slave latency for the connection in number of connection events = the number of intermediate expected connections that would lead to no data exchange without loosing the connection. If set to 7, this means that after one data exchange, there would be 7 intermediate connections events that would not lead to data exchange => 4 + 7x4 = 32s before a new data exchange would happen again.

Hope my explanation is clear.