CPU dont go to sleep

Hi!

I am using nrf32840 with free rtos,

and I have a loop that do the following

for(;;){

    vTaskDelay(pdMS_TO_TICKS(intervalTime)); // go to sleep due to portSUPPRESS_TICKS_AND_SLEEP( xExpectedIdleTime );

 

    // do some work

}

 

The problem is as follow:

In most of my devices, the CPU goes to a deep sleep mode and the current is 200micro,

 

In some of my devices, it seems that the CPU don’t go to sleep, and the current is bigger then 6mA,

 

In some other devices the problem sometimes occurs and sometimes not...

 

 

I tried the following with the devices that always do has the problem:

  1. Write the example hex of ble_app_hrs_freertos.hex, and the current was 200micro, so it seems that the micro controller is fine.
  2. check if I get unexpected interrupts, so I used __disable_irq() sd_nvic_critical_region_enter(), but it doesn’t seem to help as well.
  3. I used a debugger and made sure it got to the idle task and the portSUPPRESS_TICKS_AND_SLEEP() function had been called.

 

 

I am out of ideas, do you have any suggestion why that could happen, and how to solve it?

Parents
  • Hi,

    I tried the following with the devices that always do has the problem:

    1. Write the example hex of ble_app_hrs_freertos.hex, and the current was 200micro, so it seems that the micro controller is fine.

    Not sure if I understand this first point correct. If you have the hex file that is giving proper power consumption in the devices working correctly and used this hex file in the faulty devices and if that is also working fine, then it seems that the app binary and the chips are fine. 

    Have you tried to compare the two hexes which causes correct and faulty behavior?

    Also you can use SystemView to understand of there are any contexts or times where the chip is waking up unnecessarily.

    From the description you gave, it is hard for me to narrow down the problem to anything as I do not know anything about your application or the custom boards.

  • Hi, thanks for the quick response!

    I given the ble_app_hrs_freertos.hex file to the faulty devices, and they seems to work properly, with current of 200micro.

    Now say that I have a file: myApp.hex

    If I give it to the working correctly devices, the current is 200micro

    If I give them to the faulty devices, the current is 6mA

    I will check about the SystemView maybe it will be helpful, thanks!

    Yes I understand that I didnt gave you enough info about myApp, I will try to summarize it in more proper and informative way, and will send it.

    Anyway, if you have more ideas in mind to how to debug it, or what the cause might be, I would be happy to hear!

Reply
  • Hi, thanks for the quick response!

    I given the ble_app_hrs_freertos.hex file to the faulty devices, and they seems to work properly, with current of 200micro.

    Now say that I have a file: myApp.hex

    If I give it to the working correctly devices, the current is 200micro

    If I give them to the faulty devices, the current is 6mA

    I will check about the SystemView maybe it will be helpful, thanks!

    Yes I understand that I didnt gave you enough info about myApp, I will try to summarize it in more proper and informative way, and will send it.

    Anyway, if you have more ideas in mind to how to debug it, or what the cause might be, I would be happy to hear!

Children
  • Novo said:

    If I give it to the working correctly devices, the current is 200micro

    If I give them to the faulty devices, the current is 6mA

    How many faulty devices do you have? Is it like 1 in 100 or like 1 in 10.

    It also depends if you have a custom device or working on the nRF53 DK?

    Can you test your application hex file in the nrf53DK if you have not done that already?

    What I am trying here is to exclude few things to see if we need to focus on the hardware issue or the software issue.

Related