Power consumption is too high

[Sergio T]

I am using the PCA10028 to connect to my board and use Segger embedded studio. I am unable to bring my power consumption below 1 mA.

To exclude my hardware from the equation, I decided to connect the EEPROM I´m using (24LC16) and one key to the PCA10028 board and use the nRF current measurement feature. I soldered a 22 Ohm resistor on R6 and loaded my program into it. 

The program is very simple: if key is ON I have BLE advertising and all runs.

If key is OFF, then I stop BLE advertising and only keep my app_timer running on RTC1. I tried also stopping the timer and the result is the same. I get 1 mA consumption.

I tried performing NRF_POWER->SYSTEMOFF = 1; instruction but the controller doesn't stop (I made an endless loop with this instruction and toggle of a LED) and the code just ignores the command and continues running, even if I don't connect the board to the PC (use then a battery for supply).

I tried also NRF_POWER->TASKS_LOWPWR = 1; but it also doesn't work.

I tried __WFE(); __SEV(); and even __WFI(); but none seams to work. 

What am I doing wrong?

[Sergio T]

For information, here is my main loop:

//-------------------------------------
/**@brief Application main function.
 */
//-------------------------------------
int main(void)
{
    uint32_t err_code;

// ---- Initialize ckock timer ----
    
    APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_OP_QUEUE_SIZE, false);
    err_code = app_timer_create(&real_time_clock_id, APP_TIMER_MODE_REPEATED, rtc_handler);
    app_timer_start(real_time_clock_id, 32767, false);
    
// ---- Initialize kernel timer ----
    err_code = app_timer_create(&kernel_clock_id, APP_TIMER_MODE_REPEATED, kernel_handler);
// ----
#ifdef USE_BLE
    ble_stack_init();
    gap_params_init();
    services_init();
    advertising_init();
    conn_params_init();
#endif
//    configure_ram_retention();
#ifdef DEBUG_PRINT
    printf("\r\nUART Start after RESET!\r\n");
    printf("BT Disconnected");
    printf("\r\n");
#endif
    InitIo();
    CheckWarmCold();      // chek if EEPROM was initialized
    ClearRxString();      // clear BLE receive buffer
    f_key_was_on = 0;
    f_power_is_on = 0;    
    InitIo();             // configure ports
    for (;;)
      {
      power_manage();
      if (f_power_is_on)
        {
        if (f_data_rx)
          {
          f_data_rx = 0;
#ifdef DEBUG_PRINT
          printf("RX: ");
          printf(rx_string);
          printf("\r\n");
#endif
          if (ParseMessage())           // parse command to rx_data[]
            {
            ClearRxString();            // clear rx_buffer for next communication
            ExecuteMessage();
            }
          else
            ClearRxString();            // message invalid: clear rx_buffer for next communication
          }
        if (f_data_tx)
          {
          f_data_tx = 0;
#ifdef DEBUG_PRINT
          printf("TX: ");
          printf(tx_string);
          printf("\r\n");
#endif
          ble_nus_string_send(&m_nus, tx_string, tx_string_len);
          }
        }
      CheckPowerKey();                // check power key
      if (f_power_is_on)
        {
        CheckScheduling();
        UpdatePumpOperation();
        Timers();
        UpdateLed();
        }
      }
}

[Sergio T]

and the Check Power Key routine:

//-------------------------------------
void CheckPowerKey(void)
{
  if (f_key_was_on)
    {
#ifdef DEMO_BOARD
    if (nrf_gpio_pin_read(K_PWR) || !nrf_gpio_pin_read(PDN))
#else
    if (!nrf_gpio_pin_read(K_PWR) || !nrf_gpio_pin_read(PDN))
#endif
      {
      f_key_was_on = 0;   // key changed ON -> OFF
      }
    else // Key is On and not PDN: => switch on if was off
      {
      if (!f_power_is_on)
        {
        f_power_is_on = 1;
        PowerOffToOn();
        first_minute = 60;
        StartBLE();       // start BLE and kernel_int
        RebuildActionSequence();
//        ReloadOnPeriod();
//        ReloadOffPeriod();
        if (!po_on_period)
          po_on_period = TEST_ON_PERIOD;
        }
      }
    }
  else // f_key_was_on = 0
    {
#ifdef DEMO_BOARD
    if (!nrf_gpio_pin_read(K_PWR) && nrf_gpio_pin_read(PDN))
#else
    if (nrf_gpio_pin_read(K_PWR) && nrf_gpio_pin_read(PDN))
#endif
      {
      f_key_was_on = 1;       // key changed OFF -> ON
      }
    else // Power key is OFF: => switch off if it was on
      {
      if (f_power_is_on)
        {
        StopBLE();       // stop BLE and kernel_int
        f_power_is_on = 0;
        first_minute = 0;
        PowerOnToOff();
        }
      }
    }
}

[Jared]

Hi,

 Before we proceed we need to verify your measurement setup. You should measure around 4 µA with the example that I shared in my previous reply, if you measure anything else then your measurement setup is not correct. Can you confirm what you measure with the Power management example, is that 9 µA?

Also if the debug connector is connected then the chip will be in debug mode. The chip will never go to system off in debug mode, it will only emulate it, and the HFCLK will be kept active which will consume current, around a 1mA which explains what you measure. If you want to measure current then chip can't be in debug mode. 

regards

Jared 

[Sergio T]

Hi Jared:

Thanks for your reply. My measurement setup is probably not 100% accurate as I am measuring with too less resolution. Still the differences are there.

I am not able to compile the power management project because I don't have a compatible development environment (I don't remember anynmore how I did it, as it was 5 years ago I started this!). 

Still, I would expect that changing the main.c and the sdk_config files would make the job, because all the rest is the same, but it doesn't work!

If I disconnect the USB and supply with a battery, then I would assume that the board would not work in DEBUG mode. Still I see similar consumption. How can I prevent or disconnect the DEBUG mode?

I think it is better I make another question:

Do you have any documentation explaining how to select and configure the peripherals we need using the code you provide in your examples?

How can I set the controller to sleep? NRF_POWER->SYSTEMOFF = 1; doesn't work!

How can I stop the 16 MHz clock? I can't see any oscillation with an oscilloscope, so I assume it is OFF, but the consumption says otherwise!

There must be some instructions that do the job!

The production of the final product is stopped because of the power consumption issue, now that a battery backup for the time was implemented.

Kind regards

Sergio

[Jared]

Hi,

Sergio T said:

I am not able to compile the power management project because I don't have a compatible development environment (I don't remember anynmore how I did it, as it was 5 years ago I started this!). 

There is already pre-compiled hex in the hex folder of the example, so there is no need to compile it. Just use nRF Command Line Tools or nRF Connect Programmer app to program the example to your board.

Sergio T said:

If I disconnect the USB and supply with a battery, then I would assume that the board would not work in DEBUG mode. Still I see similar consumption. How can I prevent or disconnect the DEBUG mode?

The device will exit DEBUG mode after a power cycle. Just make sure that you don't connect to RTT or start a debug session and the device will not enter DEBUG Mode.

Sergio T said:

How can I set the controller to sleep? NRF_POWER->SYSTEMOFF = 1; doesn't work!

To summarize, there is 2 kinds of sleep. There is SYSTEM OFF sleep where everything is turned off including all Timers and internal CLOCKs. This is the lowest kind of power saving mode the nRF can enter. An exit from System Off sleep will always result in a reset.

The other kind of sleep is System On sleep (IDLE sleep). This will use more power than system off sleep. In IDLE sleep Timer and Clock can be active, it depends on your application. The CPU will exit System On (IDLE) sleep if an interrupt or event is generated, it will not reset the system when it exits System On sleep.

NRF_POWER->SYSTEMOFF is indeed the correct method to enter system off sleep. If you use the softdevice then you have to go trough the Softdevice API and use 

sd_power_system_off(). If you can't see the current consumption decrease when you enter System Off sleep then either the device is woken up from System Off sleep immediately, or your current measurement setup is not correct. If you could try the example I suggested and put the device to System Off sleep by pressing button 1 then we could confirm whether your measurement setup is correct or not. 

 

regards

Jared 

[Sergio T]

While updating the nRF Connect App (Programmer was not working because out of date), it destroyed my Segger Embedded Studio. Now it can no longer run the code on my target board! 

Any idea what could be? 

I can compile and download to the board but the program crashes.

I restored my computer from a previous backup of the PC but it still doesn't work.

The software crashes when app_timer_start is called. I followed step-by-step and it crashes when it returns from the function. Does this mean the addresses on the controller are wrong? 

I noticed there was no more Section Placement Macro so I defined again with te following settings:

FLASH_PH_START=0x0

FLASH_PH_SIZE=0x100000

RAM_PH_START=0x20000000

RAM_PH_SIZE=0x40000

FLASH_START=0x1B000

FLASH_SIZE=0xE5000

SRAM_START=0x20002080

SRAM_SIZE=0x1F80

I believe these are right. Still the software crashes when app_timer_start is called.

Any idea?

Kind regards

Sergio

[Jared]

Hi,

This problem is not directly related to your original question regarding power consumption. I would suggest that you create a new ticket for this, so that we can focus in this discussion on resolving your original issue.

You can always use nRF Command Line Tools to program your board if nRF Connect Programmer doesn't work.

regards

Jared 

[Sergio T]

Yes. This is another problem! I tried during 2 days to solve the toolchain crash problem without success!

I did however succeed to flash the power management example and the consumption is nearly 0 when system is off (my voltmeter measure 0.0 mV over 22 Ohm).  This confirms that my measurement setup is correct.

As you can see by my history, this has been a recurrent problem in this project for years!

I give up!

I am handing over the project to someone else and it is up to him to solve or change to another solution.

Anyway, thanks for your support, although it really didn't help.

Kind regards

Sergio