nrf_pwr_mgmt_run sometimes not sleeping?

RE: nrf_pwr_mgmt_run sometimes not sleeping?

agecalculator — Mon, 03 Jun 2024 08:20:46 GMT

Excellent, thanks a lot for your help.

RE: nrf_pwr_mgmt_run sometimes not sleeping?

charles_fi — Tue, 11 Apr 2023 13:12:18 GMT

The issue turned out to be us doing blocking TWI transfers (and other assorted bus transmissions) from inside the EGU2 SoftDevice handler. For whatever reason, this causes the nRF52840 to never successfully enter the sleep state again; it always instantly wakes up.

If I were starting a project from scratch, I'd probably not use any of the SD Observers and simply poll SD for events at a known stable point in my application instead. That approach seems simpler and safer, even if it means not being able to use a good chunk of the SDK observer-based code.

RE: nrf_pwr_mgmt_run sometimes not sleeping?

xonoy18882 — Tue, 11 Apr 2023 08:42:00 GMT

If you are experiencing issues with the nrf_pwr_mgmt_run function not sleeping your device as expected, there are a few potential causes to investigate.

Firstly, ensure that you have configured the power management module correctly, using the nrf_pwr_mgmt_init function. This should be called early in your application's initialization process.

Another potential cause is that some peripherals or modules may be preventing the device from entering sleep mode. Check that all peripherals are properly configured and that there are no interrupts or other events preventing the device from sleeping.

Finally, ensure that your application is correctly handling any events or tasks that may be waking the device from sleep mode. If a task is waking the device but not allowing it to return to sleep, this could be causing the issue.

By investigating these potential causes, you should be able to fnf diagnose and resolve any issues with the nrf_pwr_mgmt_run function not sleeping your device as expected.

RE: nrf_pwr_mgmt_run sometimes not sleeping?

yunaren — Wed, 02 Nov 2022 03:13:58 GMT

Great. Thanks for your answers.

lolbeans

RE: nrf_pwr_mgmt_run sometimes not sleeping?

charles_fi — Tue, 01 Nov 2022 16:22:43 GMT

Einar- Thanks so much for the deep investigation. I've replaced my sleep call with the following:

void cpu_init(void) {
  SCB->SCR &= ~SCB_SCR_SEVONPEND_Msk;
}

void cpu_sleep(void) {
  CRITICAL_REGION_ENTER();
  __set_FPSCR(__get_FPSCR() & ~0x9Fu);
  __DSB();
  NVIC_ClearPendingIRQ(FPU_IRQn);
  CRITICAL_REGION_EXIT();

  sd_app_evt_wait();
}

And it seems to be working well now. I think SEVONPEND was the culprit; I've shipped a few nRF528xx IoT products now and this was the first time I've ever tried nrf_pwr_mgmt_run().

Going back to handling the FPU IRQ errata myself and just calling sd_app_evt_wait() directly seems to be working well (again).

Thanks a bunch for your help!

Best,

Charles

RE: nrf_pwr_mgmt_run sometimes not sleeping?

Einar Thorsrud — Tue, 01 Nov 2022 12:54:20 GMT

Hi,

[quote user="charles_fi"]I don't see any examples in the nRF SDK of calling sd_nvic_ClearPendingIRQ (or manipulating the ICPR registers in general) to implement this note. Am I doing it correctly?[/quote]

That is a good question. This is only relevant for disabled interrupts (as stated in the API documentation for sd_app_evt_wait()). But that leads to something interesting. With disabling interrupt and setting SEVOPENED you would wake up on an event but the corresponding ISR is not run (as it is not enabled in the interrupt mask in the NVIC). If you have an interrupt source which is disabled in the interrupt mask it could explain what you are seeing (device keeps waking up, but no ISR is run).

[quote user="charles_fi"]I guess a deeper question I have is "why does nrf_pwr_mgmt_init set SEVONPEND?"[/quote]

I have not been able to find explicitly why this is doen in nrf_pwr_mgmt, but it makes sense in some cases. (For instance, in our FreeRTOS port we do the same for RTC the RTC to act as periodic wake-up source without needing to spend CPU cycles in a ISR doing nothing.)

[quote user="charles_fi"]

If I'm not using nrf_pwr_mgmt_init anymore, and just doing the FPU errata and WFE myself, do I need SEVONPEND? My application is running at the lowest priority, which seems relevant.

Can I simply leave SEVONPEND disabled and still just WFE? That seems simpler.

[/quote]

I don't have a full overview of your design, but in principle, yes. It should be OK to leave SEVOPENED disabled in most cases.

RE: nrf_pwr_mgmt_run sometimes not sleeping?

charles_fi — Mon, 31 Oct 2022 14:16:26 GMT

Thanks for the quick response, Einar-

I think my original table displays that no _new_ interrupts are occurring, or I'd expect to see the "main loop turns" counter match one of the "xyz_IRQn" counters, but they're off by a few orders of magnitude. My original table also displays an almost exact 1:1 matching between "main loop turns" and "sleep attempts"; I do think that my "idle" flag works, or I would expect to see many loop turns and few sleep attempts.

nrf_pwr_mgmt_run() does some tidying up and then calls sd_app_evt_wait(). The documentation for sd_app_evt_wait() says the following in a note:

"The application must ensure that the pended flag is cleared using sd_nvic_ClearPendingIRQ in order to sleep using this function. This is only necessary for disabled interrupts, as the interrupt handler will clear the pending flag automatically for enabled interrupts."

One difference between my "this seems to work" update post and my original "this sometimes doesn't work" post is that I'm doing

// Un-pend any disabled pending interrupts
NVIC->ICPR[0] = ~NVIC->ICER[0];
NVIC->ICPR[1] = ~NVIC->ICER[1];

I don't see any examples in the nRF SDK of calling sd_nvic_ClearPendingIRQ (or manipulating the ICPR registers in general) to implement this note. Am I doing it correctly?

In an earlier attempt, I un-pended all disabled interrupts while in a critical section- that made SoftDevice stop working. I'm assuming some number of SD interrupts fire between when I exit my critsec and when I hit ICPR.

I guess a deeper question I have is "why does nrf_pwr_mgmt_init set SEVONPEND?" If I'm not using nrf_pwr_mgmt_init anymore, and just doing the FPU errata and WFE myself, do I need SEVONPEND? My application is running at the lowest priority, which seems relevant.

Can I simply leave SEVONPEND disabled and still just WFE? That seems simpler.

RE: nrf_pwr_mgmt_run sometimes not sleeping?

Einar Thorsrud — Mon, 31 Oct 2022 13:29:00 GMT

Hi Charles,

[quote user=""]1. Are there any known errata in SD140 v7.0.1 that could cause this?[/quote]

No, I do not think so.

[quote user=""]2. Are there any paths in the opaque SoftDevice binary function sd_app_evt_wait that return to the user without actually doing the WFE/SEV sleep?[/quote]

No, sd_app_evt_wait() will always result in a sequence of __WFE(); __SEV(); __WFE();. After wake-up, a mask is checked to mask out any SoftDevice IRQs. If any bits are set in the ISPR that are not set, sd_app_evt_wait() returns. If not it will (conceptually) call __WFE(); __SEV(); __WFE(); again.

[quote user=""]3. Does anyone have any ideas what I can try next, or where I can look, to root-cause and fix this?[/quote]

The most obvious suspects are that either you do not clear some event(s) that cause interrupts, or simply the idle variable in your pseudo code is not correctly updates (so that it is not true when it should be or it is not volatile).

[quote user="charles_fi"]In this specific experiment below, I have also set SEVONPEND to 1, though I'm not sure what the implications are or when / why I'd want that in production.[/quote]

That should be OK I believe. However, SEVONPEND should already be set to 1, as you use the nrf_pwr_mgmt module (done when you call nrf_pwr_mgmt_init()).

RE: nrf_pwr_mgmt_run sometimes not sleeping?

charles_fi — Sat, 29 Oct 2022 13:20:18 GMT

Update-

This seems to help, but I don't know why and I'm not sure if it's safe to use when SoftDevice is active. I really don't think this counts as a "fix" yet, but it does seem like evidence that sd_app_evt_wait() has a fallthrough path where it returns without running WFE/SEV? It sure would be nice if the source code for SoftDevice was available for reading... 🙂

In this specific experiment below, I have also set SEVONPEND to 1, though I'm not sure what the implications are or when / why I'd want that in production.

void cpu_sleep(void) {
  CRITICAL_REGION_ENTER();
  __set_FPSCR(__get_FPSCR() & ~0x9Fu);
  __DSB();
  NVIC_ClearPendingIRQ(FPU_IRQn);
  __WFE();
  CRITICAL_REGION_EXIT();

  // Un-pend any disabled pending interrupts
  NVIC->ICPR[0] = ~NVIC->ICER[0];
  NVIC->ICPR[1] = ~NVIC->ICER[1];
}

Charles