configuring gpio pin stops LFXO and RTC counter

RE: configuring gpio pin stops LFXO and RTC counter

butch — Mon, 17 Jul 2017 19:32:06 GMT

I was compiling without optimization. Again, this is low priority for me now considering that I can't replicate it (at least when not using the debugger) and I have removed the suspect code (the GPIO config) anyway. But I am curious whether the spurious behavior is caused by timing or sleep, so I think a different test would be your code with an infinite loop but where you configure GPIO pins in every loop iteration.

RE: configuring gpio pin stops LFXO and RTC counter

Hung Bui — Mon, 17 Jul 2017 11:12:13 GMT

I haven't tried with GDB but tested on Keil it worked fine when stepping in debug mode. Suspect it may have something to do with optimization level or other compile flag, could you check ?

RE: configuring gpio pin stops LFXO and RTC counter

butch — Fri, 14 Jul 2017 12:59:01 GMT

I tried to replicate. My code is below. When I step into the code on the debugger, it doesn't complete (infinite loop at the last waitOneTick()) meaning the RTC0 counter has stopped. If I don't step, but just resume the debugger, main() does complete. I don't understand why it behaves differently depending on whether I am single-stepping. The RTC and clocks should still be running while debugging. My environment is Eclipse/GCC ARM/C++.

/*
 * Test whether configuring GPIO pins stops LFXO and RTC0 counter.
 * As alleged in Nordic Devzone thread.
 */

#include "nrf_clock.h"
#include "nrf_rtc.h"
#include "nrf_gpio.h"



unsigned int ticks(){
	return nrf_rtc_counter_get(NRF_RTC0);
}

// spin until RTC0 counter increments at least once
void waitOneTick(){
	unsigned int firstTime, nextTime;

	firstTime = ticks();
	do {
		nextTime = ticks();
	}
	while (nextTime == firstTime);
}

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

		/*
		 * This configuration is same as POR state except:
		 * 1. high current output (max 5mA) instead of normal
		 * 2. pulldown instead of no pull
		 */
		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);
	}
}

int main(void)
{
	// configure lf clock source is xtal
	nrf_clock_lf_src_set(NRF_CLOCK_LFCLK_Xtal);

	// start lf clock
	nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTART);

	// spin until LFXO is stable
	while (! nrf_clock_lf_is_running()) {}

	// RTC0 begin counting (ticks always from LF clock)
	nrf_rtc_task_trigger(NRF_RTC0, NRF_RTC_TASK_START);

	waitOneTick();

	/*
	 * configure all gpio pins
	 * Despite some pins already used by LFXO xtal
	 */
	configureAllGpioPins();

	waitOneTick();
}

RE: configuring gpio pin stops LFXO and RTC counter

Hung Bui — Thu, 13 Jul 2017 15:07:07 GMT

Sorry, I should have had put it outside. I updated, the result was the same.

RE: configuring gpio pin stops LFXO and RTC counter

butch — Thu, 13 Jul 2017 13:30:43 GMT

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.)

RE: configuring gpio pin stops LFXO and RTC counter

Hung Bui — Thu, 13 Jul 2017 12:54:07 GMT

You are right butch, we should test it. But I couldn't reproduce the issue here. Here is my code, I modified the rtc example in the SDK:

int main(void)
{


    lfclk_config();
    leds_config();
    rtc_config();
    NRF_CLOCK->LFCLKSRC =1 ;
    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);
    }
    nrf_gpio_cfg_output(21); //(for the LED)
    while (true)
    {
        __SEV();
        __WFE();
        __WFE();
    }
}

Can still see the LED blinking.

RE: configuring gpio pin stops LFXO and RTC counter

butch — Wed, 12 Jul 2017 14:43:05 GMT

Yes, maybe it is only the LFXO. A wild supposition: they implemented a ring oscillator using the GPIO buffers to save silicon?

RE: configuring gpio pin stops LFXO and RTC counter

RK — Wed, 12 Jul 2017 12:51:33 GMT

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.

RE: configuring gpio pin stops LFXO and RTC counter

butch — Wed, 12 Jul 2017 12:38:23 GMT

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.

RE: configuring gpio pin stops LFXO and RTC counter

Hung Bui — Tue, 11 Jul 2017 09:20:00 GMT

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

RE: configuring gpio pin stops LFXO and RTC counter

butch — Mon, 10 Jul 2017 14:00:35 GMT

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.

RE: configuring gpio pin stops LFXO and RTC counter

RK — Sun, 09 Jul 2017 21:14:22 GMT

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.