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]

Hi,

Are you doing UART communication within the client status callback? If yes, most likely that is causing the assertion. User applications should never do any time-consuming task in the mesh callback contexts. Otherwise, they will cause timeslot violations and trigger Softdevice assert.

Try to move out UART communication from the mesh client callback.

To handle large number of incoming status message and to transport them over UART, an application should implement some queuing mechanism that can push the messages in some buffer. This buffer can then be transferred byte-by-byte by using UART interrupts. Alternatively, refer to serial example and see how serial bearer is constructed using bare-metal bearer event scheduler.