I was wanting to know if this function has been changed since mesh SDK v2.2.1? It appears to not behave quite the same. When I call it, I think the mesh does not entirely get disabled as there is still something like ~8mA of current draw, when before it used to put the system in a state where it drew something like 600uA.
I had a poke into the nrf_mesh_disable() function and saw that scanner_disable() was no longer called. Is this the reason? I tried adding this call back into nrf_mesh_disable() and it caused an assert.
Any help would be greatly appreciated.
As far as I can tell, the scanner will be automatically disabled after the timeslot has been ended (that what the nrf_mesh_disable() does) . So when testing here I can see that after I call nrf_mesh_disable() the device stayed in high current draw for a little while (about 10s before dropping the current down to the range of uA. This matches with the timeslot being stopped.
Is there anyway to end the timeslot earlier than 10s? Its just that in mesh sdk 2.2.0, the nrf_mesh_disable() function caused the device to enter the lower power state much faster (less than one second)?
Hmm, calling timeslot_stop() straight after nrf_mesh_disable() seems to achieve what I want (entering low power state much faster). I can then call nrf_mesh_enable() and everything works as normal again. Is it safe-ish to use timeslot_stop() in this manner?
Sorry for late response, I was checking with our expert. The proper sequence to disable mesh (immediately) is:
uint32_t retval = proxy_stop();
if (retval == NRF_SUCCESS)
retval = nrf_mesh_disable();
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Disabling mesh: status: %d\n", retval);
And to enable:
uint32_t retval = proxy_enable();
retval = proxy_start();
retval = nrf_mesh_enable();
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Enabling mesh: status: %d\n", retval);
Thanks for the reply. I tried this, but when I try and disable the mesh in this fashion, I get an assert in timer_scheduler.c, line 205:
void timer_sch_abort(timer_event_t* p_timer_evt)
NRF_MESH_ASSERT_DEBUG(bearer_event_in_correct_irq_priority()); //assert here
NRF_MESH_ASSERT(p_timer_evt != NULL);
p_timer_evt->p_next = NULL;
I've come across this assert in the past before, and the only way of fixing it was to call the function causing it from a different context (not ie:main). Is this more or less correct? Is it safe to call from a timer handler?