configuring gpio pin stops LFXO and RTC counter

[butch]

I found that blindly configuring all GPIO pins can stop the LFXO and RTC counter. I am reporting this as: something to be aware of, not obvious to everyone. Not a question, just saying "don't do that, or do it in a different order."

After starting the LFXO clock and enabling RTC counter I did this:

for (uint32_t pin = 0; pin < 32; pin++) {

	// Configure high current output (max 5mA)
	nrf_gpio_cfg(
			pin,
			NRF_GPIO_PIN_DIR_INPUT,
			NRF_GPIO_PIN_INPUT_DISCONNECT,
			NRF_GPIO_PIN_PULLDOWN,
			NRF_GPIO_PIN_H0H1,	// !!! high current
			NRF_GPIO_PIN_NOSENSE);
}

This code changes the pin configurations to have a pulldown and high current, different from their reset condition (but still not connected, same as reset.) Just looking at Figure 1 under GPIO in the product spec, it is not clear to me why this stops the RTC counter. I understand that the physical pin is shared between the LFXO crystal and the GPIO port. I guess that the ANAEN signal is controlled by the LF clock and that somehow configuring the GPIO pin disrupts that.

[RK]

Don't think it has anything to do with ANAEN. You're force driving one of the LFCLK pins low which stops the oscillator which is then going to stop anything using the oscillator. You'd think that when the pin is used for the crystal the GPIO would be disconnected and configuration changes would have no effect, however it seems that's not the case.

You didn't say which chip.

[butch]

I thought that this configuration is the same as the POR reset configuration, and that it means that all the logic to the left in Figure 1 is disconnected, i.e. the two switches leading from the physical pin to the two buffers (triangles) are open, so the physical pin (and I presumed the LF clock) is isolated from the GPIO logic. Figure 1 seems to show the pulldown/up resistors on the input buffer, so they should not be connected to the physical pin either? Thats why I was configuring all the GPIO's, other posts suggested you should not leave the pulldown/up configured NOPULL. I could be wrong, I'm not an electrical engineer. I refer to the nRF52 documents, but I suspect it's the same on the nRF51.

[Hung Bui]

I also suspect that the pulldown configuration cause the LFCLK crystal to stop. Could you try again with NOPULL ?

[butch]

Sorry, but no I am not interested in that experiment, since I already know a solution: don't configure a GPIO pin when the corresponding physical pin is used by another peripheral. Which might seem obvious to most people. I suggest that the documents be improved. In the middle of Figure 1 there is a "square" that I presume represents the physical pin, but it should be labeled. Figure 1 doesn't show where any other peripheral (such as LFXO) that shares the physical pin is connected to the physical pin (upstream or downstream of the GPIO buffers.) Figure 1 doesn't show the pullup and pulldown resistors, only obscurely hints that they might be on the input buffer since that is where CNF.PULL attaches. Again, I suppose how pin multiplexing works is the same across all platforms and that most experienced embedded programmers already know.

[RK]

If this is actually the case I'd count it as a silicon bug. If the GPIO is used by the LF crystal then I'd expect them to be disconnected from the GPIO subsystem. Fortunately you've given enough information that someone at Nordic can check and see if it's actually the case and work out whether it needs to be specifically documented or even counts as an erratum.

In general you can configure GPIO pins even if the pin is used by another peripheral, in fact it's even recommended that you do exactly that so the pins are in a defined state before and after the peripheral connects. Check for instance the SPI module which recommends how pins should be configured so that sleep mode leaves the pins in an SPI 'neutral' state.

So "don't configure pins when the corresponding pin is used by another peripheral" is probably too strong a rule.