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

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

ValentinL — Wed, 16 Sep 2020 13:39:55 GMT

here is the link to the new post ! Waiting for your answer :)

devzone.nordicsemi.com/.../low-power-mesh-node-based-on-lightswitch-example-by-using-proxy_stop-and-mesh_disable

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

ValentinL — Wed, 16 Sep 2020 13:30:57 GMT

Ok ty I am creating a new post therefore ! thx

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

Hung Bui — Wed, 16 Sep 2020 13:05:45 GMT

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)

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

ValentinL — Wed, 16 Sep 2020 12:12:28 GMT

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

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

ValentinL — Wed, 16 Sep 2020 10:30:39 GMT

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 ?

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

ValentinL — Wed, 16 Sep 2020 10:27:42 GMT

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();
    }
}

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

Hung Bui — Thu, 02 May 2019 14:27:58 GMT

Hi Gordie,

Yes it's correct.

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

gordie — Wed, 01 May 2019 00:43:54 GMT

Hi Hung, so just to confirm, after applying the suggested patch to bearer_handler.c, the correct way of enabling and disabling the mesh is now:

// The proper sequence to disable mesh (immediately) is: 

uint32_t retval = proxy_stop();

if (retval == NRF_SUCCESS)
{
	//scanner_disable(); // not needed
	retval = nrf_mesh_disable();
}
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Disabling mesh: status: %d\n", retval);



// And to enable: 

//scanner_enable(); // not needed

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

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

Hung Bui — Thu, 11 Apr 2019 15:32:02 GMT

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.

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

Justin — Thu, 11 Apr 2019 00:10:16 GMT

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!

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

Hung Bui — Wed, 10 Apr 2019 12:36:23 GMT

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

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

Justin — Tue, 09 Apr 2019 23:56:20 GMT

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.

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

Justin — Mon, 08 Apr 2019 20:32:28 GMT

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

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

Hung Bui — Wed, 03 Apr 2019 14:51:57 GMT

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 )

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

Justin — Tue, 02 Apr 2019 17:01:09 GMT

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.

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

gordie — Mon, 01 Apr 2019 22:33:41 GMT

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.

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

gordie — Mon, 01 Apr 2019 22:32:20 GMT

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.

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

Justin — Mon, 01 Apr 2019 22:21:40 GMT

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?

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

gordie — Sun, 24 Feb 2019 22:14:12 GMT

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

Regards,

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

Hung Bui — Fri, 22 Feb 2019 12:58:39 GMT

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

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

gordie — Wed, 20 Feb 2019 01:01:59 GMT

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?

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

Hung Bui — Wed, 13 Feb 2019 10:16:17 GMT

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

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

gordie — Mon, 04 Feb 2019 22:54:03 GMT

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?

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

gordie — Mon, 04 Feb 2019 22:46:16 GMT

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

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

Hung Bui — Mon, 04 Feb 2019 12:38:28 GMT

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.