QN9080DK BLE library prevents MCU PowerDown0

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

QN9080DK BLE library prevents MCU PowerDown0

ソリューションへジャンプ
1,286件の閲覧回数
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
ラベル(1)
  • QN

タグ(2)
0 件の賞賛
返信
1 解決策
1,083件の閲覧回数
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 

元の投稿で解決策を見る

0 件の賞賛
返信
4 返答(返信)
1,083件の閲覧回数
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 件の賞賛
返信
1,083件の閲覧回数
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 件の賞賛
返信
1,083件の閲覧回数
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 件の賞賛
返信
1,084件の閲覧回数
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 

0 件の賞賛
返信