QN908x wakeup from PD0 leaves XTAL running

[joseraffucci]

I am running into a situation where my boards are waking up from PD0 and then begin to draw additional current (approx 1.5mA in my case).  I am not actively using the BLE stack in this case.  The stack is initialized bug any active connections are dropped and advertising is shut off.

I have narrowed it down to the controller task being called when the scheduler runs after a wakeup event.  At some point after leaving WFI and entering WFI again something is getting set that keeps the XTAL running.  I believe that this is the source of my extra current.  I can induce this by either allowing the OSC_INT interrupt to wake the system up or by enabling the LPTMR interrupt.  In either case the controller task is always woken up.  I'm guessing that it's using an RTOS timeout on a resource as part of the main loop.   I can prove that no other tasks are waking up when this occurs.  I am scoping the XTAL output on PA25.

SDK 2.2.0/bluetooth1.5.4/framework 5.6.4

I have 2 questions:

1.  What is the controller task doing that is keeping XTAL active?  Are there any race conditions or dependencies on the XTAL32K clock that could cause this?  I am using RCO32 as the low power timer source and have run the calibration prior to allowing the device to enter PD.   I ask because the timing is unpredictable and not all boards exhibit this behavior (that I can tell).

2.  Why does the OSC_INT event keep firing every 10s, even when I have no connections or advertisements active?  I am able to mitigate this issue somewhat by disabling LPTMR running and interrupting in PD and by disabling OSC_INT interrupts when in PD.  There is very little int the documentation on what this vector is for and what it does/should do.

[joseraffucci]

We are using 32Mhz XTAL and no XTAL32.  32K source is internal RCO.  PA25 shows 25Mhz clock when active.

What is happening is that after PD0 is entered, XTAL is still active.  I do not know who is keeping it active.  The only wakeup source is the BLE 10s wakeup in my test mode.  This does not occur at every wakeup.  I suspect the system is not shutting down cleanly due to race condition, possibly due to something happening in the controller task.  It is the only thing that runs when I wake up.

How can I disable BLE 10s wakeup?

[pengfei_zhen]

Hi Jose,

10s wakeup could not disable. 

Could you please share your project? So that I can try to reproduce your issue.

[joseraffucci]

I have been able to identify the origin of the wakeup but don't know what to do about it.  The issue is being caused by the PMU_CTRL0.RETENTION_EN bit that is set in the PWRLib_Init function.

When this line is in, my test fails -- XTAL does not correctly shut down after entering PD0 after a few wakeups.

When I comment this line out, my test works.  XTAL is only running during wakeup period.

I have modified the power_mode_switch example in the SDK that reliably reproduces this problem.  I have inserted a compiler warning where the line is in the example. 

I do not know if the eval boards will exhibit this behavior -- only some of our boards will fail, which makes me think there is a subtle race condition in the PMU logic.  

I am stuck at the moment as I don't have the knowledge or equipment to debug this further.  In the meantime, can you help me understand what this register is doing?  There are exactly 2 pieces of information from the code and user's manual:

 

and

Which isn't super helpful. 

Clearly not all registers are being restored cleanly or some hardware is getting turned on while I'm in PD.  I suspect it's something in the clock tree but cannot be sure yet.

[pengfei_zhen]

Hi Jose,

I think the CPU registers need to be keep retention when using Freertos, if we don't enable Clock output to GPIO, nothing wrong. While if we enable clock output to GPIO, something will prevent QN9080 enter power down.

So it is make sense that I have test this case on bare matel project before, and did not found your issue.

I will continue investigating this issue, and at the same time, I have ask for help from SW team. 

And now, as a work around, customer can disable clock output to GPIO before enter PD, and then  enable the function after exiting from PD.  Or customer can chang to barematel from freertos.

[joseraffucci]

To be clear:

• Not all of our boards are exhibiting this behavior right away.  It is quickly reproducible on the ones that do.
• I am not sure if all boards will show this behavior.  I am only working with a handful at the moment.
• The problem does not appear to be temperature related.  I have heated and cooled boards and the results are the same.
• Power to MCU is good.
• They are all from the same run and the CHIP_ID register is the same:

   

• Is is not possible to disable GPIO when in PD as it is source of wakeup for application.
• It is not possible to not use RTOS as our firmware and BLE stack will not run.
• We do not need to use BLE once we determine that PD is appropriate.  If problem is due to BLE hardware somehow we can disable if needed.

[pengfei_zhen]

I saw you attached code.

What I mean is that when using barematel, we don't need to keep CPU registers retention in PD mode.

Actually all the default barematel example in SDK, we don't keep CPU register retention in PD mode.

1.  If you comment out "SYSCON->PMU_CTRL0 |= (SYSCON_PMU_CTRL0_RETENTION_EN_MASK);"

then the issue will never reproduce?

2.  If yes, please comment out this line. I checking Connectivity Framework Reference Manual, I found that the user can disable the CPU registers retention.

3.  Even if after disable the CPU registers retention, the issue could be reproduced. 

I'm working on the issue, will keep you updated if any finding.

Thanks

[joseraffucci]

The example I provided is for helping debug.  Our application uses RTOS and must have registers preserved.

If you can reproduce this withe the retention disabled then the problem is likely in the power down/up logic in the MCU, no?  Maybe the register save/restore is affecting the timing.

[pengfei_zhen]

Hi Jose,

I have complete a testing project based on power_profiling_freertos. The modification as below:

1. Config a GPIO output:

   a.  Set to low befor enter PD,  add the gpio seeting code at the beginning of function "void BOARD_PrepareDeepSleep()"

   b. Set to high level after wakeup from PD. Add the new line at the end of function "void BOARD_WakeupRestore()"

2. Config colck output to PA25.

Test procedure:

1. Download the program to QN9080 DK.

2. Use a logic analyzer to capture clock output PIN and PD indicator PIN.

3. Press on button1 on QN9080DK, switch QN9080 power mode.

Here is a analysis of QN9080DK in advertising.

QN9080 will periodically wakeup from PD0 and send advertising packet, and then enter to PD0.

If QN9080 enter PD0, at the same time clock still output, we consider that the issue is reproduced.

Have a lot of test, but could not reproduce the issue on my side.

Could you please test following my way? Using this way, we can check if QN9080 really have called enter PD function when the issue occurred.

[joseraffucci]

1.8V does not seem to be the issue.  I bumped the voltage on the board to 2.1 and still see it.

Here are some traces.  Channel 4 is XTAL.  Channel 1 is LED (active low).

Code:

[pengfei_zhen]

Hi Jose,

I have looked into your code.

You have comment out "BOARD_BootClockRun()", which is not allowed.

And I add a while loop berfore enter power down, so that QN9080 could keep active for a longer time

After including "BOARD_BootClockRUN()",  I test it on the QN9080DK board, and the test result as below: 

Current consumption is OK, both XTAL and clock output are OK.

Still could not replicate your issue.

[joseraffucci]

As I've said repeatedly, this issue is not happening on all boards so I'm not surprised that you can't replicate it.  What would be most valuable is to find out what could be getting missed by the PMU when shutting down the MCU so we can try and come up with a possible firmware fix.

We have swapped MCU's from one of my failing boards to a QN9080DK board and the problem has followed the MCU.  We will be sending the board to you or the group in Mexico.  I am taking inventory of what lot #'s are working and which ones are not.  It is not a simple task as I can only do indirect measurements on finished boards due to our design.  It takes 6 or so hours to see the effects on the battery due to the increased current draw.

[joseraffucci]

Boot clock initialization does not make a difference..  I removed to minimize the amount of code that was being executed.  The ONLY thing that affects the behavior is the PMU_RETENTION bit.

[joseraffucci]

Are there any other registers besides CHIP_ID that I can look at to see if the MCU's all match production/lot numbers?  I have seen issues in the past with MCU variations and am beginning to wonder if this could be the problem.

[pengfei_zhen]

Could you please share your hardware schematic? 

[pengfei_zhen]

Hi Jose,

Could you please have a try at 3.0V power supply?

Your setup is different from mine. I don't have a oscilloscope.

I'm using logic analyzer, and capturing Clock output on PA25, and PD indicator PIN. I don't capture the XTAL.

I have also test at 1.8V power supply, and could not duplicate the issue too.

I have attached my test project. You can download and use it directly.

Here is the logic analyzer scope @1.8V power supply:

BTW, could you please list your requirements and descript the issue in detail in case of I miss something.

Thanks

Pengfei.

[pengfei_zhen]

Yes, there is Chip ID register.

You can also have a check on the top-side marking

[joseraffucci]

I have performed a similar test and can verify that the LED follows the expected MCU power state.  Current measurements also confirm this.

Why is advertising relevant?  My findings show that the problem is strictly related to entering/leaving PD0.

I can generate traces later today.

[joseraffucci]

One additional piece of information that may or may not be important -- We are operating MCU at 1.8V.  Power supply has been scoped and is solid.

[joseraffucci]

Please see example I provided. It is bare metal.  GPIO Clock is not enabled.  Problem is 100% reproducible when PMU register retention is enabled.

Or customer can chang to barematel from freertos.

Seriously?

[joseraffucci]

To clarify, I am able to enter and leave PD0 as expected.  This problem only occurs some time after the first PD0 but is not tied to any number of wakeup/PD pairs.  It seems to occur randomly but does occur with 100% certainty on some boards.

[james_zhang]

PengfeiZhen‌ please help on the issue, thanks.