Softdevice assert (id:0x1 pc:1089e info:0x0)

[Sami-Pekka Mähönen]

Our product uses non-connectable/undirected advertising, where advertisement packets are sent every 1 minute for 500ms time. For that we are using FreeRTOS timers to start/stop advertisement.The problem is that randomly either right after the advertisement is started or during the advertisement, app_erro_fault_handler() gets called leading to the system reset (id: 0x1 pc: 0x1089e info: 0x0). What might be the cause based on the given program counter or where would be the best place to start looking for the possible cause for the assert? I cannot disclose  all the specifics about the product sw/hw due NDA but basically we are using nRF52SDKI v12.10 with S132 v3.0.0. Ble control code is modified by removing all the heart sensor etc. related code and just sending specific advertisement packets.

[Sami-Pekka Mähönen]

Update: I have done some changes to our implementation regarding timers etc. Assert is still happening but with different program counter. Since the original pc has changed and to keep this thread minimal I will create another ticket with updated info and verify the suggestion to update SD from 3.0.0 to 4.0.5 as answer to original problem.

[Sigurd]

Are you still getting assert with pc: 0x1117C on 4.0.5 ?

[Sami-Pekka Mähönen]

Hey,

Yes, I made changes so that instead of starting and stopping with FreeRTOS timers, I have set advertising timeout to 1 second. When on_adv_evt(BLE_ADV_EVT_IDLE) gets called after timeout, timer using nrf_drv_timer_*() is started. Once that timer timeouts, advertising is started again. It works for a while but then SD asserts. 

0> SDH:INFO:sd_ble_enable: RAM START at 0x20001fd0
0> :DEBUG:Fast advertising.
0> :DEBUG:Advertising idle.
0> :DEBUG:Fast advertising.
0> :DEBUG:Advertising idle.
0> :DEBUG:Fast advertising.
0> :DEBUG:Advertising idle.
0> :DEBUG:Fast advertising.
0> :DEBUG:Advertising idle.
0> :DEBUG:Fast advertising.
0> :DEBUG:Advertising idle.
0> :DEBUG:Fast advertising.
0> :DEBUG:Advertising idle.
0> :DEBUG:Fast advertising.
0> APP_ERROR:ERROR:app_error_fault_handler, id: 0x1 pc: 0x1117C info: 0

static void on_adv_evt(ble_adv_evt_t ble_adv_evt)
{
switch (ble_adv_evt)
{
case BLE_ADV_EVT_FAST:
{
NRF_LOG_DEBUG("Fast advertising.\r\n");
break;
}
case BLE_ADV_EVT_IDLE:
{
NRF_LOG_DEBUG("Advertising idle.\r\n");
m_advertising = false;
timer_extended_compare(APP_IDLE_TIME_MS);
timer_start();
break;
}
default:
{
break;
}
}
}

To start the advertising when idle timer timeout happens:

static void timer_event_handler(nrf_timer_event_t event_type, void *p_context)

{
BaseType_t yield_req = pdFALSE;
xTimerPendFunctionCallFromISR(timer_pend_func, NULL, (uint32_t)event_type, &yield_req);
portYIELD_FROM_ISR(yield_req);
}

static void timer_pend_func(void *param1, uint32_t param2)
{
if((nrf_timer_event_t)param2 == NRF_TIMER_EVENT_COMPARE0)
{
uint32_t ret;
if(!m_advertising)
{
ret = ble_control_adv_start();
if(ret != NRF_SUCCESS)
{
// Failed to start advertising, retry again after configured time.
timer_extended_compare(APP_RETRY_TIME_MS);
timer_start();
}
}
}
}

timer_extended_compare() and timer_start() are just wrappers that use nrf_drv_timer_extended_compare() and nrf_drv_timer_enable() functions. 

[Sigurd]

Ok, unfortunately, we are still running into the same assert. pc: 0x1117C on 4.0.5 is the same as pc: 0x1089e on v.3.0.0. We will look more into this.

[Sigurd]

Is this on a custom board? Could you try it on a nRF52-DK?

It could be some issue with the xtal clock not being accurate enough.

[Sami-Pekka Mähönen]

We indeed have a custom board and I checked that we initialize 16 MHz like this in main.c:

/* Start 16 MHz crystal oscillator */
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
NRF_CLOCK->TASKS_HFCLKSTART = 1;

/* Wait for the external oscillator to start up */
while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
{
}

I added following configuration and used it in SOFTDEVICE_HANDLER_INIT:

#define NRF_CLOCK_LFCLKSRC_RC {.source = NRF_CLOCK_LF_SRC_RC, \
.rc_ctiv = 16, \
.rc_temp_ctiv = 2, \
.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

static void ble_stack_init(void)
{
uint32_t err_code;

nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC_RC;

// Initialize the SoftDevice handler module.
SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, ble_new_event_handler);

...

I haven't seen any asserts yet after testing a good amount of time but just to be sure I need to test this few hours. I'll let you know how it goes. 

[Sigurd]

Great, let me know how it goes. Note that on the nRF52 the HFXO is controlled by a 32 MHz external crystal.

Just so I understand this, did you use 32.768 kHz crystal oscillator(LFXO) when you had the asssert before ? and now you are testing with the 32.768 kHz RC oscillator instead(LFRC)? correct?

If not, what changes did you try now?

[Sami-Pekka Mähönen]

That is correct. All I did was that I changed the clock configuration given when initializing SD from NRF_CLOCK_LF_SRC_XTAL to NRF_CLOCK_LF_SRC_RC. So far, after ~30mins or so, no assert.

Edit: After 17 hours of testing, no assert seen. As summary, in the end this was fixed by changing used clock configuration used to initialize soft device in ble_stack_init().

static void ble_stack_init(void)
{
uint32_t err_code;

nrf_clock_lf_cfg_t clock_lf_cfg = NRF_CLOCK_LFCLKSRC_RC;

// Initialize the SoftDevice handler module.
SOFTDEVICE_HANDLER_INIT(&clock_lf_cfg, ble_new_event_handler);

...

where NRF_CLOCK_LFCLKSRC_RC is:

#define NRF_CLOCK_LFCLKSRC_RC {.source = NRF_CLOCK_LF_SRC_RC, \
.rc_ctiv = 16, \
.rc_temp_ctiv = 2, \
.xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

[jake.yoon]

@Sigurd

So, Could you please let me know how the LFCLK source is affecting the timing assertion of SD?

We should know the mechanism between LFCLK source and SD scheduler to find a way to use LFXO and avoid the assertion.

[jake.yoon]

Any progress here?