nrf_gpio_cfg() function leaks current to pins

[butch]

When I run an infinite loop of NOP on the NRF52DK, the led's remain dark. But when I run an infinite loop of:

nrf_gpio_cfg(
pin,
NRF_GPIO_PIN_DIR_INPUT,
NRF_GPIO_PIN_INPUT_DISCONNECT,
NRF_GPIO_PIN_PULLDOWN,	// !!! pulldown
NRF_GPIO_PIN_H0H1,	// !!! high current
NRF_GPIO_PIN_NOSENSE);
}

(iterating on all the gpio pins) the led's glow very faintly. I expected the led's to remain dark, since the reset state of the pins is dark (loosely speaking) and the call to nrf_gpio_cfg doesn't change that.

Might it be a "break before make" problem in the HW implementation? Maybe SW must change pin configuration bits in a certain order?

This continues the discussion in my previous post devzone.nordicsemi.com/.../. If blindly configuring gpio pins DOES leak current to the physical pin, might it disrupt the LFXO if you configure a pin that is also a LFXO pin?

[RK]

You're explicitly attaching a pulldown to the pin. The reset state of the pins is NOPULL. Looking at the GPIO diagram, pull is attached after direction (input disconnect isn't shown explicitly on the input buffer but the intention of that is to disconnect the read circuit, not to prevent pull, you often need to pull a pin you don't need to read).

So you are explicitly pulling all your pins low so I'd expect them all to glow.

Change it to NOPULL to hi-Z them and the LEDs won't glow. That is the actual reset state. I believe Hung Bui suggested this in the last thread.

[butch]

Thanks. Finally an answer that explains missing parts of the diagram. Why would you need to pull a pin that you don't read? My reasoning: if you don't read it implies not an input implies is output, and the output circuitry will drive it low or high.