Mesh SDK 3.0.0 assertion GATT provision er when running mesh from main loop

RE: Mesh SDK 3.0.0 assertion GATT provision er when running mesh from main loop

natersoz — Mon, 31 Dec 2018 22:41:10 GMT

The asserts are happening for a reason. I have seen Nordic's softdevice assert when you use resources which conflict with the softdevice. For instance: if you write to memory reserved for the softdevice stack. It will assert. Unfortunately the error provided in the error handler may not be all that informative, it is better to have Nordic call the error handler and abort operation rather than continue along while your app conflicts with softdevice resources.

RE: Mesh SDK 3.0.0 assertion GATT provision er when running mesh from main loop

emh203 — Mon, 31 Dec 2018 14:51:27 GMT

Just an FYI: The mesh init snippet was to just show the IRQ priority setting.

In this case, the assertion is generated somewhere in the soft device during run-time when using the nRF mesh app for provisioning. I have a debugger attached and the assertion is happening in the software device. I really wish the software device was just a set a files we could actually debug instead of a binary block.

The static assertions are very scary for production as there might be a rare occasion when a device can lock up.

RE: Mesh SDK 3.0.0 assertion GATT provision er when running mesh from main loop

natersoz — Sat, 29 Dec 2018 22:15:56 GMT

I have not tried the mesh features, but here are some ideas:

1. Instead of using the ERROR_CHECK macro, handle the error locally:

uint32_t const error_code = mesh_app_uuid_gen(dev_uuid, node_uuid_prefix, NODE_UUID_PREFIX_LEN);

Now you can either log the error or access it using the debugger. The error code will provide insight into what is happening.

I hate Nordic's use of these macros BTW. I would discourage their usage completely.

2. You realize that the softdevice reserves IRQ priorities 0, 1, 4 for itself. The softdevice will (likely) send you an assert when you use their reserved resources.