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

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

jake.yoon — Mon, 20 Apr 2020 04:43:11 GMT

Any progress here?

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

jake.yoon — Fri, 17 Apr 2020 01:35:47 GMT

@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.

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

Sami-Pekka Mähönen — Tue, 06 Mar 2018 12:19:38 GMT

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}

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

Sigurd — Tue, 06 Mar 2018 11:49:53 GMT

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?

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

Sami-Pekka Mähönen — Tue, 06 Mar 2018 11:42:16 GMT

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.

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

Sigurd — Tue, 06 Mar 2018 09:43:18 GMT

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.

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

Sigurd — Tue, 06 Mar 2018 09:30:29 GMT

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.

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

Sami-Pekka Mähönen — Tue, 06 Mar 2018 09:12:27 GMT

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.

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

Sigurd — Tue, 06 Mar 2018 09:02:43 GMT

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

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

Sami-Pekka Mähönen — Tue, 06 Mar 2018 09:01:14 GMT

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.

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

Sami-Pekka Mähönen — Wed, 28 Feb 2018 16:22:46 GMT

Hey,

Ok, I just wanted to be sure that I'm not doing something wrong by changing advertising data without stopping advertisement first.

I enabled logs and seems that the program counter that I'm seeing now has changed to 0x1117C.Further debugging is not an option as we build our project with Eclipse and not with Keil.

id: 0x1 pc: 0x1117C info: 0

To be noted that assert is no longer as easy to reproduce as originally.

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

Sigurd — Wed, 28 Feb 2018 14:29:27 GMT

Hi,

[quote user="SamiPM"]I had my device on testing overnight and there were lots of resets still. [/quote]

Are you still getting the assert with pc: 0x1089e ? or is this a new issue? Generally, a reset indicates that you are running into the error handler (APP_ERROR_CHECK), where the default behavior is to do a reset. You should then debug in order to find the reason for the reset, and you should have the preprocessor symbol DEBUG defined when debugging. See e.g. this post about debugging.

You should be able to change the manufacturing data like you are doing without stopping the advertising. The SD will not get flooded. But, you could of course try to stop the advertising before you change it, and see if it makes any difference.

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

Sami-Pekka Mähönen — Wed, 28 Feb 2018 08:42:49 GMT

Hey,

Thank you for all the help. I was able to make it so that from now on we will update all BL + SD + APP as one. This is actually required in case we need to update BL to all existing devices which customers have.

I had my device on testing overnight and there were lots of resets still. We are not using time slots so its either some irq priority issue we are doing something incorrectly from the app side. One thing that I've been wondering is that as said earlier, we advertise every 1 minute for 500 ms. Advertising interval is set to 100 ms. Advertising type is non-connectable/non-scannable and mode is set to fast. I have created own function to update the manufacturing data on the fly:

uint32_t ble_advertising_set_adv_manuf_data(ble_advdata_manuf_data_t *manuf_data)
{
m_advdata.p_manuf_specific_data = &m_manuf_specific_data;
m_manuf_specific_data.data.p_data = m_manuf_data_array;
m_advdata.p_manuf_specific_data->company_identifier = manuf_data->company_identifier;
m_advdata.p_manuf_specific_data->data.size = manuf_data->data.size;

for (uint32_t i = 0; i < manuf_data->data.size; i++)
{
m_manuf_data_array[i] = manuf_data->data.p_data[i];
}

return ble_advdata_set(&m_advdata, NULL);
}

This function is called whenever the data has been changed and it's needed to be updated. Is it ok to update manufacturing data like this considering that if the data changes a lot SD might get flooded or do we need for example stop the advertising before setting it?

Edit: The function above has been added to ble_advertising.c

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

Sigurd — Tue, 27 Feb 2018 14:03:55 GMT

Hi,

When updating to a new major SD number, it is required to update the bootloader also. You should do a BL + SD + APP update. See the combination table, and “Note 2” on this page: https://github.com/NordicSemiconductor/pc-nrfutil#generate. Also note that there is bug in the bootloader copy routine, so you need to add an offset based on the SoftDevice version. See this page.

Edit: You will not run into the bug in the bootloader copy routine since S132 v.3.0.0 and v.4.0.5 is the same size (124 kB)

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

Sami-Pekka Mähönen — Mon, 26 Feb 2018 17:11:48 GMT

Hey,

One issue that came up when upgrading from S132 3.0.0 to 4.0.5 is that DFU fails at dfu_req_handling.c when post validation is done. Current SD major (3) and new SD major (4) do not match. Do you see any issue there? We generate zip-package containing both SD and application which is then flashed by using serial DFU based on nRF SDK 13.0.0. Otherwise migration was successful but to be sure that it fixes the problem requires more extensive testing.

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

Sami-Pekka Mähönen — Mon, 26 Feb 2018 09:44:15 GMT

Hey,

Thanks for the fast reply. I'll try by updating softdevice to the version 4.0.5. I'll let you know how it goes once the migrating is done and I've done some testing with it.

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

Sigurd — Fri, 23 Feb 2018 16:08:47 GMT

Hi,

This assert could happen if you are using timeslots, and exhaust your time slot. In other words, it might help if you could reduce whatever code you have going in the slot. Maybe it is possible to move some of the code to a different context. Also make sure that you are not disabling interrupts globally. It could also be caused by some irq priority issue with FreeRTOS, and it could also be that you are running into a bug in the SoftDevice that was fixed in version 4.0.5. In the release notes the bug fix is described as "Fixed an issue which could cause an assert while running advertiser or scanner". I will ask our FreeRTOS expert at Nordic for input on this, but you might need to migrate to S132 4.0.5 to solve this.