Why sd_app_evt_wait() is short time sleep.

[MaSo]

Thank you for viewing my question.

I think sd_app_evt_wait() doesnt  work in my project because current consumption is high.

I am executing idle_state_handle() within the main loop. I have confirmed that sd_app_evt_wait() is being executed based on the fact that the program stops when I set a breakpoint at sd_app_evt_wait() inside nrf_pwr_mgmt.

The issue is that the function immediately following sd_app_evt_wait() is being executed frequently. Since sd_app_evt_wait() puts the soft device to sleep until an event occurs, it is strange to immediately execute the function on the next line.

① What could be the cause of not entering a proper sleep (very short sleep) duration?

② If the frequent occurrence of soft device events is the cause, please tell me how to identify those events.

 

[Einar Thorsrud]

Hi,

When sd_app_evt_wait() is called a few things happen, but effectively it ends up in WFE, which puts the CPU to sleep, waiting for an even (which again is similar to WFI). Any event or interrupt will wake up the CPU, and if it is an interrupt that should only be handled by the SoftDevice, that will be handled and the CPU go back to sleep without sd_app_evt_wait() returning. However, for any other events, sd_app_evt_wait() will return so that the application can process them.

The key point here is any event/interrupt. It does not have to be from the SoftDevice at all. Perhaps you have enabled interrupts for something that happens frequently? Or if you are doing some low-level stuff yourself, perhaps you are not clearing an event so that you get the interrupt repeatedly? I would first consider your application and try to think of likely suspects, and perhaps comment out the configuration and use of those to see if that is the cause of the unexpected interrupts. Or perhaps add logging in your event handlers. 

[MaSo]

Thank you for your reply.

I don't know what specific interrupt is occurring frequently. I am currently investigating it.

By the process of clearing events, are you referring to NVIC_ClearPendingIRQ? If so, since it is located within nrf_pwr_mgmt_run, I believe it is being cleared properly. If sd_app_evt_wait() is executed and there are no events or interrupts, will "d" be printed with the following code?

sd_app_evt_wait();

printf("d");

[Einar Thorsrud]

Hi,

Regarding clearing interrupts there are many different interrupt sources. The ones used by the SoftDevice, that will handle. And if you use SDK drivers for peripherals, that will also handle clearing of interrupts for you. But if you made your own drivers or access some peripheral at the register level, you have to think about it yourself. So I just wanted to mention it as that is one typical reason for sd_app_evt_wait() always returning immediately.

A more likely explanation could be that you have interrupts ocuring and being cleared properly, but happening more frequently than you have considered or that there is some other issue. 

But others could be simply that you get interrupts that you have forgot/not thought about. Is it so that sd_app_evt_wait() return immediately always, or is there a different pattern?

With the code here, "d" will not be printed if there are no interrupts (including no SoftDevice events). But unless you do absolutely nothing, interrupts will happen quite ofte in a real application that for instance use the radio or other peripherals.

[MaSo]

Thank you.

I have added logging outputs to all handler functions, and except for the timer handler, they are not occurring frequently. Can application timer events, like the one attached, cause sleep disturbances?

[Einar Thorsrud]

I am not sure what you mean by a sleep disturbance, but every time an app_timer times out and runs, the CPU will wake up to process it (from an RTC interrupt). This is how it should be, though. As long as you call sd_app_evt_wait() in your main loop and don't do a lot of other stuff there, the CPU will go back to sleep again. This is how low-power applications are normally designed using the nRF5 SDK with SoftDevice.