RTC "tick" Interrupt Timing Anomaly

In my nRF52810 based circuit board I'm trying to use the RTC along with the RTC tick interrupt to toggle an IO pin every 6msec.    In main.c   I use WFE to enter low power mode between the RTC tick event interrupts.  This seems to work fine with the output pin toggling every 6 msec as desired, but 25 seconds later, the output toggle period changes from 6 msec to about every 7 seconds.   This event is very repeatable.  If I comment out the WFE instruction, the problem goes away.  Can you point me in the right direction?  See the “code” below.

// Configure LFCLK 

void lfclk_config(void)
{
// Initialize the low frequency clock 
   nrf_drv_clock_init();

// Request the clock to not generate events
   nrf_drv_clock_lfclk_request(NULL);
}


// RTC1 interrupt handler 

void rtc1_handler(nrfx_rtc_int_type_t int_type)
{
    nrf_gpio_pin_toggle(output_pin); // toggle output
}


// Configure the RTC1

void rtc1_config(void)
{	
    nrfx_rtc_config_t rtc1_config = NRFX_RTC_DEFAULT_CONFIG;

    // Configure the RTC to tick every 6.25ms which results in an 80HZ output frequency
    rtc1_config.prescaler = 203; // tick =  32768 / (203 + 1) = 80Hz = 12.5msec (all approximate).

    // Initialize the rtc 
    nrfx_rtc_init(&rtc1, &rtc1_config, rtc1_handler);
 
    // Enable a tick interrupt on each tick
    nrfx_rtc_tick_enable(&rtc1, true);

    // start the rtc 
    nrfx_rtc_enable(&rtc1);
}


int main(void)
{
     gpio_init(); // Initialize the gpio
     lfclk_config(); //low frequency low power clock configuration
     nrfx_clock_lfclk_start();
     rtc1_config(); // rtc1 configuration 
      
      while (true) 
      {
           __WFE(); 
      }

}

Parents
  • Hello,

    I'm afraid I can't think of any explanations for this behavior. I also tried to reproduce this here with the test example below (requires SDK 17.1.0) without any luck. Maybe you can try this example and see if you get the same result? I tested with both the RC oscillator and crystal oscillator as the 32K clock source, but it didn't make any difference.

    0511.rtc_test.zip

    Logic trace after letting it run for a few minutes:

    Best regards,

    Vidar

  • Vidar,  Much thanks for your fast response.  I tested the code that you provided exactly as written and it still fails the same way.  One more piece of information.  If I change the RTC pre-scaler from 203 to 406, the Period of the output toggle doubles as you would expect but after exactly 50 seconds of runtime, the toggle Period switches from the expected 12.4 msec to this odd new wavelength of 14 seconds which is exactly double that which I was seeing with a pre-scaler value of 203.  In other words, this long wavelength is related somehow to the value of the pre-scaler but can't be explained entirely by the pre-scaler because you could never achieve an RTC tick interrupt of 14 seconds with the pre-scaler alone.

    In your attempt to reproduce the problem, were you running an nrf52810?  I saw some errata regarding the RTC and am just wondering.  I'm running out of ideas for things to look at.  If this were a board level hardware issue, I wouldn't expect this odd result to repeat itself with such precise timing.

Reply
  • Vidar,  Much thanks for your fast response.  I tested the code that you provided exactly as written and it still fails the same way.  One more piece of information.  If I change the RTC pre-scaler from 203 to 406, the Period of the output toggle doubles as you would expect but after exactly 50 seconds of runtime, the toggle Period switches from the expected 12.4 msec to this odd new wavelength of 14 seconds which is exactly double that which I was seeing with a pre-scaler value of 203.  In other words, this long wavelength is related somehow to the value of the pre-scaler but can't be explained entirely by the pre-scaler because you could never achieve an RTC tick interrupt of 14 seconds with the pre-scaler alone.

    In your attempt to reproduce the problem, were you running an nrf52810?  I saw some errata regarding the RTC and am just wondering.  I'm running out of ideas for things to look at.  If this were a board level hardware issue, I wouldn't expect this odd result to repeat itself with such precise timing.

Children
No Data
Related