Random SoftDevice NRF_FAULT_ID_SD_ASSERT errors

[PaulB]

During development with the nrf52832 (SDK11.0.0-2.alpha), I occasionally get NRF_FAULT_ID_SD_ASSERT errors. I have a breakpoint set at the "softdevice_fault_handler" and the Call Stack shows the ID of 0x00000001, the Program Counter of 0x0000F8DC, and 0x00000000 for Info, which shows that it is NRF_FAULT_ID_SD_ASSERT error, but I don't appear to be able to figure out what address 0x0000F8DC is in the SoftDevice code.  Any help on what I can do to not get this assert based on this Program Counter would be greatly appreciated.

[tesc]

Hi,

In order to figure out what might be the issue I must know what SoftDevice and version you are using.

If you use the nRF52832, then I highly recommend to use the latest release of our SDK (currently v15.2.0). At least you should change to a production release of the SDK, and not use an alpha version.

If you use the nRF51 series then the latest compatible SDK release is version 12.3.0.

You can download nRF5 SDK releases here.

Regards,
Terje

[PaulB]

Thanks for the reply. 

We are using the S132 SoftDevice v2.0.0-7.alpha (not sure how I forgot to add that to the original description).  These versions were from when the project was originally started a few years ago.  We are adding BLE functionality now and, ideally, want to minimize any unnecessary changes.  I do see your point that using an alpha release of anything is not ideal when used in production products.

Is there anyway for you to tell me what assert might be failing in this version of the SoftDevice?  I will attempt to update to the latest production version, but if we must still support the nRF52832 IC Revision Engineering B release due to units that are already in the field, I would like to try to address the issue as it stands in this version of SoftDevice.  We are using the BMD-300 module from Rigado and have been for years.  I have reached out to them to learn what versions of nRF52832 IC Revision are in their modules so I can see what the latest version of the SoftDevice we can upgrade to.

[tesc]

Hi,

The best attempt at fixing this is actually to update to SDK 11 / s132 v2.0.0 production releases. There was a few bugfixes related to asserts before the s132 v2.0.0 production release, according to the SoftDevice release notes. I have not checked if v2.0.0 can run with the SDK v11.0.0-2.alpha, you may be lucky and only need to update the SoftDevice.

Regarding alpha releases, they are not qualified designs, so you cannot use our QDIDs for qualifying your Bluetooth product. That, and the fact that alpha releases are not considered stable, finished products, means it is a very good idea to upgrade at least to the first stable release following the particular alpha.

More regarding the assert: Some action (unknown what) within the SoftDevice was not finished within the required timing constraints. You may get this error if interrupts have been disabled, if you use the timeslot API and do not release the timeslot in time, if you run application code at an interrupt level higher than or equal to the highest level of the SoftDevice, or if you pause program execution in a debug session (i.e. single stepping, breakpoints, etc.)

If you still see the same issue on s132 v2.0.0, and none of the above seems likely, can you try to figure out what you do prior to getting the fault? Information about SoftDevice configuration, number of links and of what type, connection state, etc will also be useful.

Regards,
Terje

[PaulB]

Am I correct that if any of these processors in the field are Engineering B units that I won't be able to upgrade to SDK 11 / s132 v2.0.0 production releases?  Or am I misinterpreting the compatibility matrix?

[tesc]

Hi,

I refer to footnote 2 on that compatibility matrix:

"If workaround for anomaly 73 is implemented, nRF5 SDK 11.0.0 can be used for development purposes together with SoftDevice S132 2.0.0/S212 0.9.x/S332 0.9.x on nRF52832 Engineering B. For more information, see nRF52 Engineering B Errata or nRF5 SDK 11.0.0 release notes."

So yes, you will be able to use Engineering B for development, provided that you implement the workaround mentioned. Please note however that you should not use Engineering B ICs in production.

Regards,
Terje