Sleep mode power consumption

[fgeldenh]

I would like to confirm that my hardware design is correct and in addition that I am following the correct procedure to place the nRF52832 to sleep to achieve the lowest possible sleep current. I am using the standard unmodified power management example for PCA100040. Although I only have a single button, it should still work as I understand. I am using Segger Embedded Studio with j-Link. I understand that in order to run the sample I must not run in debug mode. I am still however getting a current draw of 850uA. As you can see, I am using the module from Raytac.

Job1.PDF

[fgeldenh]

Edvin - Thank you for your prompt response.

I am using the very simple peripheral (nrf_pwr_mgmt_pca10040) sample code. I attach two files, the one is using ublox EVK-NINA-B1 kit which is pretty similar to the nRF52 DK, and the other is my custom board.

These files depict the output from the sample code. In the case of Ublox it works as expected whilst my board does not shut down. I sent the schematic so you can look and see why there may be different behaviour.

The Ublox kit has a built in Segger debugger while in my case I am using the Segger J-Link debugger.

Maybe you can help me find out what the difference may be.

Thank You

[fgeldenh]

I my have not attached the filesImages.zip

[Edvin]

Did you try the .hex file that I attached in the previous post?

BR,

Edvin

[fgeldenh]

Edvin - OK I admit that I have not read all the Nordic documentation. (There is a lot!). I have established that my issues are all related to the board configuration. If I set up a correctly formed custom_board.h, then all my issues clear up.

Thank you for your assistance

[Edvin]

As I mentioned, if you use the unmodified nrf_pwr_profiling_pca10040 with a different board (using custom_board.h) with the number of buttons defined less than 2, then it will automatically go into advertising, and not sleep. This is done in the main() function.

What I did in the hex file that I sent you was to remove everything that has to do with buttons, so that it will go into sleep no matter what.

I see that we were speaking of two different examples, though. I was referring to examples\ble_peripheral\ble_app_pwr_profiling, and you meant the examples\peripheral\nrf_pwr_mgmt_pca10040.

There is a lot of button setup in this example. It might be that you get an assert if you don't have as many button defines in that example. From your logs, it doesn't look like the custom board is actually going to sleep. Try to do some debugging, and see if you can figure out why.

BR,

Edvin

BR,

Edvin

[fgeldenh]

Edvin - The reason why the board did not go to sleep was due to the incorrect board. With the correct board set, it works fine.