s140_nrf52_7.0.1_softdevice fault @ 0x25B96

[jkaye-du]

Dear Nordic,

Running BLE mesh sensor network with multiple servers and a single client linked to a gateway.

SDK: 16.0.0_98a08e2

SDK Mesh: v4.0.0

nRF52840

The client sporadically faults @ address 0x25B96. The servers are rock solid.

Can you kindly give me a clue as to why it faults at that address.

Thanks!

-John

[jkaye-du]

Hi, and thank you for your response and attention.

In brief, I've built BLE sensor mesh network based on the components I list above. The server and client implementations are based primarily on the SDK mesh light switch example with a bit of the Thingy52 Mesh example thrown in for the model creation. The servers simply read sensors, package the data into a JSON string, and transmit that string through the mesh to the client. The client receives those JSON strings, does some minor processing, and then transmits them over a UART connection to the gateway. Pretty simple. The issue I have is that the client occasionally faults @ 0x25B96 in its address space. I run emStudio on the client and can tell when it does. Since I don't have the source code, or even a map, for the S140 Softdevice, I have no idea what's going on. I imagine this is a popular topic for the Nordic forum.

Questions for you:

1. What strategies can I implement to better handle and recover from softdevice faults? I've seen references to softdevice_fault_handlers in older versions of the SDKs as well as the Thingy52 SDK; are there examples of how to use or implement those? Are there other methods?
2. In terms of the client receiving asynchronous messages from a large number of servers, does Nordic recommend an architectural approach for handling those incoming messages without violating BLE timing? Are there examples where the incoming messages are buffered and processed in a non time critical way?

Thanks again for your help and support.

-John

[Mttrinh]

I looked into the address of the softdevice fault. It seems to be a timing issue. The application did not end the timeslot in time, it used more than allocated time before closing the timeslot. Might have used too much time in the callback handler.

Softdevice faults are asserts that need a reset of the device. So there could be no recovery on the softdevice side, but the app can modify the app_fault hander and save some state data before calling NVIC_SystemReset()

Regarding your second question, I have forwarded this to our Mesh team. I will come back to you with an update.