51802 debug mode consuming less power?

[Borden]

Hi community, I'm running a 51802 on my custom board with no other parts on it, except for some buttons and leds directly connected to GPIO, and a DC/DC converter which feed the 51802 with 1.8V power directly. I'm running a custom 2.4G protocol with neither softdevices, nor Gazell lib, which keep 16M clock always running.

Now when I try to optimize power, I've found some interesting thing that I can't find an explanation. I measure current before the DC/DC, so the absolute current read is not so relevant. The cpu is running the main loop steadily merely check for GPIO buttons, not much radio activities except sending a heartbeat packet every second,

the current read 2.21mA.

But if I reset the board to debug mode(with jlink plugged),

the current read 0.96mA.

I've checked this many times to make sure, as long as power is on, the consumption keeps the low state, and there seems no difference of the functionality of the 51802.

So my question is: why in debug mode, the power consumption reduced to about 44% of the normal state? what's changed inside the chip?

[Borden]

Yes I have this resistor on the SWDCLK pin, but that makes no difference, with or without it, I got the same result. When I paused my program in keil, I measured about 0.7xmA, 0.96mA is when my program running. As I mentioned above, this current is read before my DC-DC, which I feed with 3V, so it's about 0.96 / 1.8 * 3 * 0.9 = 1.44mA drawing by 51802, which is much lower(over 50%) than my board running with no jlink attached.

[Sigurd]

Ok, then I suspect that this is leakage current, i.e. you are getting current from the debugger into the nRF51-chip, and therefore partly powering the chip from the debugger. You are therefore measuring a lower current when the debugger is connected.

---

The cpu is running the main loop steadily merely check for GPIO buttons

Note that this is not power-efficient at all. In order to reduce the current here, you should instead set-up a interrupt for the GPIO buttons, so that the CPU can stay in sleep mode. Take a look at e.g. the pin_change_int example in the SDK.

[Borden]

Yes I've had the same thought, so I've experimented, it's not leakage. Once the chip is in debug mode, it stays at 0.96mA, even after I pull the jlink off, until another power cycle.

And for the gpio polling, thanks for your advice, I know it's not efficient, but I'd like to optimize that after this problem made clear, step by step. The main reason that I haven't use the GPIOTE is it can't detect both edge at the same time, and my number of buttons is more than 4, make the GPIOTE inapplicable in my case, not even the extra power it needs, since my 16M clock is always running, I don't think it will draw more power.

[Borden]

Here's a shabby video I've made just now: video

My board have only a 3V power, and a multimeter attached to a 10ohm power line series resistor.

1. When I turn the power on, we can read a steady 1.99mA after power on initialization(a little lower than yesterday's 2.21mA for some unknown reason).
2. then I have a jlink attached, we can see the board reset, after an initialization, we get a steady 0.88mA.
3. then I remove the jlink, it still stay at 0.88mA.
4. When I use a on board button to turn the board off, we read 2.32mA, which further prove the board is in debug mode. If I turn my board off in normal mode, I read 0.02~0.03mA.
5. I turn my board on again, it still read 0.88mA.
6. then I turn the power off and on again, my board recover to 1.99mA of the normal mode.

[Sigurd]

It could be that the chip enters debug mode when you first power the board on, even if the debugger is not connected. It won’t enter debug mode just by simply plugging in the debugger, but since the board does a power-on reset when you connect the debugger, it could actually exit debug mode when you connect the debugger and go into normal mode. After you remove the debugger, it would continue to stay in normal mode.

What does the on-board button do?

If you start a debug session in KEIL, and let the program run, what current do you measure then?

From the reference manual, we have that

To guarantee that the device remains in normal mode, the SWDCLK line must be held low, that is, '0', at all times. Failing to do so may result in the DIF(Debugger Interface) entering into an unknown state and may lead to undesirable behavior and power consumption.

Could to try to connect the SWDCLK pin to ground, and then start your board up, and see what current you measure then.

---

If the issue is still present after this, you should check for floating pins that could be causing this.