QN9080dk take around 600uA current after 30-40sec in PD0

[bhaveshshah]

Hello,

My end requirement is to run QN9080 in low power down mode PD0 with very high BLE advertising interval (~20 seconds).

I am using the QN9080dk board and testing on "qn908xcdk_wireless_examples_bluetooth_power_profiling_freertos" of SDK version 2.2.0. 

When I test the example without any change, in power down mode PD0 by pressing button-1 it takes around ~2.30 uA, which is as expected.

But it starts taking very high current around ~600uA after 30 to 40 seconds.

It happens every time. 

I modified the code a bit and make controller go to PD0 mode directly after power up. There also it takes ~2.3 uA for first 30 to 40 seconds after that it starts taking high current arouond ~600uA. 

I haven't started BLE advertising yet.

Now I debugged  into the code and came to know this case dose not take higher current more than expected current when I comment out the " OSC_EN as interrupt and wakeup source" from "PWRLib_Init()" function,

But it is require to use BLE and low power timers. 

And another thing I found that QN9080 board starts taking higher current only after when there is any pending "OSC_IRQn" interrupt. 

In attachment there are some screen shots of current consumption which describe the behavior mentioned above.

screen-shot 1 to 4 are screenshot of controller in PD0 mode without BLE
screen-shot 5 and 6 are from unchanged sdk example "qn908xcdk_wireless_examples_bluetooth_power_profiling_freertos" in PD0 with BLE advertisement mode

Can you guys please help me finding the reason behind this extra current?

[estephania_mart]

Hello, 

Could you please help me with the version of the SDK you are currently using? The 2.2 you mention it's regarding the drivers but and it's helpful but I would need as well the version of the Bluetooth LE, you can check about it in the release notes of the device. 

Could you please try using the latest one in the MCUXpresso builder? Also, could you please try removing the JP11 jumper in case you are not using the G-Sensor ? 

Regards, 

Estephania 

[joseraffucci]

I am seeing something similar.  I can go into PD0 and can see low current numbers as expected.  After a while, the current pops up and the MCU appears to be sleeping and not in PD0 where it should be. 

I've narrowed things down to an event that's occurring approximately every 13s.  I'm pretty sure that it's the OSC_IRQn event as that's what the wakeup source shows when I connect to the target after the high power state is reached on my target board.  I suspect that the stack is not getting down cleanly and something is sticking around keeping a timer going.  My application requires BLE to be completely disabled when I go into low power.  I disconnect any active connections and disable advertising.  Is there anything else that needs to be done?  I feel like something is missing.

I am using SDK 2.2.0 / bluetooth_1.5.4 / framework_5.6.4

I never saw this on the previous SDK I was using ( SDK 2.2.0 / bluetooth_1.5.3 / framework_5.6.3) but I have made changes to our board since then.  The biggest one being that I am now using the internal oscillator as the low power clock instead of an external digital clock input.  I don't know if that's relevant or not.

What debugger was used to create the power traces?  I need one of those!

[joseraffucci]

I spent some more time on this and have a little bit more info...

The MCU is definitely in PD0 and not sleeping as I had originally thought.  I verified this by turning on an LED when entering sleep and turning it off after the WFI instruction.  I get a brief flash every 13s or so but it does not stay on.

This means that the problem is in the state of the MCU during DS0.

I was able to get some favorable results after poking around and finally figuring out how to disable the OSC_INTn wakeup signal.

It is in PWRLib_Init():

By disabling I was able to prevent it from waking me up and getting stuck in the high power state.  I think I can get away with this in my application since I only use BLE when I have external power via USB and thus never need to PD0 with it active.

It would be nice to know why the interrupt handler is not cleaning up after itself!