SoftDevice does 26ms of work inside first call to sd_app_evt_wait()

[charles]

nRF52832_XXAA, S132 v5.0.1, SDK 14.0.0

We enable SoftDevice via nrf_sdh_enable_request(). We immediately assert nrf_sdh_is_enabled() so we know it worked. On the first call to sd_app_evt_wait() we see SoftDevice take control of the CPU for 26ms. We have not started advertising or done any BLE work, the device is silent.

In certain boot conditions, this is fine and we don't care, SD can do what it wants. In other boot conditions, this 26ms work happens while we're doing open-loop battery measurement and powering the device off of a tiny capacitor. SD's mystery work immediately overwhelms this cap and the measurement aborts.

The code looks almost exactly like this:

nrf_sdh_enable_request();
volatile bool done = false;
while (!done) {
  sd_app_evt_wait();
}

Questions:

1. What is SD doing?

2. How do we know when SD will do work when we sleep?

3. Is there any API for us to test that SD is done with whatever its 26msec work is?

4. Will this work ever take more or less time than 26msec?

We need to know when it's safe to sleep for 125msec with no SD activity, or we can't boot correctly.

(Note that we used to enable SD after doing all of this work, but that led to a race when initializing the LFCLK so we enable SD very early now).

[charles]

Update:

We now do something like this:

APP_TIMER_DEF(t);

bool triggered = false;

void timer_callback() {
  triggered = true;
}

nrf_sdh_enable_request();
app_timer_init();
app_timer_create(&t, APP_TIMER_MODE_SINGLE_SHOT, timer_callback);
while (!triggered) {
  sd_app_evt_wait();
}

(this is pseudocode but you get the idea. i forgot to add the call to app_timer_start with 50msec but this website is so painfully slow that i'm not going back to edit it again)

And we always see this 26ms CPU activity here, so by the time we need complete CPU silence for the open-loop PMIC measurement, SoftDevice appears to not have anything to do.

This is a very dangerous solution, though, since we can't audit the SoftDevice code and the API doesn't seem to expose whether SoftDevice has anything that it wants to do. 50msec seems like enough, but who knows, maybe it could take longer sometimes?

So: please tell us exactly what S132 v5.0.1 is doing here, how long it could possibly be working, and whether there's any other work SoftDevice could possibly do here. Ideally we'd have an API, or an event that we'd get, that tells us that softdevice is out of work to do and has no pending timers. Note that this is all happening long before we start BLE advertising, so it's confusing that SD is doing anything at all.

[Edvin]

charles said:

(this is pseudocode but you get the idea. i forgot to add the call to app_timer_start with 50msec but this website is so painfully slow that i'm not going back to edit it again)

 Trust me, I am painfully aware, and we are working on solving this.

I will ask our softdevice team, but I still don't understand exactly where you are measureing. Is it only the nrf_sdh_enable_request() you are measureing, or the whole snippet you have there, including creating the timer, starting it and waiting for the callback and so on?

Also, I don't really see the issue. After nrf_sdh_enable_request, what is it that you can't do? 

[charles]

When I call sd_app_evt_wait() on line 13, SoftDevice is taking over the CPU and doing work for 26msec. This happens once, the very first time I call sd_app_evt_wait() after enabling SoftDevice.

I need to control that, or have an API to learn what SoftDevice needs to do or for how long, or at the very least get a normative answer from Nordic about what the longest amount of time SoftDevice can take while doing this.

[Edvin]

And what is the problem with this CPU activity. I assume it is only preparing the sleep functionality. You don't have to wait for this to finish, do you?