Timer can't generate a <10 μs clock, what did I do wrong?

[xxb9075]

Hi Nordic community,

I'm trying to generate a 1 MHz base clock with one of the peripheral timer, and in the timer ISR does some GPIO toggling. 

I followed the nRF5 SDK example and just toggle one GPIO in the ISR to test the clock frequency. I notice, for some reason, the fastest clock I can get here is ~100 kHz (10.6 μs period).

Would you help me check what I did wrong?

Here is the relevant code snippet in main function:

    nrf_gpio_cfg_output(BSP_LED_1);
    nrf_gpio_pin_set(BSP_LED_1);
    timer_init(&TIMER1, 1);
    timer_enable(&TIMER1);
    while(1)
    {
        __WFI();
    }

Here is the timer_init definition:

void timer_init(nrfx_timer_t const * const p_instance, uint32_t time_us)
{
    uint32_t time_ticks;
    nrfx_timer_config_t timer_config = NRFX_TIMER_DEFAULT_CONFIG;               // Start with default settings for the timer instance
    timer_config.bit_width = NRF_TIMER_BIT_WIDTH_16;
    timer_config.frequency = NRF_TIMER_FREQ_1MHz;

    APP_ERROR_CHECK(nrfx_timer_init(p_instance, &timer_config, timer_irq_handler)); // Initialize the timer
    time_ticks = nrfx_timer_us_to_ticks(p_instance, time_us);                   // Calculate time tick needed for the initialized timer based on its clock config
    
    switch(p_instance->instance_id)
    {
      // case NRFX_CONCAT_3(NRFX_TIMER, 0, _INST_IDX):
      //   nrfx_timer_extended_compare(p_instance, NRF_TIMER_CC_CHANNEL0, time_ticks, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK, true);                                 // Setting the timer channe0 in the extended compare mode
      //   break;      
      case NRFX_CONCAT_3(NRFX_TIMER, 1, _INST_IDX):
        nrfx_timer_extended_compare(p_instance, NRF_TIMER_CC_CHANNEL1, time_ticks, NRF_TIMER_SHORT_COMPARE1_CLEAR_MASK, true);                                 // Setting the timer channel in the extended compare mode
        break;
      // case NRFX_CONCAT_3(NRFX_TIMER, 2, _INST_IDX):
      //   nrfx_timer_extended_compare(p_instance, NRF_TIMER_CC_CHANNEL2, time_ticks, NRF_TIMER_SHORT_COMPARE2_CLEAR_MASK, true);                                 // Setting the timer channel in the extended compare mode
      //   break;
      // case NRFX_CONCAT_3(NRFX_TIMER, 3, _INST_IDX):
      //   nrfx_timer_extended_compare(p_instance, NRF_TIMER_CC_CHANNEL3, time_ticks, NRF_TIMER_SHORT_COMPARE3_CLEAR_MASK, true);                                 // Setting the timer channel in the extended compare mode
      //   break;
      default:
        break;
    }
}

And here is the timer irq handler

static void timer_irq_handler(nrf_timer_event_t event_type, void *p_context)    // Timer handler is only used in timer mode not counter mode
{
  switch(event_type)
  {
    // case NRF_TIMER_EVENT_COMPARE0:
    //   nrf_gpio_pin_toggle(BSP_LED_1);
    //   break;
    case NRF_TIMER_EVENT_COMPARE1:                                              // The event type is based on the timer setting
      nrf_gpio_pin_toggle(BSP_LED_1);
      //NRF_LOG_INFO("TIMER");
      break;
    // case NRF_TIMER_EVENT_COMPARE2:
    //   nrf_gpio_pin_set(BSP_LED_0);
    //   break;
    // case NRF_TIMER_EVENT_COMPARE3:
    //   break;
    default:
      break;
  }
}

Lastly, the timer_enable function just calls 

nrfx_timer_enable

 .

Really appreciate your help.

Thanks.

Richard

[Jørgen Holmefjord]

Hi,

Is this your full code, or just a part of it? Do you have a Softdevice on your chip? The Softdevice will increase interrupt latency up to 4 us, see Interrupt latency due to System on Chip framework. 

If there is no Softdevice and no other peripherals enabled; did you check if the value returned from nrfx_timer_us_to_ticks() makes sense? Have you tried increasing the frequency of the timer to 16 MHz?

Best regards,
Jørgen

[Jørgen Holmefjord]

Some of the latency might also come from the device starting up from sleep, see t_IDLE2CPU in Device startup times. You can try to remove the call to __WFI() and check if this reduces the latency time.

[xxb9075]

I think I tried removing __WFI() too though. 

Would you suggest how to disable softdevice so I can try to locate if it is the problem?

And would it be better to just use no interrupt?

[Jørgen Holmefjord]

You may try polling the register directly instead of using interrupt, but it is not a good long-term solution if you want to keep low power and allow the CPU to perform other tasks. 

You should also try the timer code in a standalone application without the Softdevice present, to see if you get the expected latency.

If you want fully predictable latency, you need to use PPI to trigger tasks when the timer fires, but if this is a viable solution in your application depends on what you want the timer to do.

[xxb9075]

I will try your recommendations. The PPI does not work since I need more than 8 GPIOs. But nRF52840 has only 8 GPIOTEs.

May I also ask, since we are shifting to nRF Connect SDK, the Zephyr k_sleep function seem to be a function to implement the delay while not keeping CPU engaged. Would you suggest if it's a viable idea to use some blocking delay APIs from Zephyr instead?

Thanks,

Richard

[Jørgen Holmefjord]

I will advice against using stalling for creating delays, regardless of the SDK version used. By default, the system clock in Zephyr runs from the 32.768 kHz clcok, which will not allow you to achieve the frequency you want. Using interrupts will allow you to set the priority of the task higher than other tasks in the application, and it will allow you to put the CPU to sleep for longer periods of time.