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.

[Sigurd]

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.

[Sami-Pekka Mähönen]

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

[Sigurd]

Hi,

Sami-Pekka Mähönen said:

I had my device on testing overnight and there were lots of resets still.

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.

[Sami-Pekka Mähönen]

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.