Before starting advertising, we want to write some configuration information to NVM. In order to write to NVM, we first call sd_flash_page_erase and wait for the response from the softDevice. While waiting, we call sd_app_evt_wait. We expect to receive the SWI2 interrupt indicating that the erase is complete.
On most of our boards, this happens correctly, within ~50ms, and we have no subsequent problem. However, on some boards the SWI2 interrupt doesn’t fire until after the NRF is woken up by an external interrupt from a different processor, several seconds later. Our conclusion is that we are asleep (NRF_POWER_MODE_LOWPWR). We know we have interrupts configured correctly because it works fine on some boards, so how could we be stuck in sleep?
In debugging this issue, we also noticed that the RTC1 interrupt stops firing during the time the NRF is asleep. We expect the processor to wake up every 125ms and service RTC1, but this interrupt also doesn’t fire until we get an external wakeup from the host processor.
Another confusing element is that we made a seemingly unrelated change that seems to “fix” both problems above. In our initialization sequence, we were calling sd_radio_notification_cfg_set very early on, before writing to NVM. When we moved the call to happen AFTER writing to NVM, the above problems went away. But considering that we’re writing to NVM before starting advertising, I can’t understand how this change would have any effect.
How can radio notifications affect whether the RTC1 interrupt fires or whether the NRF gets stuck in sleep?
