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

[emh203]

Hello:

I am upgrading my application to use Mesh SDK 3.0.0 (I was at 2.1.1).   In my application, I process the mesh from the main loop (per the instruction in the Interrupt Priority levels section of the documentation )

My mesh_init() looks like this:

static void mesh_init(void)
{
 uint8_t dev_uuid[NRF_MESH_UUID_SIZE];
 uint8_t node_uuid_prefix[NODE_UUID_PREFIX_LEN] = SERVER_NODE_UUID_PREFIX;

ERROR_CHECK(mesh_app_uuid_gen(dev_uuid, node_uuid_prefix, NODE_UUID_PREFIX_LEN));
 mesh_stack_init_params_t init_params =
 {
 .core.irq_priority = NRF_MESH_IRQ_PRIORITY_THREAD,
 .core.lfclksrc = DEV_BOARD_LF_CLK_CFG,
 .core.p_uuid = dev_uuid,
 .models.models_init_cb = models_init_cb,
 .models.config_server_cb = config_server_evt_cb
 };
 ERROR_CHECK(mesh_stack_init(&init_params, &m_device_provisioned));

}

I used the NRF_MESH_IRQ_PRIORITY_THREAD priority level.

In this configuration, I noticed I will always get an assertion from somewhere in the mesh stack when using the GATT based Android App for provisioning.

Everything works fine when I use NRF_MESH_IRQ_PRIORITY_LOWEST but I can no longer use mesh API from the main loop.


What is the solution to being able to use the GATT proxy for provisioning w/ the app also well as using mesh API in the main loop?

[natersoz]

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.

[emh203]

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. 

[natersoz]

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.