Can I keep BLE connection alive in CPU1 STOP2 mode?

Hello,

You shall not do anything to control the CPU2 low power mode. The wireless stack running on CPU2 makes sure the lowest low power mode on CPU2 is requested depending on the use case.

Basically, you should develop you application on CPU1 in the same way as if it was a single core product (i.e you dont need to care about CPU2 for low power management).

The recommendation is to use the low power manager provided with all BLE projects and especially the implementation of stm32_lpm_if.c that use all semaphores and synchronization with CPU2 as both CPU may requires to reconfigure the system clock at the same time.

Here are some answers to your specific questions:

1/ In case you tried to control the CPU2 low power mode with its dedicated LPMS setting, you may have broken the state machine on CPU2.

2/Yes and you have nothing specific to do for this. When you have a BLE connection up and CPU1 enters Stop2, the system will enter Stop2 between connection interval and will be in RUN mode during radio event. You can check the power profile for the Heart Rate application. Between connection interval, the power consumption is in the range of 3.6us (i.e Stop2) as expected.

3/ As said above, BLE activities do not stop. The mailbox on top of IPCC is already configured to get out CPU2 from Stop2 when a command is sent from CPU1 to CPU2. There is nothing specific in the CPU1 application to make this working.

4/ Yes. Just set the low power mode you need on CPU1 depending on your application in the same way as if you were a single core product without BLE and don't worry about CPU2.

I believe the starting point is the Heart Rate application that you can use to check power profile or mechanism implemented. The Heart Rate project is the only project which is by default configured to reach the lowest power consumption.

All other projects are low power mode capable but by default, the debugger, button, gpio, traces are enabled so they are burning more power. It is all a matter of configuration in app_conf.h. ( you can make a diff with the one from the Heart Rate project)

Regards.

Hi @Christophe Arnal​ 

Thank you for your detailed answers. I have resolved the design concerns related to this.

I need your input for another issue. I am working on upgrading the wireless stack & FUS programmatically. I am NOT doing the OTA firmware upgrade but storing my new stack & FUS images in internal flash memory. The MCU that I am using is STM32WB5xxG(1M). Following are the steps I am following based on the instructions in AN5185 Rev 6.

The pre-condition is that the WS is running (which I think means FUS is running too), BLE is initialized, my custom application is running:

1. Install the new wireless stack at 0x08078000 (additional encryption added)
2. Decrypt the new wireless stack from additional encryption
3. Initiate the upgrade by using FUS commands :

• Call SHCI_C2_FUS_GetState(0); - Should I still call this if I know that my stack is running?
  • Call SHCI_C2_FUS_FwDelete();
  • Call SHCI_C2_FUS_FwUpgrade(0x08078000, 0x080C7000);

With this, I am not able to flash the new image and the error code from FUS commands is SHCI_UNKNOWN_CMD.

Is this a correct method? Is there an example other than OTA that I can follow?

Thank you,

Arshiya Tabassum

Hello,

See answer in this post:

Can I upgrade the STM32WB wireless stack & FUS in a custom application?

Best Regards