power consumption is too high on my nrf52 SoC

[Juliusc]

Hi, 

I am currently trying to decrease my power output, for this purpose I used a power profiler and found this pattern:

I am using a test firmware that just disables all unused gpio ports, start ble and then goes into while(1){ __WFE();}

power consumption is never below 400uA, the spikes seem fine (BLE advertising spikes I presume).

s there anything you can tell me about why this would happen?

Even if I turn of BLE I still got 200uA on average, so some of the problem is probably in my configuration (but. already increased the adv intervals) and part of it is the chip by itself. I am using a custom PCB but am pulling down all GPIO ports

Best, Julius

[Vidar Berg]

Hi Julius,

Unused pins can be left floating without affecting the sleep current as GPIO pins are configured as inputs with the input buffer disconnect after reset. 

Are you developing with the nRF Connect SDK or the nRF5 SDK? 

Best regards,

Vidar

[Juliusc]

nRF5 SDK

I see I noticed that the current is a bit higher when I dont set certain gpio pins to clear specifically. 

[Vidar Berg]

Thanks for confirming. Did you check what pin configuration of those pins were first? Also, are these pins connected to anything on your board?

[Juliusc]

yes I have a radar chip connected to those pins, though this isnt really the problem that I see with my power. Or do you think theres more to that?

One of the pins is connected with a not-gate maybe this is the reason why some current was drawn through that. 

[Vidar Berg]

Is the radar chip powered from the power rail as the nRF5, and is it possible that you may say current leakage from this IC if the nRF5 is no driving the pins to a defined state?

[Juliusc]

yeah some leakage comes from there, like around 220uA, I know this, since I also used a fw that just says NRF_POWER->SYSTEMOFF = 1; and thats the current I see then. this still doesnt explain the residual 200uA when using BLE

[Vidar Berg]

You can also see leakage from IOs in System OFF as the GPIO peripheral configurations are retained in OFF mode. Is possible to cut the power to the radar IC, or is it powered with the nRF?

Juliusc said:

and thats the current I see then. this still doesnt explain the residual 200uA when using BLE

Not sure I understand the relation with BLE. Does the floor current increase when you enable BLE?

[Juliusc]

yes, its 450uA on average if I turn on BLE (as seen in the image provided)

without BLE its 220 on average but as I said I want to focus on the BLE problem first. 

[Vidar Berg]

You should be able to see the sleep/floor current between advertising events (assuming the spikes are BLE events and not some other noise). 

Do you start an advertiser after you enable BLE? In that case, what interval are you advertising at? 

[Juliusc]

yeah exactly thats why i made this thread I never see like near 0 current or 'real' sleeping intervals its just always like this, my advertising interval is around 300ms 

the event where my arrow is pointing is supposed to be the advertising I think:

[Vidar Berg]

Are you able to share your main() function here?

[Juliusc]

int main(void) {

  gpio_init();

  ble_init();

  flash_init();

  ble_advertise();

  while (1) {
     __WFE();
  }

}

gpio_init as I said just initializes (clears) some pins, ble_init() does the usual initialization of services etc, in flash init I just read from flash so no further interefering processes from there, I also have no scheduler enabled. I also tried sd_app_evt_wait() but no difference here