802.15.4 sys_sleep_request_ms does not work

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Mon, 15 Feb 2021 08:48:47 GMT

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.

RE: 802.15.4 sys_sleep_request_ms does not work

rozpruwacz — Fri, 12 Feb 2021 15:58:22 GMT

Great !!!

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/294195#294195"]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:[/quote]

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.

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Fri, 12 Feb 2021 14:45:57 GMT

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

RE: 802.15.4 sys_sleep_request_ms does not work

rozpruwacz — Fri, 12 Feb 2021 11:57:20 GMT

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/294125#294125"]How do you wake up from the sleep? I see that you use sys_sleep_request_ms(10000); Do you wake up after 10 seconds, or do you wake on a button press or something?[/quote]

No. I am working now with a minimal example that only goes sleep after calling sys_init. No wake up.

This is the exact and only code I'm running:

#include "sys_init.h"
#include "sys_utils.h"
#include "nrf_drv_clock.h"
#include "802_15_4_config.h"
#include "ral_irq_handlers.h"


static void clock_init(void)
{
    ret_code_t err_code = nrf_drv_clock_init();
    ASSERT((err_code == NRF_SUCCESS) || (err_code == NRF_ERROR_MODULE_ALREADY_INITIALIZED));

    nrf_drv_clock_hfclk_request(NULL);
    while (!nrf_drv_clock_hfclk_is_running())
    {}

    nrf_drv_clock_lfclk_request(NULL);
    while (!nrf_drv_clock_lfclk_is_running())
    {}
}

int main(void)
{
    static uint8_t __ALIGN(ALIGN_VALUE) m_heap[CONFIG_POOL_SIZE];
    static const size_t m_heap_size = CONFIG_POOL_SIZE;
    ral_irq_handler_import();
    clock_init();
    sys_init(m_heap, m_heap_size);
    nrf_drv_clock_hfclk_release();
    nrf_drv_clock_lfclk_release();
    while(1) {
        __WFE();
    }
}

IF I COMMENT OUT THE sys_init CALL THE CURRENT CONSUMPTION IS 3uA.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/294125#294125"]How do you measure it? Is the dongle connected to a computer via the USB?[/quote]

I power the board with 3.3V through OUT ping (which is the VDD CPU pin).

I measure the current with multimeter beetween power source and OUT pin.

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Fri, 12 Feb 2021 10:41:14 GMT

>HFCLKSTAT = 65536

Yes, that means HFCLKSTAT = 0x00010000, meaning that STATE = not running, SRC = XTAL.

I haven't tried to measure the current consumtion on the dongle before. How do you measure it? Is the dongle connected to a computer via the USB?

How do you wake up from the sleep? I see that you use sys_sleep_request_ms(10000); Do you wake up after 10 seconds, or do you wake on a button press or something?

The reason I ask is because if none of the clocks are running, and you wake up after 10 seconds, it means it is using nrf_delay_ms(), which doesn't really allow the device to go to sleep.

BR,
Edvin

RE: 802.15.4 sys_sleep_request_ms does not work

rozpruwacz — Thu, 11 Feb 2021 21:48:04 GMT

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/293979#293979"]I see that you release the hfclk as well, but is it requested from elsewhere in your project? You can try to debug nrf_drv_clock_hfclk_release() to see whether or not this line is true or false:[/quote]

No other part of the code is requesting the hf clock. I checked also that nrf_drv_clock_hfclk_release actually stops the hf clock and it does.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/293979#293979"]Is your lfclk running when you enter sleep?[/quote]

Yes it runs in sleep. I added code to disable it after Your suggestion but it not changed the current consumption during sleep.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/293979#293979"] For both of the clocks you can check the registers directly using [/quote]

I checked both registers values just before __WFE call and those are the values:

HFCLKSTAT = 65536
LFCLKSTAT = 0

I'm not sure if the HFCLKSTAT is correct. As I understand, the value 65536 (0x10000) means that the hfclk runs from internal high frequency oscillator. Before call to nrf_drv_clock_hfclk_release the value is 0x10001 which means that the hfclk runs from external oscillator. Should the value of HFCLKSTAT be 0 ? If yes, then maybe in debug mode it can't be 0 to allow debug interface to work ?

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/293979#293979"]What HW are you running this on? DKs or custom boards? Does it have an LFXTAL?[/quote]

I'm using nrf52840 dongle board (pca10059).

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/293979#293979"]Another possibility is other peripherals. Are you using anything else? UART for logging or the application?[/quote]

No other peripherials. No logs, no uart.

I'm pretty sure that the high current consumption is caused by the sys_init call because if I call sleep just before sys_init I get 3uA, if I call sleep just after sys_init I get 400uA.

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Thu, 11 Feb 2021 12:42:00 GMT

[quote user="rozpruwacz"]I cannot reply directly to Your last message because there is no reply button so I just reply to myself.[/quote]

It happens from time to time. Try to reload the page until it shows up if it happens again.

So it could be a couple of different things causing the higher current consumption.

802.15.4 is used in Thread and Zigbee, and the downside with this is that the proper nodes have to always be listening, keeping the radio in RX mode. However, this would draw a lot more than 400µA (roughly 5-10 mA), so I don't think that is what you are seeing.

Please note that calling TIMER0->TASK_STOP doesn't stop the actual clock that you requested using nrf_drv_clock_hfclk_request().

I see that you release the hfclk as well, but is it requested from elsewhere in your project? You can try to debug nrf_drv_clock_hfclk_release() to see whether or not this line is true or false:

m_clock_cb.hfclk_requests

and whether hfclk_stop() is called.

Is your lfclk running when you enter sleep? For both of the clocks you can check the registers directly using

NRF_CLOCK->HFCLKSTAT;

NRF_CLOCK->LFCLKSTAT;

(see links for register description)

What HW are you running this on? DKs or custom boards? Does it have an LFXTAL? If it is a custom board, you need to check the XTALs' electrical specification to see how much current it draws.

Another possibility is other peripherals. Are you using anything else? UART for logging or the application? If so, you can try to disable this as well, and set the pins in the disconnected input state. Basically, an output may draw current if it needs to hold a pin high or low while it is in sleep.

Best regards,

Edvin

RE: 802.15.4 sys_sleep_request_ms does not work

rozpruwacz — Thu, 11 Feb 2021 11:30:02 GMT

Hi Edvin,

Thanks for the response. I cannot reply directly to Your last message because there is no reply button so I just reply to myself.

I did what You suggested (calling __WFE()) and it does work. But I have an issue with the current consumption. It is much larger than expected and is aroung 400uA. I expect it to be less that 10uA. The isolated test case is below:

static void clock_init(void)
{
    ret_code_t err_code = nrf_drv_clock_init();
    ASSERT((err_code == NRF_SUCCESS) || (err_code == NRF_ERROR_MODULE_ALREADY_INITIALIZED));

    nrf_drv_clock_hfclk_request(NULL);
    while (!nrf_drv_clock_hfclk_is_running())
    {
        // spin lock
    }

    nrf_drv_clock_lfclk_request(NULL);
    while (!nrf_drv_clock_lfclk_is_running())
    {
        // spin lock
    }
}

static void sleep()
{
    nrf_drv_clock_hfclk_release();
    __SEV();
    __WFE();
    __WFE();
    nrf_drv_clock_hfclk_request(NULL);
    while (!nrf_drv_clock_hfclk_is_running())
    {
        // spin lock
    }
}

int main(void)
{
    static uint8_t __ALIGN(ALIGN_VALUE) m_heap[CONFIG_POOL_SIZE];
    static const size_t m_heap_size = CONFIG_POOL_SIZE;
    ral_irq_handler_import();
    clock_init();
    sys_init(m_heap, m_heap_size);
    sleep();
}

To be sure that the issue is related to the 802.15.4 library i tested the case where sleep was called just before sys_init and the result was that the current consumption was at around 3uA which is what I would expect.

So obviously the sys_init call enables some hardware that consumes 400uA of current and I'm not able to figure out what it is. I know that I should disable all the peripherials for low current consumption in sleap mode, but I do not know which peripherials are enabled by the sys_init call.

I suspect the RADIO and TIMER0 peripherials but disabling them explicitly before sleep does not change the current consumption.

To disable radio and timer I did:

NRF_RADIO->TASKS_DISABLE = 1;
TIMER0->TASK_STOP = 1;

So the question is, what do I need to disable to get low current consumption in SYSTEM ON sleep ?

Best regards,

Marek Czerski

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Thu, 11 Feb 2021 08:27:22 GMT

Hello,

Sorry for the late reply. I missed the internal reply. I am sorry.

So I asked our 802.15.4 team about this, and their reply was:

--------------------------

The state of this IEEE 802.15.4 stack is that it was developed externally (therefore it is distributed in a binary form) as a standalone project. By "standalone" I mean the developers who worked on this, extracted from SDK or developed internally any components that required HW access (peripheral drivers, Radio configuration, MDK and cortex libs). And they added a configuration option to indicate whether to use those internal drivers, or the stack has to integrate with external components. The stack available in the nRF5 SDK uses the latter config to integrate with the SDK components (drivers and libraries) and not the internal components of the 802.15.4 stack project.

Unfortunately the config option is not properly reflected in the API documentation, but the understanding should be, that anything that accesses the nRF52 HW except for the RADIO and TIMERs used by the stack, should be handled externally. In this case the user should call the WFE() CMSIS function to put the device to seelp. The sys_sleep() API can only handle the sleep approving logic (checking if other components approve entering the sleep state).

--------------------------

So it looks like the API is not putting the device to sleep. Only providing the events that you can do so in.

To see how to put the device to sleep, I suggest that you check out some of the other examples in the SDK that uses the nrf_pwr_mgmt_run().

See e.g. the ble_app_hrs example. In the main loop, you have:
idle_state_handle() -> nrf_pwr_mgmt_run() ->

    {
        // Wait for an event.
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

Best regards,

Edvin

RE: 802.15.4 sys_sleep_request_ms does not work

rozpruwacz — Wed, 03 Feb 2021 10:57:16 GMT

Hi Edvin,

Thanks for the response.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]Assuming you are using raw 802.15.4 and don't intend to use Zigbee then, right?[/quote]

yes.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]What do you see if you don't use sys_sleep_approver_register()? Does the device go to sleep for the correct amount of time when you call sys_sleep_request_ms()?[/quote]

No effect, the device is not going to sleep.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]

Did you remember to call sys_sleep_init() before calling sys_sleep_request_ms()?

[/quote]

Yes, at the application startup. But I guess that sys_sleep_init is already called by the sys_init.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]What is the sys_sleep_wakeup_reason() after you wake up immediately after calling sys_sleep_request_ms()[/quote]

It is 0.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]As I mentinoned in one of your previous tickets, this library is not much used, and noone currently working in Nordic is particularly familiar with it.[/quote]

Up until now this library is working good for me. The only problem is the documentation which does not describe very important things like resource ownership, api calls invariants, etc. This would be no problem if the source code was available.

on this page (https://www.nordicsemi.com/Software-and-tools/Software/802-15-4-software) I can read:

"For those who wish to utilize another protocol stack, or implement their own, we offer complete PHY and MAC support for the nRF52840 multiprotocol SoC."

Is it refering to 802.15.4 library that I use or the other piece of software ?

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]When I ask our network group about this library they will point us to the 802.15.4 driver used in the thread and zigbee SDK, so I guess they will do the same if I ask them about this.[/quote]

As I understand, the 802.15.4 driver You mention is this (https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver) and it is not a proper 802.15.4 mac layer implementation, so I would need to implement a lot more code. I can't find any documentation on it also.

[quote userid="26071" url="~/f/nordic-q-a/71174/802-15-4-sys_sleep_request_ms-does-not-work/292628#292628"]I have never tested the sleep implementation in the 802154 library. Do you have an example where you have set it up that I can test?[/quote]

Below is my test code and log output. It assumes that there is PAN coordinator on the other side, and the sys_sleep_request_ms is called only after succesfull association.

#include "config.h"
#include "ral_irq_handlers.h"
#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"
#include "nrf_delay.h"
#include "app_usbd.h"
#include "bsp.h"

#include "nrf_drv_clock.h"

#include "mac_mlme_pib.h"
#include "mac_mlme_reset.h"
#include "mac_mlme_scan.h"
#include "mac_mlme_associate.h"
#include "mac_mlme_sync.h"
#include "mac_mcps_data.h"
#include "sys_init.h"
#include "sys_memory_manager.h"
#include "sys_sleep.h"
#include "sys_task_scheduler.h"
#include "boards.h"

static mac_pan_descriptor_t pan_descriptor;
uint16_t my_addr = 0xFFFF;
static bool allow_sleep = false;
static sys_sleep_approver_id_t approver_id;

void mcps_data_ind(mcps_data_ind_t * p_ind)
{
    bool addresses_match = p_ind->dst_pan_id == pan_descriptor.coord_pan_id &&
                           p_ind->dst_addr_mode == pan_descriptor.coord_addr_mode &&
                           p_ind->dst_addr.short_address == my_addr &&
                           p_ind->src_pan_id == pan_descriptor.coord_pan_id;

    NRF_LOG_INFO("%d received success from %x", sys_time_get(), p_ind->src_addr.short_address);
    if (addresses_match && p_ind->msdu_length > 0)
    {
        if (bsp_board_led_state_get(CONFIG_DOWNSTREAM_PIN))
            bsp_board_led_off(CONFIG_DOWNSTREAM_PIN);
        else
            bsp_board_led_on(CONFIG_DOWNSTREAM_PIN);
    }
    mac_mem_msdu_free(&p_ind->msdu);
}

static void mcps_data_conf(mcps_data_conf_t * conf)
{
    if (conf->status == MAC_SUCCESS)
    {
        NRF_LOG_INFO("%d send success", sys_time_get());
        bsp_board_led_off(CONFIG_UPSTREAM_PIN);
    }
    else
    {
        NRF_LOG_INFO("%d send failed", sys_time_get());
    }
}

static void send_data()
{
    static uint8_t m_radio_tx_buffer[PHY_MAX_PACKET_SIZE + MAC_MAX_MHR_SIZE];
    static mcps_data_req_t m_data_req;
    NRF_LOG_INFO("%d send_data", sys_time_get());

    m_radio_tx_buffer[MAC_MAX_MHR_SIZE] = 'x';

    m_data_req.dst_addr_mode = pan_descriptor.coord_addr_mode;
    m_data_req.dst_addr = pan_descriptor.coord_address;
    m_data_req.dst_pan_id = pan_descriptor.coord_pan_id;
    m_data_req.src_addr_mode = MAC_ADDR_SHORT;
    m_data_req.msdu = (uint8_t *)&m_radio_tx_buffer[MAC_MAX_MHR_SIZE];
    m_data_req.msdu_length = 1;
    m_data_req.msdu_handle++;
    m_data_req.tx_options.ack = true;
    m_data_req.tx_options.gts = false;
    m_data_req.tx_options.indirect = false;
    mcps_data_req(&m_data_req, mcps_data_conf);

    bsp_board_led_on(CONFIG_UPSTREAM_PIN);
}

static void ext_addr_set()
{
    const pib_id_t pib_id =
    {
        .mlme_id = MAC_EXTENDED_ADDRESS,
    };
    uint64_t address = CONFIG_IEEE_ADDRESS + CONFIG_DEVICE_SHORT_ADDRESS;
    mac_status_t result = mlme_set(pib_id, 0, &address);
    NRF_LOG_INFO("ext_addr_set: %d", result);
}

//static void auto_request_set()
//{
//    const pib_id_t pib_id =
//    {
//        .mlme_id = MAC_AUTO_REQUEST,
//    };
//    uint8_t auto_request = 0;
//    mac_status_t result = mlme_set(pib_id, 0, &auto_request);
//    NRF_LOG_INFO("auto_request_set: %d", result);
//}

static void beacon_order_set(uint8_t beacon_order)
{
    const pib_id_t pib_id =
    {
        .mlme_id = MAC_BEACON_ORDER,
    };
    mac_status_t result = mlme_set(pib_id, 0, &beacon_order);
    NRF_LOG_INFO("beacon_order_set: %d", result);
}

static void mlme_associate_conf_cb(mlme_associate_conf_t * conf)
{
    NRF_LOG_INFO("%d mlme_associate_conf: %d", sys_time_get(), conf->status);
    if (conf->status == MAC_SUCCESS)
        bsp_board_led_on(CONFIG_INIT_DONE_PIN);
    else
        bsp_board_led_off(CONFIG_INIT_DONE_PIN);

    my_addr = conf->assoc_short_address;
    NRF_LOG_INFO("short_address: %x", my_addr);
    allow_sleep = true;
}

static void log_mac_pan_descriptor(const mac_pan_descriptor_t *mac_pan_descriptor)
{
    NRF_LOG_INFO("coord_addr_mode: %d", mac_pan_descriptor->coord_addr_mode);
    NRF_LOG_INFO("coord_pan_id: %x", mac_pan_descriptor->coord_pan_id);
    NRF_LOG_INFO("coord_address.short_address: %x", mac_pan_descriptor->coord_address.short_address);
    NRF_LOG_INFO("coord_address.long_address: %x", mac_pan_descriptor->coord_address.long_address);
    NRF_LOG_INFO("logical_channel: %d", mac_pan_descriptor->logical_channel);
    NRF_LOG_INFO("superframe_spec.beacon_order %d", mac_pan_descriptor->superframe_spec.beacon_order);
    NRF_LOG_INFO("superframe_spec.superframe_order %d", mac_pan_descriptor->superframe_spec.superframe_order);
    NRF_LOG_INFO("superframe_spec.final_cap_slot %d", mac_pan_descriptor->superframe_spec.final_cap_slot);
    NRF_LOG_INFO("superframe_spec.battery_life_extension %d", mac_pan_descriptor->superframe_spec.battery_life_extension);
    NRF_LOG_INFO("superframe_spec.pan_coordinator %d", mac_pan_descriptor->superframe_spec.pan_coordinator);
    NRF_LOG_INFO("superframe_spec.association_permit %d", mac_pan_descriptor->superframe_spec.association_permit);
    NRF_LOG_INFO("gts_permit %d", mac_pan_descriptor->gts_permit);
    NRF_LOG_INFO("link_quality %d", mac_pan_descriptor->link_quality);
    NRF_LOG_INFO("timestamp %d", mac_pan_descriptor->timestamp);
}

static void mlme_scan_conf_cb(mlme_scan_conf_t * conf)
{
    NRF_LOG_INFO("%d mlme_scan_conf: %d", sys_time_get(), conf->status);
    if (conf->status != MAC_SUCCESS)
        return;
    NRF_LOG_INFO("unscanned channels: %x", conf->unscanned_channels);
    NRF_LOG_INFO("results: %d",conf->result_list_size);
    if (conf->result_list_size == 0)
        return;
    NRF_LOG_INFO("first result");
    pan_descriptor = conf->pan_descriptor_list[0];
    log_mac_pan_descriptor(&pan_descriptor);

    {
        beacon_order_set(pan_descriptor.superframe_spec.beacon_order);
        static mlme_sync_req_t req;
        req = (mlme_sync_req_t){
            .logical_channel = pan_descriptor.logical_channel,
            .track_beacon = true
        };
        NRF_LOG_INFO("syncing to channel %d", req.logical_channel);
        mlme_sync_req(&req);
    }

    static mlme_associate_req_t req;
    req = (mlme_associate_req_t){
        .logical_channel = pan_descriptor.logical_channel,
        .coord_addr_mode = pan_descriptor.coord_addr_mode,
        .coord_pan_id = pan_descriptor.coord_pan_id,
        .coord_address = pan_descriptor.coord_address,
        .capability_information = {
            .alternate_pan_coordinator = 0,
            .device_type = 0,
            .power_source = 0,
            .rx_on_when_idle = 0,
            .reserved = 0,
            .security_capability = 0,
            .allocate_address = 1
        }
    };
    mlme_associate_req(&req, mlme_associate_conf_cb);
}

void mlme_reset_conf_cb(mlme_reset_conf_t *conf)
{
    NRF_LOG_INFO("%d mlme_reset_conf: %d", sys_time_get(), conf->status);
    if (conf->status != MAC_SUCCESS) {
        bsp_board_led_off(CONFIG_INIT_DONE_PIN);
        return;
    }

    ext_addr_set();

    static mac_pan_descriptor_t pan_descriptors_buf[2];
    static mlme_scan_req_t req = {
        .scan_type = ACTIVE_SCAN,
        .scan_channels = (1 << 15), //PHY_CHANNEL_SUPPORTED,
        .scan_duration = 8,
        .pan_descriptors_buf_size = sizeof(pan_descriptors_buf) / sizeof(pan_descriptors_buf[0]),
        .pan_descriptors_buf = pan_descriptors_buf,
        .energy_detect_buf_size = 0,
        .energy_detect_buf = NULL,
    };
    mlme_scan_req(&req, mlme_scan_conf_cb);
}

static void out_of_memory_callback(const void * data)
{
    bsp_board_led_on(CONFIG_ERROR_PIN);
}

static void memory_freed_callback(const void * data)
{
    bsp_board_led_off(CONFIG_ERROR_PIN);
}

static void falling_asleep_callback(const void * data)
{
    NRF_LOG_INFO("%d falling_asleep_callback", sys_time_get());
    sys_sleep_approve(approver_id);
}

static void wake_up_callback(const void * data)
{
    NRF_LOG_INFO("%d wake_up_callback", sys_time_get());
}

/**@brief   Application task initialization for GPIO test.
 */
static void app_task_init(void)
{
    static sys_event_desc_t m_out_of_memory_desc = {
        .event_id = SYS_EVENT_OUT_OF_MEMORY,
        .callback = out_of_memory_callback,
    };
    static sys_event_desc_t m_memory_freed_desc = {
        .event_id = SYS_EVENT_MEMORY_FREED,
        .callback = memory_freed_callback,
    };
    static sys_event_desc_t m_falling_asleep_desc = {
        .event_id = SYS_EVENT_FALLING_ASLEEP,
        .callback = falling_asleep_callback,
    };
    static sys_event_desc_t m_wake_up_desc = {
        .event_id = SYS_EVENT_WAKE_UP,
        .callback = wake_up_callback,
    };
    static uint8_t __ALIGN(ALIGN_VALUE) m_heap[CONFIG_POOL_SIZE];
    static const size_t m_heap_size = CONFIG_POOL_SIZE;

    sys_init(m_heap, m_heap_size);
    sys_sleep_init();
    approver_id = sys_sleep_approver_register(&m_falling_asleep_desc, &m_wake_up_desc);
    NRF_LOG_INFO("aprover id is %d", approver_id);

    sys_event_subscribe(&m_out_of_memory_desc);
    sys_event_subscribe(&m_memory_freed_desc);
    //sys_event_subscribe(&m_falling_asleep_desc);
    //sys_event_subscribe(&m_wake_up_desc);

    static mlme_reset_req_t req = {
        .set_default_pib = true
    };
    mlme_reset_req(&req, mlme_reset_conf_cb);
}

void mlme_sync_loss_ind(mlme_sync_loss_ind_t * ind)
{
    NRF_LOG_INFO("%d mlme_sync_loss for PAN ID: %x on channel %d", sys_time_get(), ind->pan_id, ind->logical_channel);
    NRF_LOG_INFO("reason: %d", ind->loss_reason);
}

void mlme_beacon_notify_ind(mlme_beacon_notify_ind_t *ind)
{
    NRF_LOG_INFO("%d mlme_beacon_notify_ind bsn: %d", sys_time_get(), ind->bsn); 
    mac_mem_msdu_free(&ind->sdu);
}

static void clock_init(void)
{
    ret_code_t err_code = nrf_drv_clock_init();
    ASSERT((err_code == NRF_SUCCESS) || (err_code == NRF_ERROR_MODULE_ALREADY_INITIALIZED));

    nrf_drv_clock_hfclk_request(NULL);
    while (!nrf_drv_clock_hfclk_is_running())
    {
        // spin lock
    }

    nrf_drv_clock_lfclk_request(NULL);
    while (!nrf_drv_clock_lfclk_is_running())
    {
        // spin lock
    }
}

/**
 * @brief Function for application main entry.
 */
int main(void)
{
    ral_irq_handler_import();
    clock_init();
    APP_ERROR_CHECK(bsp_init(BSP_INIT_LEDS | BSP_INIT_BUTTONS, NULL));
    bsp_board_leds_off();
    APP_ERROR_CHECK(app_usbd_init(NULL));
    app_usbd_enable();
    app_usbd_start();
    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    for (int i=0; i<300; i++)
    {
        while (app_usbd_event_queue_process());
        if (i % 2)
            bsp_board_leds_off();
        else
            bsp_board_leds_on();
        nrf_delay_ms(10);
    }
    bsp_board_leds_on();
    NRF_LOG_INFO("Blinky device example started.");
    bsp_board_leds_off();

    app_task_init();

    bool prev_button = bsp_board_button_state_get(CONFIG_BTN_DATA_SEND);
    bool curr_button = 0;
    while (true)
    {
        while (app_usbd_event_queue_process());
        sys_task_run();
        curr_button = bsp_board_button_state_get(CONFIG_BTN_DATA_SEND);
        if (prev_button == 0 && curr_button == 1) {
            send_data();
        }
        prev_button = curr_button;
        if (allow_sleep) {
            allow_sleep = false;
            NRF_LOG_INFO("%d going sleep", sys_time_get());
            sys_sleep_request_ms(10000);
            NRF_LOG_INFO("%d woke up, reason: %d", sys_time_get(), sys_sleep_wakeup_reason());
        }
    }
}

<info> app: Blinky device example started.
<info> app: aprover id is 0
<info> app: 1138 mlme_reset_conf: 0
<info> app: ext_addr_set: 0
<info> app: 3952220 mlme_scan_conf: 0
<info> app: unscanned channels: 0
<info> app: results: 1
<info> app: first result
<info> app: coord_addr_mode: 2
<info> app: coord_pan_id: 1234
<info> app: coord_address.short_address: A
<info> app: coord_address.long_address: A
<info> app: logical_channel: 15
<info> app: superframe_spec.beacon_order 7
<info> app: superframe_spec.superframe_order 5
<info> app: superframe_spec.final_cap_slot 15
<info> app: superframe_spec.battery_life_extension 0
<info> app: superframe_spec.pan_coordinator 1
<info> app: superframe_spec.association_permit 1
<info> app: gts_permit 1
<info> app: link_quality 255
<info> app: timestamp 1654218
<info> app: beacon_order_set: 0
<info> app: syncing to channel 15
<info> app: 7560187 mlme_associate_conf: 0
<info> app: short_address: CDFA
<info> app: 7560666 going sleep
<info> app: 7560834 falling_asleep_callback
<info> app: 7561030 wake_up_callback
<info> app: 7561217 woke up, reason: 0

Best regards,

Marek Czerski

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Wed, 03 Feb 2021 09:46:26 GMT

Ok,

Assuming you are using raw 802.15.4 and don't intend to use Zigbee then, right?

What do you see if you don't use sys_sleep_approver_register()? Does the device go to sleep for the correct amount of time when you call sys_sleep_request_ms()?

Did you remember to call sys_sleep_init() before calling sys_sleep_request_ms()?

What is the sys_sleep_wakeup_reason() after you wake up immediately after calling sys_sleep_request_ms()

As I mentinoned in one of your previous tickets, this library is not much used, and noone currently working in Nordic is particularly familiar with it. When I ask our network group about this library they will point us to the 802.15.4 driver used in the thread and zigbee SDK, so I guess they will do the same if I ask them about this.

I have never tested the sleep implementation in the 802154 library. Do you have an example where you have set it up that I can test?

BR,
Edvin

RE: 802.15.4 sys_sleep_request_ms does not work

rozpruwacz — Tue, 02 Feb 2021 15:34:29 GMT

infocenter.nordicsemi.com/.../group__sys__sleep.html

RE: 802.15.4 sys_sleep_request_ms does not work

Edvin — Tue, 02 Feb 2021 15:16:55 GMT

I can't find any references to sys_sleep_request_ms in the SDK. Where did you find this?

If you are still planning on learning about 802.15.4 before you start developing using zigbee, please be aware that the Zigbee stack from the SDK uses a different 802.15.4 stack, and that you don't use the 802.15.4 stack directly when using the zboss stack (the name of the Zigbee stack).