Ask about power consumtion of nrf52833 with esb_tx example

[Quangca]

Hi Nordic support team.

I incharg project replace NRF24l01 by new design with nrf52833.

Using nRF5_SDK_17.0.2 and segger studio compiler.

I using esb_tx example, the application running well.

But it seem take so much power consumtion. i try to modify code in main function like this nothing to do only sleep mode like this.

int main(void)
{
    ret_code_t err_code;
    gpio_init();
    clocks_start();

    err_code = esb_init();
    APP_ERROR_CHECK(err_code);

    while (true)
    {
            __WFE();
            __SEV();
            __WFE();
    }

}

But when measure power consumtion i see that always 270uA. It happened the same eventhrough i commented //gpio_init() function

Can you help me check about that. i expect down to 25uA.

thank and best regards,

[Susheel Nuguru]

I have not tested this but seems like there is one errata on this chip where you need to apply a workaround. Have you tried applying the workaround mentioned in the errata?

[Quangca]

Hello, Susheel Nuguru.

i check with errata, and see that:

Apply the following code after any reset:

*(volatile uint32_t *)0x4007AC84ul = 0x00000002ul;

Where to put this code? is it the first line of main() function?

i chek part number of my chip set: NRF52833-QDAAB02204AA

I put it like this code, issue the same.

int main(void)
{
    *(volatile uint32_t *)0x4007AC84ul = 0x00000002ul;
    
    ret_code_t err_code;
    gpio_init();
    clocks_start();

    err_code = esb_init();
    APP_ERROR_CHECK(err_code);

    while (true)
    {
            __WFE();
            __SEV();
            __WFE();
    }

}

I also refer on some topics on devzone it guide to check HFCLK but not clearly.

[Susheel Nuguru]

Nguyen, It should be enough to apply this workaround in the early bootup time like you did in your code and forget about it.

Did it help with the power consumption after adding this workaround?

[Quangca]

It seem not resolve my issue, power consumption is the same 270uA.

I am researching more on devzone.

Can you predict some main reason? 

HFCLK  is the reason? 

below is example code:

static nrf_esb_payload_t        tx_payload = NRF_ESB_CREATE_PAYLOAD(0, 0x01, 0x00, 0x00, 0x00, 0x11, 0x00, 0x00, 0x00);

static nrf_esb_payload_t        rx_payload;

void nrf_esb_event_handler(nrf_esb_evt_t const * p_event)
{
    switch (p_event->evt_id)
    {
        case NRF_ESB_EVENT_TX_SUCCESS:
            NRF_LOG_DEBUG("TX SUCCESS EVENT");
            break;
        case NRF_ESB_EVENT_TX_FAILED:
            NRF_LOG_DEBUG("TX FAILED EVENT");
            (void) nrf_esb_flush_tx();
            (void) nrf_esb_start_tx();
            break;
        case NRF_ESB_EVENT_RX_RECEIVED:
            NRF_LOG_DEBUG("RX RECEIVED EVENT");
            while (nrf_esb_read_rx_payload(&rx_payload) == NRF_SUCCESS)
            {
                if (rx_payload.length > 0)
                {
                    NRF_LOG_DEBUG("RX RECEIVED PAYLOAD");
                }
            }
            break;
    }
}


void clocks_start( void )
{
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART = 1;

    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
}


void gpio_init( void )
{
    nrf_gpio_range_cfg_output(8, 15);
    bsp_board_init(BSP_INIT_LEDS);
}


uint32_t esb_init( void )
{
    uint32_t err_code;
    uint8_t base_addr_0[4] = {0xE7, 0xE7, 0xE7, 0xE7};
    uint8_t base_addr_1[4] = {0xC2, 0xC2, 0xC2, 0xC2};
    uint8_t addr_prefix[8] = {0xE7, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7, 0xC8 };

    nrf_esb_config_t nrf_esb_config         = NRF_ESB_DEFAULT_CONFIG;
    nrf_esb_config.protocol                 = NRF_ESB_PROTOCOL_ESB_DPL;
    nrf_esb_config.retransmit_delay         = 600;
    nrf_esb_config.bitrate                  = NRF_ESB_BITRATE_2MBPS;
    nrf_esb_config.event_handler            = nrf_esb_event_handler;
    nrf_esb_config.mode                     = NRF_ESB_MODE_PTX;
    nrf_esb_config.selective_auto_ack       = false;

    err_code = nrf_esb_init(&nrf_esb_config);

    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_base_address_0(base_addr_0);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_base_address_1(base_addr_1);
    VERIFY_SUCCESS(err_code);

    err_code = nrf_esb_set_prefixes(addr_prefix, NRF_ESB_PIPE_COUNT);
    VERIFY_SUCCESS(err_code);

    return err_code;
}

int main(void)
{
    ret_code_t err_code;
    gpio_init();
    clocks_start();

    err_code = esb_init();
    APP_ERROR_CHECK(err_code);

    while (true)
    {
            __WFE();
            __SEV();
            __WFE();
    }

}

[Susheel Nuguru]

250uA seems like it is the HFCLK, but I am unsure why esb_init is keep the hfclk active. 

I thought you are just initializing the esb, so whatever you have in the esb_event_handler should not contribute the the current consumption as it is never called. So my focus now is to see how esb_init is contributing to the current.

Is this a custom board or are you testing this on the DK? I can try to test this on DK if you can reproduce this on DK.