nRF52840 Dongle and Blinky example using GPIO 0.31 draws 8mA

[Dano]

I added two extra buttons to ble_app_blinky (SDK 17.1.0) - port 1.10 and 0.31 I am running the code on an nRF52840 Dongle.The additional buttons are configured exactly like the existing button example, uses pullups are active low and the code works well.... however....if I measure the current draw on the 52840 dongle the normally low current (20-50uA) increases to 8mA if I use pin 0.31 (active low = ground).

I changed to the pin next to it (0.29) and it works as expected like the other button and the tactile switch, but pin 0.31 seems to pull massive current.

I went through the config and changed the default PWM output from 31 to 11 just in case that was effecting it but there is no change to the current draw.

The code works and functions as expected even using pin 0.31, but the current draw when using pin 0.31 is way outside spec.

Can you assist?

Is there something else I should be switching off, on, or configuring so I can use this pin.

It is just that pin 0.31 is very convenient as it is next to the gnd pin so easy to activate.

[SwRa]

Hi Darren,

Have you tried testing the sample on an nRF52840-DK.?

Regards,

Swathy

[Dano]

I did and the result is the same. It is pretty easy to replicate - just add port 0.31 as an input to APP_BLE_BLINKY and use it to trigger the input and watch the current. The 840 DK drew 9mA on grounding 0.31

[Stian Røed Hafskjold]

 Hi, I tried to replicate this here on a DK but can not see the same thing. I started out with ble_app_blinky in SDK 17.1.0 and changed the LEDBUTTON_BUTTON define to 31. I can not see any difference in power consumption. Grounding the pin results in about 200uA, which is expected because of the pull up. Could you please provide more details into what changes you have made to the example code? Thanks.

[Dano]

OK. Try this then.

From the examples, load Nordic supplied Hex code for ble_app_blinky (ble_app_blinky_pca10059_s140.hex) into a nRF52840 Dongle. Current is approx 4mA (mostly from the LED). Now connect 0.31 to GND and the current immediately goes to 12mA.
An 8mA increase. No code or config changes, just using the Nordic supplied Hex code.

Now load the same Hex code into the nRF52840 DK. The buttons and LEDs won't work, but that's OK as the nRF is the same. Current is approx 2mA. Now connect 0.31 to GND and the current goes to 10mA. Another 8mA increase.

Let's swap this around.

Load the correct hex code for ble_app_blinky (ble_app_blinky_pca10056_s140.hex) into the nRF52840 DK. The current is around 5mA. If you connect 0.31 to GND there is no change (I am not measuring down to 200uA). This is the expected current behavior.

Now load the DK Hex (ble_app_blinky_pca10056_s140.hex) into the Dongle. Basically no current (no LEDs working but it is running code). Now connect 0.31 to GND and still no current (maybe 200uA?) - this is also the ideal.

So the current issue is not related to the board (DK or Dongle) as I can get both effects on both boards. This leads me to conclude that the current use is related to a pca10059 configuration setting using pin 0.31 for "something".

Note that I haven't tested all pins as I am actually only concerned with 0.31 at this stage, but the other pins I am using all seem fine. I could check every pin if necessary, but I think I have proven the issue and that it can be replicated.

Nordic has an infinitely better understanding of the nRF52840 than I (clearly!), so I am reaching out to Nordic to assist with the investigation as to the cause and a solution. It bugs me and I want to know why this is happening. I don't think my coding is too bad, but I've only been doing it 40 years or so and I may have missed something.

D

[Stian Røed Hafskjold]

Thanks for the explanation. I tried compiling for the PCA10059 target, and yes I see the same thing. The reason is that P0.31 is configured as the UART TX pin for the logging module. If you are not using UART logging, the easiest way to fix this is to turn it off by setting the NRF_LOG_ENABLED in sdk_config.h to 0. Or you can change NRF_LOG_BACKEND_UART_TX_PIN to something else.

I thought we were looking at  an hardware issue on the nRF52840 rather than a software configuration, so I didn't think about checking if the pin was used for something else. So I'm sorry that it took a while to figure it out.

A tips on how to debug pin configuration issues is to read out the configuration using nrfjprog.The following command will read out P0.00 to P0.31 and P1.00 to P1.15:

$nrfjprog --memrd 0x50000700 --n 0x80 && nrfjprog --memrd 0x50000A00 --n 0x40

0x50000700: 00000002 00000002 00000002 00000002   |................|
0x50000710: 00000002 00000002 00000003 00000002   |................|
0x50000720: 00000003 00000002 00000002 00000002   |................|
0x50000730: 00000003 00000002 00000002 00000002   |................|
0x50000740: 00000002 00000002 00000002 00000002   |................|
0x50000750: 00000002 00000002 00000002 00000002   |................|
0x50000760: 00000002 00000002 00000002 00000002   |................|
0x50000770: 00000002 00000002 00000002 00000003   |................|

0x50000A00: 00000002 00000002 00000002 00000002   |................|
0x50000A10: 00000002 00000002 0000000C 00000002   |................|
0x50000A20: 00000002 00000003 00000002 00000002   |................|
0x50000A30: 00000002 00000002 00000002 00000002   |................|

The values can be correlated with the PIN_CNF[n] register description.

P0.31 (marked in red) shows that the pin is an output.

2 means disconnected input (default state), 3 (or 1) means output, C means input with pullup, etc.

[Dano]

I cannot thank you enough and I am very grateful for the time you have spent getting to the bottom of the issue. I was starting to question what had I done wrong. It now makes total sense as the DK has a J-Link and the Dongle does not so the debug data is sent to an external pin.

I expect that this pin use detail for the Dongle is buried somewhere in documentation but can I ask that this configuration point is highlighted in some way. As a newbie to Nordic SDK, details about configuration are complex and distributed over a vast range of documents.

The tip on reading the port configuration is extremely helpful.

Again, many thanks.