RTC weird on nrf52832

[pellepl]

Hi,

we have an odd issue on ~ 50% of our in-house boards here. We're using the internal RC as a low frequency clock, and then enable one RTC. No softdevice or anything. In main(), after the classic Reset_Handler (SDK 17.0.2), the first thing we do is:

    // start high frequency clock
    NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_HFCLKSTART    = 1;
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
    __DSB();

    // wait for selected low-frequency oscillator to start up
    enum {LFCLK_OSC_RC = 0, LFCLK_OSC_XTAL = 1, LFCLK_OSC_SYNTH = 2} osc = LFCLK_OSC_RC;
    NRF_CLOCK->LFCLKSRC = osc;
    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_LFCLKSTART = 1;
    while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0);
    __DSB();
    
    // setup and reset rtc
    NRF_RTC2->TASKS_STOP = 1;
    NRF_RTC2->PRESCALER = 1;
    NRF_RTC2->TASKS_CLEAR = 1;
    while (NRF_RTC2->COUNTER != 0);
    NRF_RTC2->TASKS_START = 1;
    //while (NRF_RTC2->COUNTER == 0); // HANG 4ever :(
    __DSB();

On the second last line, while (NRF_RTC2->COUNTER == 0);we hang indefinitely on some boards. How can this be?

[Sigurd]

Hi,

What is the IC marking on the nRF52832 that fails?

Are you using some old nRF52832 Engineering A devices here ? If yes, then this errata would explain the issue: https://infocenter.nordicsemi.com/topic/errata_nRF52832_EngA/ERR/nRF52832/EngineeringA/latest/anomaly_832_10.html

[pellepl]

Hi, thanks for answering.

I'm pretty sure it is newer than that as it came from the factory this autumn, but will check for sure coming Monday.

Also, it affects all three RTCs in fact, the RTC2 is simply the last one I tested.

Finally, turns out a full power cycle recovers it. A reset via nrfjprog -r does not. Have yet to test nvic reset. We have no pin reset. And no idea of how we got to this state.

Cheers,

Peter

[Sigurd]

Hi,

I'm not seeing this when testing on nRF52832-DKs. Can you try to call nrfx_clock_anomaly_132() before triggering LFCLKSTART ?

PS: I recommend using the nrfx driver.

[hmolesworth]

This is not necessarily the issue, but I suggest changing the position of DSB to ensure the start completes before attempting to read. Additionally continuous reading of the counter register by the 64MHz cpu thrashes the bus pathwys between CPU and the 32kHz RTC and may (will) cause issues,

Change:
    NRF_RTC2->TASKS_START = 1;
    //while (NRF_RTC2->COUNTER == 0); // HANG 4ever :(
    __DSB();
To:
    NRF_RTC2->TASKS_START = 1;
    __DSB();
    while (NRF_RTC2->COUNTER == 0) nrf_delay_usec(200); // HANG 4ever :(

[pellepl]

Hi Sigurd,

sorry for belated reply. The marking on the chip says QFAAE1 2114FA, In production we're using the nrfx drivers, this example is boiled down for clarity.

Turns out a power cycle resolves it. The processors are in a bit awkward position to easily cold boot. 

My gut feeling is that we've gotten into this state by numerous debugging sessions and flashings on perhaps bad timings. But it is a little scary that we got in this state as we're relying on the rtc to work. I'll see if I can reproduce it.