This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf_mesh_disable() function changed since SDK for Mesh V3.1.0?

Hi,

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.

Parents Reply Children
  • 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?

  • Hi Gordie, 

    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)

                {

                    scanner_disable();

                    retval = nrf_mesh_disable();

                }

         __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Disabling mesh: status: %d\n", retval);

    And to enable: 

                scanner_enable();

                uint32_t retval = proxy_enable();

                if (retval == NRF_SUCCESS)

                {

                    retval = proxy_start();

                }

     

                if (retval == NRF_SUCCESS)

                {

                    retval = nrf_mesh_enable();

                }

     

                __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Enabling  mesh: status: %d\n", retval);

  • Hi,

    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);
        remove_evt(p_timer_evt);
        p_timer_evt->p_next = NULL;
        setup_timeout(timer_now());
    }

    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?

  • It's pretty strange you received this issue. Could you try to reproduce it with one of our example, for example the lightswitch server ? 

  • Okay, I will try that and then post the code here.

    Regards,

Related