Enabling configGENERATE_RUN_TIME_STATS on FreeRTOS zynq ultrascale+ A53 break FreeRTOS timing

Kernel
1

Hello, I am running into an issue using Vitis 2022.2 pre configured FreeRTOS Hello World example on the zynq ultrascale+. Basically when activating configGENERATE_RUN_TIME_STATS 1, the vTaskDelay() function only delays for around 100ms instead of 1000ms in the example. portTICK_RATE_MS is 1 and I call vTaskDelay(1000). It seems like the run time stats broke the freeRTOS kernal clock. Does somebody have similar issues?

2

Which clock are you using to generate the run-time stats? Is it the same as that generating the kernel tick?

Is the code you are using something we provided, or something generated by Vitis. If Vitis, did Vitis generate the run-time stats configuration, or did you add it manually?

3

Hi,
today I have the same problem. I found in portZynqUltraScale.c the following code:

	/*
	 * 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 timer time out interval is changed
	 * as "configured tick rate * 10". The multiplying factor of 10 is hard coded for Xilinx FreeRTOS ports.
	 */
#if (configGENERATE_RUN_TIME_STATS == 1)
	XTtcPs_CalcIntervalFromFreq( &xTimerInstance, configTICK_RATE_HZ*10, &usInterval, &ucPrescale );
#else
	XTtcPs_CalcIntervalFromFreq( &xTimerInstance, configTICK_RATE_HZ, &( usInterval ), &( ucPrescale ) );
#endif

and in port.c

	/*
	 * 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/tick 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
	{

But it looks like that the delay timer and tick timer are running to fast.

BR
martin

4

Thanks for helping track this down @msauerpb! The code comment states that the FreeRTOS tick will now execute 10 times faster. Given this, the kernel appears to be operating correctly in @Borli’s case.

Either you could scale your delay by 10 (probably the easiest fix) or modify the FreeRTOS vTaskDelay function to scale by 10 when the configGENERATE_RUN_TIME_STATS macro is defined to 1.