QN9080DK BLE library prevents MCU PowerDown0

cancel
Showing results for 
Search instead for 
Did you mean: 

QN9080DK BLE library prevents MCU PowerDown0

Jump to solution
345 Views
arpad_toth
Contributor II

Hello,

The "lib_ble_5-0_host_peripheral_cm4.a" library doesn't allow to enter PowerDown0 mode for the second time.

Please see attachment.

Overview:

  1. BLE init
  2. Prepare for sleep
  3. POWER_EnterPowerDown0
  4. Wakeup from sleep
  5. Prepare for sleep again    -> fails because BLE reports kPmSleep instead of kPmPowerDown0
  6. POWER_EnterPowerDown0 ->not reached
Labels (1)
  • QN

Tags (2)
0 Kudos
1 Solution
142 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello, 

Sorry for the inconveniences this might cause you, but the libraries can't be shared, also I believe the way you are implementing the changes might be intrusive to the framework as you are not following the recommendations in the documentation we provide.

Why aren't you using the PWR_ChangeDeepSleepMode API? And, are you using the PWR_AllowDeviceToSleep? I did not see any of those in your code, have you added those? If you did, how are you using them? Is your issue during the IDLE state? Is it in the advertisement? Or is in the connection? 

Have you tried using our recommended APIs and process? 

Regards, 
Estephania 

View solution in original post

0 Kudos
4 Replies
142 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello, 

I started checking your attached file there might some missing steps or necessary elements that might be intrusive to the flow of the Bluetooth LE stack. 

I will strongly recommend you to check Chapter 10 Low-Power Management of the Bluetooth® Low Energy Application Developer’s Guide as well as use as a base and follow the flow of the examples configuring those in power down mode, to be sure that you have all the elements of the process. 

Regards, 
Estephania  

0 Kudos
142 Views
arpad_toth
Contributor II

Hello,

After init the stack is hapilly able to start/stop advertisement many times.
OS_task is called continuously.
Is there a memory address I could read detailed internal state from the BLE stack?

I extracted the shutdown/wakeup process from power_profiling_bm, in there I see the following:

PWR_CheckIfDeviceCanGoToSleep
     BLE_get_sleep_mode() - kPmPowerDown0
     do PowerDown0
Shutdown
Wakeup
PWR_CheckIfDeviceCanGoToSleep
      BLE_get_sleep_mode() - kPmSleep <- mine stays here
     do WFI   <- is this necessary?
BLE_get_sleep_mode() - kPmPowerDown0  <- what make it change to this mode?
      do PowerDown0

0 Kudos
142 Views
arpad_toth
Contributor II

Hello,

I did more digging:

BLE_get_sleep_mode() -> kPmPowerDown0
enter PowerDown0
Wakeup
BLE_get_sleep_mode() -> kPmSleep
__enable_irq();
BLE_get_sleep_mode() -> kPmActive
while BLE_get_sleep_mode() -> kPmActive
       OSA_dispatch() --> ControllerTask task gets called many times, but stuck in kPmActive

in power_profiling_bm example only 2 calls to ControllerTask is needed then it changes to kPmPowerDown0, which doesnt happen in my app.

Reading some BLE stack internal states would save you a lot of debugging time.

0 Kudos
143 Views
estephania_mart
NXP TechSupport
NXP TechSupport

Hello, 

Sorry for the inconveniences this might cause you, but the libraries can't be shared, also I believe the way you are implementing the changes might be intrusive to the framework as you are not following the recommendations in the documentation we provide.

Why aren't you using the PWR_ChangeDeepSleepMode API? And, are you using the PWR_AllowDeviceToSleep? I did not see any of those in your code, have you added those? If you did, how are you using them? Is your issue during the IDLE state? Is it in the advertisement? Or is in the connection? 

Have you tried using our recommended APIs and process? 

Regards, 
Estephania 

View solution in original post

0 Kudos