SoftDevice assertion 86132, combining FATFS in to Mesh DFU example

[SirBuhi]

Hi,

I'm trying to implement the FATFS example with the SD Card access into the Mesh DFU example. Setup is SES v5.44, SDK 17.0.2, Mesh SDK 5.0.0 and S140.

After the start of the Mesh Network, I'm unable to jump into a function and get a Softdevice assert: 86132:0

The order of execution is like: Init BLE Stack -> Init Mesh -> Init/Mount SD Card -> Start Mesh -> Try to write something to the SD Card, but it crashes already while trying to access the function for it.

The mesh initializes with NRF_MESH_IRQ_PRIORITY_LOWEST which is 6 and all IRQ levels in the sdk_config are on the default level 6.

Can you please give me a hint in which direction to go?

Cheers,

SirBuhi 

[tesc]

Hi,

That SoftDevice assert indicates there are timing constraints in the SoftDevice which could not be met. This typically happens when the SoftDevice has been prevented from running for too long.

There are some caveats when mixing Bluetooth mesh and nRF5 SDK examples, also when BLE is not involved. Required steps for a successful merge are documented in the Integrating Bluetooth mesh into nRF5 SDK examples section of the nRF5 SDK for Mesh documentation. It covers both the scenario of adding nRF5 SDK functionality to an nRF5 SDK for Mesh application, and vice versa. If you haven't done so already then please double check you have not missed anything mentioned there.

If you want us to look into the issue from our end, can you share the project? From what I understand this is a merge of two existing examples from the SDK and as such not confidential, but if you cannot share openly then please create a private ticket for sharing the code and refer to this thread.

Regards,
Terje

[SirBuhi]

Dear tesc,

Thanks for getting back to me.

The issue was, that I had breakpoints for debugging after the start of the mesh. This led most likely to the timing contraints and therefore the SoftDevice assertions.

Regards,

SirBuhi

[tesc]

Hi,

Thank you for the update. Yes, continuing execution after breaking will lead to SoftDevice asserts. This is a known limitation. For debugging repeatable bugs, you can often workaround by starting a new run with breakpoint at a later or deeper point in the execution path. Alternatively you could try out monitor mode debugging, where essentially the stack keeps running (complying with timing demands) while the rest of the application is halted, but please note this is a complex solution that is not trivial to set up correctly.

Regards,
Terje