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]

OK, thanks. Now I should try and reproduce the problem. But why do you call "NRF_CLOCK->LFCLKSRC =1 ;" inside the loop? In other words, maybe that masks the problem, isn't that reconfiguring the LF clock to be LFXO AFTER you have configured the GPIO pin? Please try it without that line in the loop. (The reason I didn't send you a small test case is that I discovered the alleged problem inside a complex app, I am not equipped to build small test cases every day. Again, thanks for your attention. I hope I have not wasted your time.)