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]

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.