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,

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.

[Sigurd]

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)