802.15.4 sys_sleep_request_ms does not work

[rozpruwacz]

Hi all,

I'm using NRF SDK v17.0.2 and IEEE 802.15.4 stack library. I want to implement sleeping device. I think I should use sys_sleep_request_ms function to make the device go to sleep but calling it does nothing. If I use  sys_sleep_approver_register to register callbacks for SYS_EVENT_FALLING_ASLEEP and SYS_EVENT_WAKE_UP events (and call sys_sleep_approve in SYS_EVENT_FALLING_ASLEEP event) I see that the callback are called but the SYS_EVENT_WAKE_UP event is emitted immediately after SYS_EVENT_FALLING_ASLEEP event.

So I digged deeper and dissassembled the components/802_15_4/raw/802_15_4_lib_gcc.a library (and all other variants of this library ) to see if there are any calls to wfi or wfe instructions and to my supprise there are none.

This is the dissassembly of the hal_sleep function:

00000000 <hal_sleep>:
   0:	2000      	movs	r0, #0
   2:	4770      	bx	lr

It looks like this function is just returning value 0, what would translate to UNKNOWN_INTERRUPT enum. Do I need to override this function (it is not declared extern so I don't think so) ?

So my question is this library supports sleeping devices ? I would imagine that this library would allow me to implement a device that would wakeup from sleep before the beacon arrival, then go to sleep after the beacon if no data tranfers are pending. Is that possible with this library ?

Nest regards,

Marek Czerski

[Edvin]

Hello,

Sorry. I was apparently a bit quick in the previous reply. HFCLKSTAT = 0x00010000 means that it is running on the RC oscillator, as you said. It is a bit difficult to debug this actually, since the internal HF oscillator is always running when the CPU is running. So whenever you hit a breakpoint, the CPU is running, and the HFCLK will be running as well. The only way to turn it off is inside the __WFE(), which you can't set a breakpoint to trigger. (setting it on __WFE() will of course trigger, but this would be before this is actually executed).

There are a lot of peripherals and drivers (And obviously also libraries) that don't let go of the peripherals as they are supposed to when being disabled. So I started digging into this, and doing some measurements using the PPK. 

I saw that the current consumption went up to about 450µA when the sys_init() was called, as you said. So since the 802.15.4 is only using Timers and the radio, that was where I started looking.

First, since it is easiest, I tried to turn off the power register in the radio peripheral using:

    NRF_RADIO->POWER = 0x00000000;
    while (NRF_RADIO->POWER != 0x00000000)
    {
        // Wait
    }

right before the while loop:

    while (1)
    {
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

This didn't seem to change anything regarding the current consumption, but I left it in for the rest of the test, so perhaps you need this one as well. You can experiment with removing this if you like.

The next thing to test was the timers. Luckily it was the first one I tested, TIMER0 that seemed to be the issue. 

Since the power register of TIMER0 is not available like the NRF_RADIO->POWER register, we need to use it's address to turn it off:

    *(volatile uint32_t *)0x40008FFCUL = 0ul;

After doing this, it looks like the current consumption dropped down to ~5µA:

(there are current spikes, but the average is at 4.39µA)

Give that a go, and let me know what you see.

Best regards,

Edvin

[rozpruwacz]

Great !!!

Edvin said:

Since the power register of TIMER0 is not available like the NRF_RADIO->POWER register, we need to use it's address to turn it off:

that was that. Thank You very much !

Last question. Where is documented this POWER register of TIMER peripherial ? I did not found it in this document and I believe it is the latest release.

[Edvin]

It is not documented publically, unfortunately, but it is the same register offset as the POWER register on the radio peripheral, which is documented here.