This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RTC Compare Interrupt Doesn't Happen After Debugger Halted

I am using the RTC1 compare event to generate a periodic interrupt. When I halt the bugger and and then run the interrupt doesn't occur. Looking at the RTC1 register set shows the counter value is greater than the compare register. See example pictures below. Is there are away to stop this or a work around?

image description image description image description image description

/* Copyright (c) 2013 Nordic Semiconductor. All Rights Reserved.
 *
 * Use of this source code is governed by a BSD-style license that can be
 * found in the license.txt file.
 */
#include <stdbool.h>
#include <stdint.h>
#include "nrf.h"
#include "nrf_gpio.h"
#include "nrf_delay.h"

#define BUTTON_0 (17)
#define BUTTON_1 (18)

#define LED_0 (21)
#define LED_1 (22)

#define LED_START (LED_0)
#define LED_STOP (LED_1)

#define BTN_PRESSED 0
#define BTN_RELEASED 1

int main(void)
{
    // Configure BUTTON0 as a regular input
    nrf_gpio_cfg_input(BUTTON_0, NRF_GPIO_PIN_NOPULL);
    
    // Configure BUTTON1 with SENSE enabled
    nrf_gpio_cfg_sense_input(BUTTON_1, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_SENSE_LOW);
    
    // Configure the LED pins as outputs
    nrf_gpio_range_cfg_output(LED_START, LED_STOP);
    
    nrf_gpio_pin_set(LED_0);
    
    // Internal 32kHz RC
    NRF_CLOCK->LFCLKSRC = CLOCK_LFCLKSRC_SRC_RC << CLOCK_LFCLKSRC_SRC_Pos;
    
    // Start the 32 kHz clock, and wait for the start up to complete
    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
    NRF_CLOCK->TASKS_LFCLKSTART = 1;
    while(NRF_CLOCK->EVENTS_LFCLKSTARTED == 0);
       
  	// Configure the RTC to generate the ISR tick 
	NRF_RTC1->PRESCALER = 0;
    
    NRF_RTC1->INTENSET = RTC_INTENSET_COMPARE0_Msk;
    NRF_RTC1->EVTENSET = RTC_EVTENSET_COMPARE0_Msk;
    NRF_RTC1->CC[0] = 256;  // interrupt at ~128Hz

    NVIC_ClearPendingIRQ(RTC1_IRQn);
    NVIC_EnableIRQ(RTC1_IRQn);

    NRF_RTC1->TASKS_START = 1;
            
    // Configure the RAM retention parameters
    NRF_POWER->RAMON = POWER_RAMON_ONRAM0_RAM0On   << POWER_RAMON_ONRAM0_Pos
                     | POWER_RAMON_ONRAM1_RAM1Off  << POWER_RAMON_ONRAM1_Pos
                     | POWER_RAMON_OFFRAM0_RAM0Off << POWER_RAMON_OFFRAM0_Pos
                     | POWER_RAMON_OFFRAM1_RAM1Off << POWER_RAMON_OFFRAM1_Pos;
    
    while(1)
    {     
      // Enter System ON sleep mode
      __WFE();  
      // Make sure any pending events are cleared
      __SEV();
      __WFE();                
    }
}

void POWER_CLOCK_IRQHandler(void)
{
  while(1);
}

void RADIO_IRQHandler(void)
{
  while(1);
}

void UART0_IRQHandler(void)
{
  while(1);
}

void RTC1_IRQHandler(void)
{
      // This handler will be run after wakeup from system ON (RTC wakeup)
    if(NRF_RTC1->EVENTS_COMPARE[0])
    {
      NRF_RTC1->EVENTS_COMPARE[0] = 0;
      NRF_RTC1->CC[0] += 256;
      nrf_gpio_pin_toggle(LED_1);
    }
}

Thanks, Darren

    1. works fine for me - do this all the time - doing it right now. I can stop the debugger as long as I like, no problem getting the compare interrupt afterwards.

    2. As your display shows, the compare event is triggered and the interrupt enable bit is set. Whilst those things are true, the interrupt will be triggered. So either it's disabled, all interrupts are disabled, or you have another interrupt on another event, of higher priority, which is constantly triggering because the event isn't cleared.

  • RK,

    Thank you for talking the time to comment! I looked into the items that you detailed in point 2 of your comment and I can't find an interrupt of higher priority and interrupts don't appear to be disabled.

    I have added main.c to this thread below as well as additional register views to the initial question.

  • So the registers show the interrupt is pending - not quite sure where you are at this point however. I don't think the interrupt enable registers are showing there so can't tell if it is or not, I'm assuming it is.

    One thing which stands out, if you run that code and then break, what I'd expect to happen is the interrupt to pend, as soon as you resume the interrupt handler to get called, you add 256 to the CC[0] register but that represents 1/128 of a second, so you've already missed that starting and stopping the debugger. So I'd expect you not to see the next interrupt for about another 512 seconds (less the time you were stopped).

    That's not what you described in the original post, but is that what you are seeing?

  • RK,

    You are right, the interrupt does occur after waiting for the counter to wrap. In my opinion this is pretty useless for debugging if you need to wait for the counter to wrap. I haven't encountered this in type of issues in my 10+ years of embedded system development.

  • I don't think I'd call that useless. Point is RTC keeps running during debug mode (which is why processors with a SysTick function often have a flag to disable it in debug) and your code doesn't defend against being late servicing the interrupt by more than the next timer delay. 1/128 second is pretty long so the chances of missing one outside debugging is pretty low, not zero however, if you end up using the softdevice that can in worst case take about 6ms, if you have other pending interrupts, you could miss it.

    Many ways to fix it. If you need the interrupt, even late, then detect you aren't going to get it from the RTC because you missed it and just set the interrupt yourself to cause it to run again, you'll catch up soon enough. If you don't need every pulse then just ensure you add multiples of 256 until your next interrupt time is in the future (by at least 2 clock pulses).

Related