Overconsumption when there is no softdevice but with FreeRTOS

[Aurele]

Hello,

i'm working on a NRF52810 on which i have ported FreeRTOS because i'm sharing library with another NRF52832 that embeds FreeRTOS too.

I'm issueing an overconsomption on this NRF52810 since i removed the softdevice and i don't know why. I'm testing on an evaluation board so that we can be totally decorrelated from our hardware. 

If i call WFE/WFI before initializing clock like the following : 

int main(void)
{
    // Initialize low level driver
    timer_init();
    log_init();
    while(1)
    {
        // Wait for an event.
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

    clock_init();

I have 4.5uA of consumption

But if do it after the clock_init :

    // Initialize low level driver
    timer_init();
    log_init();
    clock_init();
    while(1)
    {
        // Wait for an event.
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

I have around 470uA. Is that normal ?

WFE/WFI is supposed to be called by nrf_pwr_mgmt_run in my iddle task. What i guess is that it seems nrf_pwr_mgmt_run is not stopping all clock. Am i right ?

Best regards,

Aurélien

[Susheel Nuguru]

Hi Fillau,

 If you do it before the clock init

I have 4.5uA of consumption

This is because you are not starting the lfclk that is required for the rtos tick and sleeping before starting lfclk gives you best measurement since your application is doing nothing.

 

But if do it after the clock_init :

I have around 470uA. Is that normal ?

470uA is a lot. I do not think this is normal. And I am not able to replicate this with your project on the nRF52810 DK. I have added the while loop with WFE before and after and I only see couple of uA of difference which should be equal the lfclk powre consumption.

Are you testing this on a custom board?

[Aurele]

Hi Susheel,

I finally figured it out .  The overconsumption is coming from this piece of code : 

    nrf_drv_gpiote_in_config_t config = GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
    config.pull = NRF_GPIO_PIN_PULLUP;
    nrf_drv_gpiote_in_init(IQS263_INT_PIN, &config, interrupt_iqs263_handler);

If i change "true" to "false" in GPIOTE_CONFIG_IN_SENSE_HITOLO(true); the overconsumption disappears.

The same code is also executed on a nRF52832, and on it, i cannot see the overconsmption, it is only appearing on the nRF52810 !

[Susheel Nuguru]

This pretty much sounds like the workaround for ERRATA 155 has been turned on which keeps the clock on, but it looks like it is same for nRF52832 and nRF52810. If you have written code to disable the workaround for the GPIOTE after use, then it should have worked on nRF52810 also. Something does not seem right.

Can you please check if the code on nRF52810 and nRF5832 has used the workaround for 155 in the same fashion?