Crash due to softdevice assert (id:0x1 pc:0x1089E info:0x0)

[Eddie]

Hi. We are using the nRF52 sdk v12.1 with S132 v3.0.0 on a nRF52832. Once in a while (could be after running a few hours, could be after running a week) the application ends up in the app_error_fault_handler, with id 0x01, pc 0x1089E and info 0x0. I believe this indicates an assert in the softdevice? What could cause this problem? Is there any way we can investigate this issue? Is there a way to recover from this?

I'm not even sure what information would helpful to find out where the problem is. We advertise at a fast pace all the time (20ms), and there are several timers running in the background. Application is communicating through the BLE NUS, but only sporadically. We also have a TWI running to communicate with an external device.

Anyone know an idea on how to handle this problem?

[Kenneth]

Hi, I suspect you are blocking interrupts (e.g. critical region enter) for a long period of time.

Best regards,
Kenneth

[bds]

The critical region enter macro only disables application interrupts, right?

How can it then cause a Softdevice assert?

What time is acceptable to spend in a critical region?

[Kenneth]

Hi, max time for critical region is intended to be used only for a few us, in other words simply set or clear a flag inside the critical region. At least it is the place I would have started to look for this assert.

Best regards,
Kenneth

[Kenneth]

In general I recommend to use S132v3.1, so please download S132v3.1, update the S132 softdevice header files and program the S132v3.1 binary:

https://www.nordicsemi.com/Software-and-Tools/Software/S132

[bds]

We updated to S132v3.1, and now get:

Fault identifier: 0x1
Program counter: 0x10A62
Fault information: 0x0

[Kenneth]

Hi,

It seems you have found a known issue with S132v3.x softdevices, with the your latest error code I can find it's been fixed in S132v4.0.4 and S132v4.0.5, from the release notes in S132v4.0.5:

"Fixed an issue which could cause an assert while running advertiser or scanner (DRGN-9044). (This was also fixed in 4.0.4.)"

So I guess you must either update (see migration document in S132v4.0.0 release on how to) or allow these rare asserts in S132v3.x release.

Best regards,
Kenneth

[bds]

Hi,

do you have some more information on what exactly causes the assert?

Is there a work around, or some way to avoid it?

It seems hardware related as we have some boards that never have the problem, and some that show it regularly.

What do you mean with "allow these asserts"? Does it mean we can ignore them and just keep running? Or do we need take action and call some softdevice functions?

[Kenneth]

bds said:

Is there a work around, or some way to avoid it?

Unfortunately no. 

With "allow these asserts" I meant that you allow a soft reset once a ~week due to the assert. It is somewhat hardware related yes, though the only way to avoid the issue altogether is to update softdevice.

[bds]

Is the issue also related to central behavior, or bluetooth activity in the environment?

We updated our bluetooth central code (running on a Raspberry Pi), and now the issue suddenly appears to happen a lot more frequently, and on a lot more devices. Not sure if there is any relation.

[Kenneth]

I expect it may occur more frequently if there is more BLE activity in general. One question though, what is the detailed chip markings on the nRF52832 IC you are using? Do you have products in the market already, or can you order revision 2 of the nRF52832?
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52832/COMP/nrf52832/ic_revision_overview.html?cp=3_1_2_0