Assertion in access_model_publish(), after setting publish address

[frank1]

Hi everyone,

I'm migrating my project from nrf sdk for Mesh v2.1.1 to v5.0.0. To do this, I build my code on the light switch client example from nrf sdk for mesh v5.0.0.

my setup:
- own PCB with the nrf52832 chip (but same problem occurs with an nrf52DK)
- segger embedded studio for ARM V5.40a
- nrf sdk for mesh v5.0.0 (is currently v2.1.1)
- nrf mesh android app v3.1.1

The problem:
The node sends a message to the provisoner whenever the node resets (using the function access_mode_publish() in access.c). No messages are send until the subscription address is set (which is correct). But after I set the application key and subscription address with the nrf mesh app, the program gets an assert when it sends the message. It goes to the error handler.
(I've tested this in nrf sdk for mesh v4.2.0 and v3.0.0 as well, but I get the same problem).

I have been debugging this problem and I found out that the assert happens in the timer_scheduler.c here:

If I'm correct, this means that an irq priority is not set correctly. But I have set all irq priorities to 6 (NRF_MESH_IRQ_PRIORITY_LOWEST), so I don't know why this gives the problem.

I've been looking in the migration guides and release notes, but I couldn't find anything that could help me with this problem.

So my question is: How can I solve this irq priority problem?

If there is any information missing, please let me know.

[Mttrinh]

Hi,

Have you looked at this documentation to see if there is something missing? Are you using FreeRTOS?

Be aware that if you use NRF_MESH_IRQ_PRIORITY_LOWEST, you should only call the mesh API from an interrupt handler with NRF_MESH_IRQ_PRIORITY_LOWEST.

[Mttrinh]

Hi,

Do you get any error codes/asserts from the packet_send() function? And you are not running the mesh handling in the main loop, correct?

[Mttrinh]

Hi,

Yes, your assumption is correct. Can you try to debug the code, do you get any error codes when trying to connect? Set the DEBUG define before debugging. 

[frank1]

Do you mean this with the DEBUG define?

If so, i see that the nrf gets a soft reset during connecting (NRF_POWER->RESTREAS == 0b100)

Note that this happens when I changed the priority to NRF_MESH_IRQ_PRIORITY_THREAD (15). If I use NRF_MESH_IRQ_PRIORITY_LOWEST (6), this does not happen. Then I get no errors during connecting and provisioning.

[Mttrinh]

Right click on your project in your left pane -> Press "Options..." -> Change the drop-down in the upper-left from "Debug" to "Common" -> Under Code, press "Preprocessor" -> Press the "..." in Preprocessor Definitions -> Then add "DEBUG" to the list.

Then run your code in debug mode and see if you get any error codes and what function is returning it.

[frank1]

I don't get an error, but I do get an assert from this function:

Note that this is the same function that causes an assert when the irq_priority = _LOWEST (6) and I try to send a message from my nrf.

[Mttrinh]

Hi,

I asked one of our developers about this. This is his response:

I guess when the they are trying to publish a message, but the function is called from the wrong IRQ priority. Any mesh API after mesh is started must be called from the same priority as configured through mesh_stack_init_params_t.core.irq_priority. As a simple check they could use bearer_event_generic_post to schedule a callback at the mesh IRQ priority and publish a message from this callback.

Can you try this and see if it helps?

[frank1]

Sorry, I did not see your reply until today.

This is what i tried:

void(*callback)(bearer_event_callback_t) = &my_cb;
bearer_event_generic_post(callback, NULL);

void my_cb() {
    /* publish the message */
}

My message is now publish without errors/asserts.

Note: I changed the mesh_stack_init_params_t.core.irq_priority back to NRF_MESH_IRQ_PRIORITY_LOWEST (6), otherwise I cannot connect to my nrf.

I will do some more tests and verify if the message is also received correctly. It looks promosing.
Thank you for your help.