Exit from debug mode

[Jérémy Michaud]

Hello,

I did some power measurement on the nrf52 DK with the Nordic profiler kit and the result was way more than what we could expect from a nrf52 (about 1 mA). Even in power off mode, it still needs about this amount of current.

After a search on the devzone, I discovered that it could be because the nrf52 is in debug mode. In this mode, the nrf52 never goes on power down mode et consume way more than in normal mode.

I tried to power reset the chip in order to enter normal mode. But I didn't work.

I also tried nrfjprog --pinreset, but it didn't change anything either.

Finally, I saw on that thread that the code to know whether the debug mode is enabled or not is :

if (DWT->CYCCNT != 0) { bsp_board_led_on(LED); }

And the LED is always on when I run this code.

Is there a solution to exit the debug mode ?

[Jérémy Michaud]

Hello, thank you for this answer. I tried it but unfortunately, it didn't work.

I did a couple of tests to be more precise about my issue.

First of all, I discovered that when I press the reset button, It works when the Profiler kit is unplugged but not when it is plugged.

Secondly, I am not sure if this problem is linked to debug mode or another issue. I found the codeif (DWT->CYCCNT != 0) { bsp_board_led_on(LED); } on the devzone but I am not actually sure whether this is the right way of doing it or not.

To be sure of the problem, I installed the latest version of the SDK (14.0.0) and I flashed the S132 (5.0.0) to the nrf52 DK. Then I flashed the ble_app_hrs example. I opened the profiler kit sotfware and I have an average consumption of about 1 mA :

And when I am in power off mode, the average consumption is about 700 uA :

I think these values are far away from what it should be, but it could be linked to another problem.

[Bjørn Kvaale]

That's strange. I'll take a more in depth look at this issue next week.

[Jérémy Michaud]

I tried it both on the nRF52832 DK and the nRF52840 Preview DK but the result is the same.

I also found on the header file components\libraries\util\app_util_platform.h a macro named NRF_BREAKPOINT_COND and the code if (CoreDebug->DHCSR & CoreDebug_DHCSR_C_DEBUGEN_Msk) to determinate whether the debugger is connected or not. I tried it on the main function but it never goes inside the if statement.

Do you need more information? Do you have maybe some code I can try to determinate more precisely the problem?

By the way, I am using arm GCC but I can try to run the example on Keil if that could help.

Thank you for your help

[Bjørn Kvaale]

You could try to run the example on Keil to see if that helps, but I am uncertain if it will. I am looking at the issue right now. I'll get back to you soon.

[Bjørn Kvaale]

I just tried the same example you tried with the ppk using sdk 14 and the ble_app_hrs example. I am getting an average current consumption of 2.72 uA, which is a lot lower than the 1 mA you report. I flashed the softdevice (S132) using nrfgostudio (first erased the application and softdevice memory) and compiled and flashed the ble_app_hrs example using Keil. I then connected to the nrf toolbox app on my iPhone and ran the HRM example. Could you try this again using Keil? It seems very weird that you are getting such a high current consumption. Are you sure you have set up the PPK board correctly? Hope this helps a bit!

[Jérémy Michaud]

I don't have a Keil license so I cannot compile ble_app_hrs. But I tried to directly flash the ble_app_template_pca10040_s132.hex and I have the same result basically. Yes, I think I set up the PPK board correctly, but maybe could you tell me how to set it up? To be sure that it is right configured. Thank you