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

[gordie]

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.

[Hung Bui]

Hi Gordie, 

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. 

[gordie]

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)?

[Hung Bui]

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

[gordie]

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

Regards,

[Justin]

I am also experiencing this issue.
I have a device in which mesh is completely disabled to save power.
It wakes up at a specified interval to transmit data, then goes back to sleep.

In the old (2.x) mesh SDK, when calling nrf_mesh_disable() to put the device to "sleep", I measured around 15uA.  This is comparable to our BLE code version of the device (same hardware).

Current draw measures around 450uA with the new (3.1) mesh SDK.
The code posted above does not reduce the current consumption.

Are there other modules enabled that need to be turned off?

[gordie]

The code posted above does not work for me either, the way I do it is (psuedo code):

// Entering "Sleep" mode

//stop all active app timers here (if used)
timeslot_stop(); // Stop the current timeslot (Work around to enter the low power state much faster).
while(!nrf_mesh_disable());


// Exiting "Sleep" mode

// start app timers here (if used)
timeslot_restart(TIMESLOT_PRIORITY_LOW);
while(!nrf_mesh_enable());

Another thing to check is the SAADC, if you use it. Make sure you are disabling/sleeping it correctly. This can have a large effect on current draw.

[gordie]

This is how I do it in Mesh SDK v 3.1, and it works reliably for me. I have not received confirmation from Nordic if this is how it is supposed to be done.

[Justin]

what is your current draw when "sleeping"?
even with your example code implemented, i'm still seeing ~450uA.  there must be some other module keeping part of the mesh awake.

[Hung Bui]

Hi guys, 
Strange that calling       scanner_disable() didn't help for you. 

We have a new patch that solves the issue more thoroughly that you can try.  

Apply this patch for bearer_handler.c:

--- a/mesh/bearer/src/bearer_handler.c
+++ b/mesh/bearer/src/bearer_handler.c
@@ -319,10 +319,14 @@ uint32_t bearer_handler_stop(bearer_handler_stopped_cb_t cb)
         /* Will stop the timeslot when the current action ends. */
         m_stopped_callback = cb;
         m_stopped = true;
-        if (timeslot_session_is_active())
+        if (timeslot_is_in_ts())
         {
             timeslot_trigger();
         }
+        else if (timeslot_session_is_active())
+        {
+            timeslot_stop();
+        }
         else
         {
             notify_stop();

And in bearer_handler_timer_irq_handler() replace action_switch(); with 

 if (m_stopped)
        {
            timeslot_stop();
        }
        else
        {
            action_switch();
        }

Calling timeslot_stop(); is not suggested as it may cause an assertion if the bearer has not been stopped before that. So it's the other way around.  

(This should not be combined with scanner_disable()workaround )

[Justin]

thanks, i will give this a try and report back!

[Justin]

the code provided works.

however, it seems that that our issue is coming from the mesh bootloader.

when our device is programmed to use the mesh bootloader (and SD and application), sleep current is ~450uA. 

when our device is programmed with only SD and application, sleep current is ~15uA, as expected/desired.

i commented out `nrf_mesh_dfu_init` to see if that was causing the extra current consumption, but even without initializing dfu, the device still measured 450uA.

Do you have an explanation or suggestion for the bootloader current consumption? 

I can make this into a new post if you would prefer.

[Hung Bui]

It seems that we forgot to turn off some of the peripheral inside the bootloader before switching to the application. 

Could you try adding 

NRF_CLOCK->TASKS_HFCLKSTOP=1;
NRF_UART0->TASKS_STOPRX= 1;

after you disable mesh and check if the current is dropped down to few uA. 

Please also check if you still can do DFU after you wake up. 

15uA is still high, I'm not sure why your board has that number. Please try to test put CPU to sleep without initialize mesh or  before doing anything in main().