Problem with sd_app_evt_wait() after sd_clock_hfclk_request()

[Remo]

Hi there

After initializing the SoftDevice S132 V6.1.0, I request the HF crystal by calling the function sd_clock_hfclk_request():

Fullscreen

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

uint32 SD_HF_crystal_start(void)

{

uint32 sd_stat;

uint32 running;

// Request the start of the HF crystal oscillator

sd_stat = sd_clock_hfclk_request();

if (sd_stat) {return sd_stat;}

// Workaround for errata 68 of nRF52832 rev. 1

QT_wait_us(HFXO_STABLE_TIME_US);

// Wait until the HF crystal has started

running = 0;

while (running == 0)

{

sd_stat = sd_clock_hfclk_is_running(&running);

if (sd_stat) {return sd_stat;}

}

return NRF_SUCCESS;

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

uint32 SD_HF_crystal_start(void)
{
   uint32 sd_stat;
   uint32 running;

   // Request the start of the HF crystal oscillator
   sd_stat = sd_clock_hfclk_request();
   if (sd_stat) {return sd_stat;}

   // Workaround for errata 68 of nRF52832 rev. 1
   QT_wait_us(HFXO_STABLE_TIME_US);

   // Wait until the HF crystal has started
   running = 0;
   while (running == 0)
   {
      sd_stat = sd_clock_hfclk_is_running(&running);
      if (sd_stat) {return sd_stat;}
   }

   return NRF_SUCCESS;
}

Later in the code, after a BLE connection has been established (nRF being in peripheral role), I'm calling sd_app_evt_wait() in a loop to save power until the connection has been terminated again.

Now, the problem occurred that the function sd_app_evt_wait() returns immediately at every call. But when I clear the SD_EVT_IRQn after the HF crystal has been started, the function sd_app_evt_wait() remains sleeping as expected.

Fullscreen

1

2

3

4

5

6

// Enable the HF crystal

sd_stat = SD_HF_crystal_start();

if (sd_stat) {return sd_stat;}

// Clear the SoftDevice event IRQ

NVIC_ClearPendingIRQ(SD_EVT_IRQn);

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   // Enable the HF crystal
   sd_stat = SD_HF_crystal_start();
   if (sd_stat) {return sd_stat;}

   // Clear the SoftDevice event IRQ
   NVIC_ClearPendingIRQ(SD_EVT_IRQn);

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? 

Many thanks in advance.

Best regards

[bjorn-spockeli]

Hi Remo, 

 

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? 

 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

[Remo]

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

[bjorn-spockeli]

Remo said:

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

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

Remo said:

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?

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

[Remo]

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?

[bjorn-spockeli]

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