Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

Remo — Thu, 19 Mar 2020 09:31:27 GMT

Hi. This function simply waits for the stabilization time of the used crystal before it is checked if the crystal is running.

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

Justin — Wed, 11 Mar 2020 20:52:20 GMT

Hi Remo, May I know how did you take care of Errata 68?

What does // Workaround for errata 68 of nRF52832 rev. 1
QT_wait_us(HFXO_STABLE_TIME_US); function do in your code?

Any input would be greatly useful.

Thanks,

Justin

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

Remo — Thu, 21 Nov 2019 12:33:26 GMT

Hi Bjørn

Ah yes, I see. I should have read the documentation for sd_app_evt_wait() more precisely. My bad. Thank you very much for your help.

Best regards

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

bjorn-spockeli — Wed, 20 Nov 2019 18:30:34 GMT

Hi Remo,

looking at the sd_app_evt_wait() documentation I see that the following is stated:

In order to wake up from disabled interrupts, the SEVONPEND flag has to be set in the Cortex-M MCU's System Control Register (SCR), CMSIS_SCB. In that case, when a disabled interrupt gets pended, this function will return to the application's main thread.

in addition to the following

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.

So in short your hunch was correct, you need to clear the pending interrupt prior to going to sleep.

Best regards

Bjørn

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

Remo — Tue, 19 Nov 2019 14:56:04 GMT

Yes, that's right. We are calling these functions in a loop.

Yes, the pending flag for the SD_EVT_IRQn is set although the interrupt has been disabled. E.g. after the HFCLK is requested by calling sd_clock_hfclk_request(), the system event NRF_EVT_HFCLKSTARTED is returned and the pending flag for SD_EVT_IRQn is set. Is this an unexpected behavior?

Since we have not cleared the pending flag, the nRF woke up immediately after entering System ON low power mode. Is the correct flow after waking up from ON mode to fetch the occurred BLE and system events, clear the pending flag and enter ON mode again?

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

bjorn-spockeli — Tue, 19 Nov 2019 14:16:07 GMT

[quote user="Remosennhauser"]The functions sd_ble_evt_get() and sd_evt_get() return both the status NRF_ERROR_NOT_FOUND.[/quote]

Ok, so there are no events ready to be pulled.

[quote user="Remosennhauser"]I think I may have found the problem. When the SD_EVT_IRQn is enabled, the pending flag is cleared automatically when the SD_EVT_IRQHandler is entered, right?[/quote]

Ah ok, so you ve called sd_nvic_DisableIRQ(SD_EVT_IRQn) and are then just calling sd_ble_evt_get() and sd_evt_get() in a loop? Yes, the pending interrupt should be cleared upon entering the SD_EVT_IRQHandler. But are you then getting a pending SD_EVT_IRQn interrupt after you have disabled it?

Best regards

Bjørn

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

Remo — Tue, 19 Nov 2019 08:38:13 GMT

Hi Bjørn

The functions sd_ble_evt_get() and sd_evt_get() return both the status NRF_ERROR_NOT_FOUND.

I think I may have found the problem. When the SD_EVT_IRQn is enabled, the pending flag is cleared automatically when the SD_EVT_IRQHandler is entered, right?

But we have disabled the SD_EVT_IRQn and use the functions sd_ble_evt_get() and sd_evt_get() in polling mode. In that case, I assume that the pending flag is not cleared automatically when waking up from sd_app_evt_wait() and we have to do this ourselves. Is that correct?

Best regards

RE: Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

bjorn-spockeli — Fri, 15 Nov 2019 16:50:30 GMT

Hi Remo,

[quote user=""]I've read that sd_app_evt_wait() returns immediately when an event is pending, but I would have expected that the nRF enters the low power mode at the next call of this function. Did I get this wrong? Why does starting the HF crystal prevent the nRF from entering System ON low power mode? Do you know this behavior? [/quote]

I agree that having the HFCLK running should not prevent the nRF from going to System ON: Low power mode. HOwever, since there is a SoftDevice event being generated, then it would be interesing to know which event this is. Could you place a breakpoint in the ble_event_handler for the SoftDevice that is registerd with NRF_SDH_BLE_OBSERVER as this should be called when a SD event is generated and look at the (p_ble_evt->header.evt_id when you enter the handler?

Best regards

Bjørn