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]

It appears that we will be sending the board directly to you.  I'm not sure when or if it will get to you so here is a short video of the problem and the full project I am using.

[joseraffucci]

While we're waiting for the board to get to you, can you send me the registers that the PMU_RETENTION bit touches?  I'd like to try to manually set/restore them to see if that helps.

[pengfei_zhen]

Hi Jose,

Based on my founding that ble project demo project could not reproduce the issue. I have spent serival days on it but still don't fix it yet. As a work around, I think you can follow the BLE demo project to manage the power mode.

I can help you add power manager on your BLE project,  could you please provide your BLE project to me?

[joseraffucci]

The power profiling project enables advertising.  Does your test work with it disabled?

I am not able to provide source code to my project.  If you want so simulate the use case, set up a timer to turn off advertisements some time after boot (10 seconds is probably a good number).  I am willing to bet that you will be able to reproduce the problem then.

[pengfei_zhen]

Yes, I have enabled advertising on my test.

As your advice, I will do the test as below:

1. Start advertising automatically after boot. And set a 10 seconds timer at the same time.

2. Stop advertising in the 10 seconds timer callback.

3. waitting for the issue reproduce.

[joseraffucci]

While you're waiting, can you find someone who can tell me exactly what the PMU_RETENTION register does? 

Not what the single sentence in the user's manual says but what it does at a register level.

[pengfei_zhen]

I have complete the test as you descripted, but did not dulplicate the issue.

Could you please provide a BLE demo project that could reproduce this issue, and I will work on that project.

I'm checking PMU_RETENTION register internal, nothing more than UM get.

So, why you keep the CPU registers retention in PD? Why not disable it as a workaround.

[joseraffucci]

So, why you keep the CPU registers retention in PD? Why not disable it as a workaround.

Because RTOS!

#if (USE_RTOS)
    //enable CPU registers retention in power down
    SYSCON->PMU_CTRL0 |= (SYSCON_PMU_CTRL0_RETENTION_EN_MASK);
#endif

...which is why I have been repeatedly asking what that bit actually does.  I can save/restore registers manually.... IF I know the ones that are affected!

[pengfei_zhen]

Hi Jose,

I found something on QN9080 silicon development bug tracking.

And there are 2 workarond for this issue:

So please set PA22 to GPIO input mode with pulldown in BOARD_InitPins(), and keep PA22 disconnect on your board. 

I have tried this way, and QN9080 works well, the issue could not be duplicate.

In another way, I'm checking with software team if we can disable CPU register retention in freertos projects.

Thanks.

[arpad_toth]

Dear Phengfei,

And you didn't find it important to mention this bug in the errata???

We wasted months going down the PD0 path with retention.

NXP is a joke.

[pengfei_zhen]

Sorry for that, will update it in the errata.

[arpad_toth]

When do you plan to fix the issue? If not in the BLE library then in the silicon.

Are there other issues missing from the errata?

Developers don't have access to your internal bug tracker, we only see the errata, everything else just causes sleepless nights for us.

[pengfei_zhen]

Actually， In our SDK we have avoid this issue in all BLE demo projects. You can have a check on our SDK BLE demo project, you can not duplicate the issue. I have suggest before that following our SDK to  manage power which will avoid this issue.  

I'm not the designer of QN9080, I just help to investigate the issue.

[arpad_toth]

I strongly followed the power_mode_switch demo, but it doesn't use retention mode, which we need.

[joseraffucci]

Pengfei,

All of my testing has been successful so far.  I think this workaround is enough to satisfy our immediate needs.  It would be great if we could do something that didn't require modifying our use of PA22 but it is good enough for now.

Thanks for digging into the database.  That was a great find!

[joseraffucci]

Pengfei,

Apologies for the delay.  I have been busy testing and fixing the last bugs in the firmware for our delivery.  Our boards arrive from the manufacturer this week.

This is yielding promising results on my board.  I will have to think about how to manage it for our project.  We use PA22 as a wakeup interrupt from a sensor.

It is active low.  :smileysad:

As far as the BLE power logic is concerned --

I am using your framework to control the power modes from the idle task.  I did not have time to implement tickless idle in the rtos.  When I started this project that code did not exist. 

The only real difference is that I added an extra rule for PD so I could prevent it if my tasks are busy:

    if( deepsleep_isallowed() && PWR_CheckIfDeviceCanGoToSleep() )
    {
        /* Enter Low Power */
        wakeupReason = PWR_EnterLowPower();

That, and restoring the vector pointer.  That bug is still in the 2.2.1 SDK.  See my other thread for a fix.

[pengfei_zhen]

Ok, got it.

Actually, I have mentioned before that you can disable CPU registers retention in PD even if you are using RTOS, I have discussed this with software team.

Or you can have a try as below:

//Before enter power down mode, please check if ble module allowed to enter power dowm.

if(BLE_get_sleep_mode() < kPmPowerDown0)
{
   // you can print out some logs here

   // return to run freetos.
}
else
{
      //enter power down mode here
}  

I don't have your source code, I want to know where/when will qn9080 enter power down in your source? In idle task?

Another question is that does QN9080 enter power down during advertising event or connection event?

As you know, in our SDK BLE examples, QN9080 will always enter power down if there is no CPU loading, for example the time duration between 2 davertising. 

I'm thinking about that you are managing the power mode manually, only after advertising stopped, then you enter power down, is it?

Thanks

[joseraffucci]

I have been able to achieve a modest power reduction by manually shutting off XTAL when entering PD and turning it back on when waking up.  On our board it translates to roughly 400uA.  There is still an additional milliamp to account for.

I noticed this in the code:

I can not find anything about this errata.  It's not in the sheet for the QN9080 on the web site.  Is it something that's not published or is it a holdover from another chip?

[pengfei_zhen]

Hi,

I have just complete anther test @1.8V power supply. And using a scope to probe XTAL.

Channel 1 is LED(PA31) active high.

Channel 2 is XTAL.

Channel 3 is Clock output(PA25).

Attached my test code.

I have also captured the current consumption using power analyzer. And the timing sequence is very match with the clock capture sequence.

 

Please download my test code, and test using my test code.

[pengfei_zhen]

Hi Jose,

There are 2 XTAL on QN9080DK, 32MHz and 32.768KHz. We can use internal 32K RCO to replace of external 32KHz XTAL.

It's normal for 32M XTAL keep running after wakeup. 32M XTAL will provides system clock when CPU running.

What's the frequency of output on PA25 in your side?

1. Once wakeup, XTAL will keep high speed XTAL running.

2. QN9080 BLE IP has a timer, the timer will wakeup the system periodly. The wakeup interval is 10s by default in SDK.