This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Questions Regarding Current Measured in pwr_mgmt Example

Hi all,

Please find my following current measurement resuls in the pwr_mgmt example using a nRF52 preview DK and SDK 13

My setup is as follow:

  • SB40 is cut
  • SW6 is at nRF ONLY
  • SW10 is at ON (3.0V external supply to P21, 3.3V supply the current rises to 8uA and will not come down)
  • SW9 is at VDD
  • Current is measured through P22 with a current probe and a 10 ohm resistor is mounted
  • USB is connected to J2
  • UART and logger module is disabled through sdk_config.h
  • The solder joint for the onboard flash is disconnected

Should I flip SW8 to ON or OFF?

When I flip it to ON, I obtained the following measurement:

System on, low power mode:

System off, after pressing Button 1:

The result seems to make sense but there are a lot of little peaks in the waveform.

When I zoomed out, there is another peak which doesn't seem like noise:

The peak lasts for around 300ms and repeats for at 30Hz. I wonder if this is the capacitor peaks mentioned in this link:

https://devzone.nordicsemi.com/tutorials/b/hardware-and-layout/posts/current-measurement-guide-introduction

but it is way too long than what is mentioned in the link (10-15us) and it is definitely not the peak for the app timer created in the pwr_mgmt module.

When I flip it to OFF:

The current immediately rises:

This also happends when I plugged out the USB cable connected to J2, but the SoC should still be working since I use an external supply for it but why it has such radical behavior when the sw is flipped to ON and OFF? What am I missing here?

Thanks!

Parents Reply Children
  • Thanks for your reply. May I know more about the 'not power optimized' part? Exactly what will it do that is not optimized?

    I now have no guildline on how much current would be correct as their differ quite a lot as shown in my measurement. With some search on the DevZone, I think a current consumption around 1uA when it is low power mode would be an acceptable value, as shown in your measurement as well, but I worry that it could just be a false measurement.

    Perhaps you could help me out on the recommended settings of the switch positions? Such as, should I turn SW8 to ON when I measure current? Since I use an external supply for the SoC, I think SW8 turns on the supply to the rest of the circuit, but some how it affects my current measurement with more than 700uA consumption.

    By the way, my preview DK is v0.9 with the last number forgotten by me.

    Thanks.

  • The nRF52840 DK have a really complex power supply that will enable us to fully isolate the nRF52840 reference design from the rest of the DK by flipping the SW6 to 'nRF ONLY'. This is a work in progress and there are bugs in the preview kit's power supply and isolation circuit switches. As of now you cannot make accurate measurements of the current consumption. You will have to wait until the final DK is released. 

  • I'm running the pwr_mgmt example from SDK15 on a PCA10056 V1.0.0 and measuring current with the PCA63511 V1.1.0 power profiler.  With SW6 on the DK set to "nRF Only" I see ~.9uA when the nRF52 is in the System OFF state which seems reasonable.  But when its not in System OFF, in between the peaks when it is waking up to output the CPU Usage on the UART it draws an average of ~620uA which is much higher than I expected.  I assumed it would drop into IDLE mode in between these events and draw much less current.

    I'm seeing similar consumption in my own application in between advertising events and that's why I thought I'd try this example.  Any ideas on what might be causing this behavior?

  • I think that the Log module with UART backend might be enabled. Go to sdk_config and find NRF_LOG_ENABLED and set it to zero, do the same for NRF_LOG_BACKEND_UART_ENABLED. 

    I'm also seeing some issue with setting SW6 to nRF ONLY, I'm measuring a much lower current in DEFAULT. I'll ask around the office if anyone has som info on this issue. 

     

Related