Suspected GPIO Errata - excess power consumption when NRF_P->PIN_CNF[3] = 0

[Allen Jameson]

We experienced an issue in production, in which about 40% of boards had excess current consumption by about 75uA.  Root cause was found to be the PIN_CNF of a GPIO pin.  During bootup we perform a test where we set the config using 

nrf_gpio_cfg_output(MY_PIN);
nrf_gpio_pin_clear(MY_PIN);

and then we end the test by setting to what should be a low power configuration:

nrf_gpio_cfg_input(PDM_MIC_CLK_PIN, NRF_GPIO_PIN_NOPULL);

This corresponds to PIN_CNF = 0x00, as opposed to the default PIN_CNF of 0x02.  Directly toggling the PIN_CNF between 0x00 and 0x02 causes the excess current consumption; i.e. the current consumption drops by about 75uA to expected values when it is set to 0x02.  The difference between these two values is that the default value (0x02) has input disconnected while 0x00 has input connected.  Typically this difference has no impact on current consumption, but for a subset of our boards this difference it critical to power consumption. 

Is this a known issue?  Is there another explanation for these results?

Other information:

• The pin is connected to a clock line of a digital PCM mic, which is powered off when we make the current measurement (all pins should be at 0V).
• During the test on bootup (and later during operation) we use the pin with the PDM mic using NRFX_PDM_DEFAULT_CONFIG(PDM_MIC_CLK_PIN, PDM_MIC_DATA_PIN); and nrfx_pdm_init(&_pdm_config, pdm_mic_event_handler);  After we finish the test we call nrfx_pdm_stop(); then set the pins as inputs then call nrfx_pdm_uninit(); I haven't tested changes to this order (e.g. setting pins as inputs after the uninit call), but looking at the contents of each call I don't think it would matter.
• The NRF52840 is part of a module from Laird.  I don't know the revision of the IC, but it was probably manufactured 12-24mo ago.

[Allen Jameson]

Correction to title, the affected pin is P1.3 so the title should read NRF_P1->PIN_CNF[3]

[hmolesworth]

75uA is suspiciously close to a typical feedthrough value where internal or external conditions cause a floating pin to hover around the internal FET threshold midpoint. You can test that theory by setting the pin(s) to active low driven as outputs which actually gives very low consumption if pins are unloaded.

Internally pins are held (and read) at '0' but supposedly without bus loading; disconnecting the pin maybe means you get feedthrough susceptibility.

I discussed this in my response to a post a while back, along with some detailed measurements I made regarding pins, pull-up/down, inputs etc nrf52832-power-leakage

[Allen Jameson]

hmolesworth thanks for your comments.  Your explanation seems to make sense, in that a floating pin causes some excess current when connected as an input.  I don't find the relevant comments/measurements in the thread you linked to, perhaps you would be so kind as to quote the relevant data?

Is data about the threshold midpoint, feedthrough, impact of bus connection etc. available in any datasheet or technical document?

Your linked thread seems to say that leaving the input disconnected is more likely to cause an issue; in my experience it is connecting the input to an undefined voltage level that causes the excess consumption, and setting it to disconnected (default config) is what brings the power down to the expected level (I thought the pin in question should be at 0V but in reality it is probably high impedance, so this explains why it could be floating at any level).

Based on what I know now, I agree that for this particular pin, setting it to active low would probably also result in very low current; however I don't like that as a general solution since in some cases this could result in a leak, if the pin is "don't care" but not high impedance.  Setting pins to default (not connected to input bus) seems to be the most reliable option.

[hmolesworth]

The complication is knowing exactly what "disconnected" actually means for a nRF52 pin; here is a link to a TI App Note discussing the phenomenon, although I originally had this issue with a Philips 8051 device long before this App Note was written scba004e.pdf It is also not clear if the bus hold feature consumes any current.