Is the PMU keeping things powered on?

RE: Is the PMU keeping things powered on?

JohnL — Mon, 05 Aug 2024 22:23:10 GMT

***SOLVED*** - updating in case anybody else finds the same issue

https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev1%2FERR%2FnRF52832%2FRev1%2Flatest%2Ferr_832_new.html&cp=3_1_1_1_1

We have an earlier Rev1 HW on our PCB - I pulled the details from FICR

This from the Rev1 Errata details the increased power consumption on stopping SAADC - and this turned out to be the cause of ~470uA of additional current.

And, of course, explains why shutting the core down removed the excess current.

Been a vexing few days, but pleasing to have found it.

RE: Is the PMU keeping things powered on?

JohnL — Mon, 05 Aug 2024 21:25:23 GMT

At this point I am pretty sure anything that has ever been touched by the code is turned off, including the SD - I still cannot turn of the HFCLK (so something is keeping it awake) and it still draws ~500uA. The attempt to turn of HFCLK fails every time - we have a XTAL LFCLK but it is running on the internal RC LFCLK.

If I use the WFI() it never returns, if I use the WFE() it returns instantly but there are no pending interrupts in NVIC->ISPR so I have no idea what events it is waking on and there is no way of telling.

 // check everything
 ASSERT(nrf_sdh_is_enabled() == false); 
 ASSERT(NRF_RADIO->STATE == 0);
 ASSERT(NRF_UART0->ENABLE == 0);
 ASSERT(NRF_UARTE0->ENABLE == 0);
 ASSERT(NRF_USBD->ENABLE == 0);
 ASSERT(NRF_UARTE1->ENABLE == 0);
 ASSERT(NRF_SPI0->ENABLE == 0);
 ASSERT(NRF_SPIM0->ENABLE == 0);
 ASSERT(NRF_SPIS0->ENABLE == 0);
 ASSERT(NRF_SPI1->ENABLE == 0);
 ASSERT(NRF_SPIM1->ENABLE == 0);
 ASSERT(NRF_SPIS1->ENABLE == 0);
 ASSERT(NRF_SAADC->ENABLE == 0);
 ASSERT(NRF_PWM0->ENABLE == 0);
 ASSERT(NRF_PDM->ENABLE == 0);
 ASSERT(NRF_PWM1->ENABLE == 0);
 ASSERT(NRF_PWM2->ENABLE == 0);
 ASSERT(NRF_SPI2->ENABLE == 0);
 ASSERT(NRF_SPIM2->ENABLE == 0);
 ASSERT(NRF_SPIS2->ENABLE == 0);
 ASSERT(NRF_I2S->ENABLE == 0);
 ASSERT(NRF_PWM3->ENABLE == 0);
 ASSERT(NRF_SPIM3->ENABLE == 0);
 ASSERT(NRF_QDEC->ENABLE == 0);
 ASSERT(NRF_COMP->ENABLE == 0);
 ASSERT(NRF_LPCOMP->ENABLE == 0);
 ASSERT(NRF_TWI1->ENABLE == 0);
 ASSERT(NRF_TWIM1->ENABLE == 0);
 ASSERT(NRF_TWIS1->ENABLE == 0);
 ASSERT(NRF_TWI0->ENABLE == 0);
 ASSERT(NRF_TWIM0->ENABLE == 0);
 ASSERT(NRF_TWIS0->ENABLE == 0);

 ASSERT(NRF_RTC0->EVTENCLR == 0);
 ASSERT(NRF_RTC1->EVTENCLR == 0);
 ASSERT(NRF_RTC2->EVTENCLR == 0);
 ASSERT(NRF_TIMER0->SHORTS == 0);
 ASSERT(NRF_TIMER0->INTENSET == 0);
 ASSERT(NRF_TIMER1->SHORTS == 0);
 ASSERT(NRF_TIMER1->INTENSET == 0);
 ASSERT(NRF_TIMER2->SHORTS == 0);
 ASSERT(NRF_TIMER2->INTENSET == 0);
 ASSERT(NRF_TIMER3->SHORTS == 0);
 ASSERT(NRF_TIMER3->INTENSET == 0);
 ASSERT(NRF_TIMER4->SHORTS == 0);
 ASSERT(NRF_TIMER4->INTENSET == 0); 

 ASSERT(NRF_PPI->TASKS_CHG[0].EN == 0);
 ASSERT(NRF_PPI->TASKS_CHG[1].EN == 0);
 ASSERT(NRF_PPI->TASKS_CHG[2].EN == 0);
 ASSERT(NRF_PPI->TASKS_CHG[3].EN == 0);
 ASSERT(NRF_PPI->TASKS_CHG[4].EN == 0);
 ASSERT(NRF_PPI->TASKS_CHG[5].EN == 0);
 ASSERT(NRF_PPI->CHEN == 0);

 ASSERT(NRF_MWU->REGIONEN == 0); 

 for (int i=0; i<=7; i++)
 {
 ASSERT(NRF_GPIOTE->EVENTS_IN[i] == 0);
 ASSERT(NRF_GPIOTE->CONFIG[i] == 0);
 }
 ASSERT(NRF_GPIOTE->INTENCLR == 0);

 for (int i=0; i<16; i++)
 {
 ASSERT(NRF_EGU0->EVENTS_TRIGGERED[i] == 0);
 ASSERT(NRF_EGU1->EVENTS_TRIGGERED[i] == 0);
 ASSERT(NRF_EGU2->EVENTS_TRIGGERED[i] == 0);
 ASSERT(NRF_EGU3->EVENTS_TRIGGERED[i] == 0);
 ASSERT(NRF_EGU4->EVENTS_TRIGGERED[i] == 0);
 ASSERT(NRF_EGU5->EVENTS_TRIGGERED[i] == 0);
 }
 ASSERT(NRF_EGU0->INTEN==0);
 ASSERT(NRF_EGU1->INTEN==0);
 ASSERT(NRF_EGU2->INTEN==0);
 ASSERT(NRF_EGU3->INTEN==0);
 ASSERT(NRF_EGU4->INTEN==0);
 ASSERT(NRF_EGU5->INTEN==0); 

 ASSERT(NRF_MWU->REGIONEN == 0);

 // for some reason the HFCLK is still sometimes active after SD shutdown, if so explicitly kill it
 uint32_t temp = NRF_CLOCK->HFCLKSTAT;

 if (temp & 0x10000) // this is HFCLK bit in HFCLKSTAT
 {
 NRF_CLOCK->TASKS_HFCLKSTOP = 1;
 }

 while (1) 
 {
#if !defined(DISABLE_WATCHDOG)
 watchdog_feed(); // needed because the supervisor has been stopped by this point
#endif 
 nrf_pwr_mgmt_run(); 
 //__WFI();
 }

RE: Is the PMU keeping things powered on?

JohnL — Mon, 05 Aug 2024 16:17:57 GMT

On the second point - the FPU handling

We already override the weak FPU_IRQHandler like this -

/// @brief FPU interrupt handler.
/// @details Just clears interrupt and returns. Without this, power consumption is increased as
/// the FPU prevents CPU sleep.
extern "C" void FPU_IRQHandler(void)
{
 static constexpr uint32_t c_FPU_EXCEPTION_MASK = 0x0000009FUL;
 // cppcheck-suppress cstyleCast
 uint32_t *fpscr = (uint32_t *)(FPU->FPCAR + 0x40U);
 (void)__get_FPSCR();

 *fpscr = *fpscr & ~(c_FPU_EXCEPTION_MASK);
}

But in this case the this happens even with the interrupts disabled and using a __WFI(), I did just check them in the code - but i don't think is the likely cause.

I am now going to manually check all the peripherals to check they are disabled.

RE: Is the PMU keeping things powered on?

JohnL — Mon, 05 Aug 2024 16:08:47 GMT

"Is there any possible that you are testing this in the BLE with the softdevice being flashed before the application and softdevice enabled?"

My apologies, can you explain this clearer? I am not sure exactly what you mean

The softdevice is flashed at the start of the ROM, and the application has a bootloader as well. We start the bootloader if there is no application present, or if the application specifically requests it (the bootloader also uses BLE for data transfer).

RE: Is the PMU keeping things powered on?

JohnL — Mon, 05 Aug 2024 16:04:33 GMT

For the first point - the SD is disabled, I have already traced through the nrf_pwr_mgmnt_run() and seen that the check

 if (nrf_sdh_is_enabled())
 {
 ret_code_t ret_code = sd_app_evt_wait();

means that sd_app_evt_wait() is not being called.

For the second point I'll have a play with the debugger now.

If that fails then I will look at all the peripheral registers one by one to see if any of them are still on - that might take a while.

Thank you for your help/advice - I'll try and find more information.

RE: Is the PMU keeping things powered on?

Susheel Nuguru — Mon, 05 Aug 2024 15:01:47 GMT

[quote user=""]So, to recap, if the power down code is called after all the HW is initialized we see the expect 6uA (with either a WFI() loop or a complete core shutdown) - if we call it after the application has been running we see 1.4mA on the WFI() loop and 6uA on the shutdown. Therefore I assume the issue is something still running on the device.[/quote]

Hmm, Is there any possible that you are testing this in the BLE with the softdevice being flashed before the application and softdevice enabled?

We have seen issues with the application trying to go to low power mode when using the sd_app_evt_wait.
We have seen some issues in the FPU handling in a way that the application tries to control everything manually but forgets to handle the FPU exception which can keep the core awake due to the unhandled pending bit set in the NVIC register. This can be fixed by clearing the pending bits in the FPU status register and the pending bit in the interrupt register
```
__set_FPSCR(__get_FPSCR()  & ~(FPU_EXCEPTION_MASK));
(void) __get_FPSCR();
NVIC_ClearPendingIRQ(FPU_IRQn);
```

If the above two things are not the reason you see this difference, then it is worth exploring the reason by trying to debug this. One manual approach I can suggest to do is to see all the peripheral registers if they have actually disabled.

RE: Is the PMU keeping things powered on?

JohnL — Mon, 05 Aug 2024 11:30:45 GMT

I expect an reply about how are we shutting down the SD,
so this is the relevant code extract

disconnectAll(); // stop current BLE comms or advertising
sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
if (nrf_sdh_is_enabled())
{
ret_code_t err_code = nrf_sdh_disable_request();
APP_ERROR_CHECK(err_code);
while (nrf_sdh_is_enabled())
    {
      OSS_SleepMillisecs(10);
    }
}

It is certainly passing through all this without any issues. Shortly after this we shutodwn the scheduler and the interupts.