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.

[PaulB]

Thanks for your quick responses concerning all my questions.  Now, all I can do is wait for Rigado customer support to get back to me about what IC Revision they are using and have used in the past to know what my upgrade options are. 

As for figuring out what I am doing before the fault, the only thing I can say is that it is related to Bluetooth.  Before that was implemented, the fault never occurred.  Other than that, it is quite random.  We don't disable interrupts, we are not using any Timeslot API (that I am aware of), and all the interrupt levels are the defaults used in the examples.  Not sure what it could be that we are doing.

In other threads on the forum, it looks like Nordic personnel were able look into the SoftDevice code and say what function the assert failed in.  I was hoping my situation would be that simple.

If I am able to upgrade and if I still experience problems, I will respond on this thread.  Thanks again for all your help so far.

[tesc]

Hi,

Yes, in some instances we can tell clearly where the fault happened, but this time it happened inside a function which is called from several locations.

Regarding what IC revision they use for the module, do you see the nRF SoC on the module or is it encapsulated in shielding or otherwise out of view? If the SoC is visible you can have a look at its markings in order to determine what revision it is.

E.g. I have a development board here, with the following markings on the nRF:

N52832
QFAABB
1601AB

The middle line is the Packet variant and two first symbols of the Build code, as described in the IC revision overview. That means the IC on my board is Engineering C.

(The IC marking is described in section "52.1 IC marking" of the nRF52832 Product Specification, which you can find at https://www.nordicsemi.com/DocLib .)

Regards,
Terje

[PaulB]

This is helpful to know.  The Rigado part does have a shield over the SoC so I can't read the chip itself.  I am able, however, to read the INFO.PART and INFO.VARIANT registers (sections 13.1.16 and 13.1.17 of the nRF52832 Product Spec).

It turns out the reason why we were using the SDK 11.0.0-2.alpha / s132 v2.0.0-7.alpha was because that was the last supported version available as a Software Pack in Keil.  Only after starting this thread did I figure out that newer versions of the SDK need to be manually downloaded and un-zipped.

Where is the recommended location to un-zip these files in Keil, or is it common to keep these files stand alone or even with the project files?

[tesc]

Hi,

There is no standard or recommended location for the SDK, as they can be located anywhere on disk. You can go as simple as unzipping the SDK then develop your project by modifying an example within it, or you can have your project at another location. Please be aware of long paths, though, as too long paths may lead to strange compilation error messages.

I do not know what is common out in the field, but there are some DevZone threads with good suggestions for what to do.

In general I recommend to use revision control for your project files, and to not modify any SDK files.

Regards,
Terje