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

[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(). 

[Justin]

i added the code into the bootloader, at the start of bootloader_util_app_start().

this appears to fix the issue, as the device goes to ~15uA as expected.

DFU was still functional.

we have a sensor on our board that draws a bit of current, so that is why the current might be higher than you expect.

thanks!

[Hung Bui]

Thanks for verifying. UART needs to be turned off by the bootloader before switching to application.

I guess we didn't really pay much attention on power consumption when making the bootloader as it's a mesh application and usually main powered. I have reported this issue internally. 

[ValentinL]

Hello,

I work with SDK for mesh 4.0.0. I use the example code "light switch server". I just want to disable the Mesh stack and enable it when I want. When the mesh is disable I want sleep current so approx 4uA.
I measure the current with the PPK on a DK.
As you can see in the attached code. I made as recommended to disable the mesh. but I still get average +- 110 uA due to some peaks (see image attached, first image)).
If I add  NRF_CLOCK->TASKS_HFCLKSTOP=1; NRF_UART0->TASKS_STOPRX= 1;
I get no peaks but the average current increase to +- 400uA ... (see attached, second image).

Can someone help me please !? I don't know what to do and this is very critical for my low power application !!

int main(void)
{
    initialize();
    start();
    //nrf_delay_ms(3000);
    uint32_t retval;
    retval = proxy_stop();
    //SEGGER_RTT_printf(0, "retval_stopproxy %d\n",retval);
    if (retval == NRF_SUCCESS)
    {
        retval = nrf_mesh_disable();
        //NRF_CLOCK->TASKS_HFCLKSTOP=1;
        //NRF_UART0->TASKS_STOPRX= 1;
    }
    //SEGGER_RTT_printf(0, "mesh_disable %d\n",retval);
    //scanner_radio_stop();

    for (;;)
    {
        (void)sd_app_evt_wait();
        //__WFE();
    }
}

[ValentinL]

I don't use the LPN code (experimental). I use the "Lightswitch server" instead. Is it not possible to get very low mesh sleep power with this code as starting point ?

[ValentinL]

I think I have an error when I do ythe NRF_CLOCK->TASKS_HFCLKSTOP=1; That's probably why I have a wrong consumption. Where do I have to add this line in my code to don't get this error (assert) ?

[Hung Bui]

Hi ValentinL, 
Please create a new case for your question. This is a very old thread. 

Btw, in your screenshot it looks like the radio is still running, doing some advertising. Please zoom in and double check if it's advertising packet (sending on 3 channels) 

[ValentinL]

Ok ty I am creating a new post therefore ! thx