Confusion about vPortTickISR %10 logic in XTmrCtr FreeRTOS port.c

Kernel
,
1

Hi,

I am using the Xilinx MicroBlaze FreeRTOS port with AXI Timer (XTmrCtr) and I have a question regarding the vPortTickISR() implementation when configGENERATE_RUN_TIME_STATS is enabled.

In the current implementation(v11.3.0), the ISR contains logic like this:

    /* The Xilinx implementation of generating run time task stats uses the same timer used for generating
	   * FreeRTOS ticks. In case user decides to generate run time stats the tick handler is called more
	   * frequently (10 times faster). The timer    ick handler uses logic to handle the same. It handles
	   * the FreeRTOS tick once per 10 interrupts.
	   * For handling generation of run time stats, it increments a pre-defined counter every time the
	   * interrupt handler executes. */
#if (configGENERATE_RUN_TIME_STATS == 1)
    ulHighFrequencyTimerTicks++;
    if (!(ulHighFrequencyTimerTicks % 10))
#endif
{
    vApplicationClearTimerInterrupt();

    if( xTaskIncrementTick() != pdFALSE )
    {
        ulTaskSwitchRequested = 1;
    }
}

From what I understand, this pattern is used in cases where a single hardware timer is shared between FreeRTOS tick generation and run-time statistics by increasing the interrupt frequency (e.g., 10x higher frequency), and then only updating the OS tick every 10 interrupts.

However, in the AXI Timer (XTmrCtr) configuration, there are two independent counters available:

  • One counter is used for the FreeRTOS tick interrupt

  • The second counter is used as a free-running time base for run-time statistics

Given this, it seems that the %10 gating logic is not necessary for this hardware configuration, and it may effectively reduce the actual tick rate depending on how configGENERATE_RUN_TIME_STATS is set.

Could someone clarify whether this conditional tick handling is intended to remain for the XTmrCtr port, or if it is a leftover from the TTC/xiltimer implementation where a single timer is shared?

Thanks.

2

This is probably just a mistake where the division wasn’t removed when the code was updated from using a single timer to using separate timers. If this is in the mainline code then please submit a pull request to correct it.

As this is an FPGA, can the number of available [hardware] timers depend on the synthesized design?

3

Thank you for the clarification. You are correct that FPGA timer resources are flexible.

The problem I encountered became noticeable when I upgraded my FreeRTOS version, because the new port.c logic assumes a shared-timer setup by default. In older versions, my setup worked because the interrupt was manually cleared at the end of the vPortTickISR() function: #if (configGENERATE_RUN_TIME_STATS == 1) vApplicationClearTimerInterrupt(); #endif