• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 91 subscribers
  • Views 547 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 286332
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Migrating an older product from S110 to S130 and I'm having trouble with power consumption in sd_power_system_off

Glen M

Hi,

I've been upgrading a product we designed some years ago with the S110 softdevice on an nRF51822 to use S130 and nRF5x SDK version 12.3 so that we can use the more modern bootloader.

So far the transition has gone pretty well and I've got almost everything done and working - but I started comparing the power consumption today and it's way off. This device goes into OFF mode after awhile and it waits on a falling edge from a GPIO pin to wake up. With the old code, the board is drawing about 90uA while waiting to wake up. With the new code it's more like 300uA.

Since I was having trouble figuring out the issue, I decided to eliminate as much code as I could - so I changed my main routine to just wake up, initialize my IO pins, the softdevice, and the hardware on board to minimize power consumption and then I go straight into sd_power_system_off, but it's still drawing ~300uA.

I've tried the different CLOCK_CONFIG_LF_SRC options - didn't seem to make a difference (does the LF clock even run in system off mode?)

What else can I try? Does the S130 softdevice do something that the S110 didn't that makes it draw more power in the OFF state? 

I started my project from the "Blinky" example before porting my code in. Is there something that's turned on in that sdk_config that makes it draw more power than it could?

Thanks,

Glen

Parents
  • +1

    I don't remember the system OFF current in the back of my head, but it's typically sub 1uA. So if you are measuring more than this, then it is likely a GPIO that is either floating with undefined input level, or sinking or sourcing current through a output pin. If it's the first you should see a change in current by simply moving the finger over the chip and components and/or just poke with a 1Mohm resistor to ground around the pins to see which is the likely culpit.

    Kenneth

Reply
  • +1

    I don't remember the system OFF current in the back of my head, but it's typically sub 1uA. So if you are measuring more than this, then it is likely a GPIO that is either floating with undefined input level, or sinking or sourcing current through a output pin. If it's the first you should see a change in current by simply moving the finger over the chip and components and/or just poke with a 1Mohm resistor to ground around the pins to see which is the likely culpit.

    Kenneth

Children
  • 0 in reply to Kenneth

    I'm going to mark this as solved - I think my issue was primarily related to not getting some hardware on the board properly shut down, plus difficulty measuring due to a supercap on the board.

    I did learn one valuable thing from this - it's well documented but it just didn't sink in when I first developed this firmware: you don't come back where you left off with sd_power_system_off. When you "wake up" from that, it's a reset event. I had unnecessary code in there trying to set up my peripherals again when I detected a wakeup.

    Thanks!

Related
Terms of service