Q:

Convert DWT cycle count to time using STM32 and HAL

I am developing on STM32F302R8 in FreeRTOS. I am using the following DWT code from here to profile execution time. My DWT cycle count seems to be working, but I am unsure how to convert it into seconds. From what I gathered online, it seems like the cycle count is based on the CPU frequency. Which HAL function will return the correct CPU frequency for me? I am thinking that it's one of the following
uint32_t          HAL_RCC_GetSysClockFreq(void);
uint32_t          HAL_RCC_GetHCLKFreq(void);
uint32_t          HAL_RCC_GetPCLK1Freq(void);
uint32_t          HAL_RCC_GetPCLK2Freq(void);

Furthermore, I tried gathering some empirical evidence by inserting the DWT code inside the 1kHz tick interrupt like so:
void xPortSysTickHandler( void )
{
    /* The SysTick runs at the lowest interrupt priority, so when this interrupt
    executes all interrupts must be unmasked.  There is therefore no need to
    save and then restore the interrupt mask value as its value is already
    known. */
    portDISABLE_INTERRUPTS();
    {
      /* MY CODE START */
      static uint32_t cycles;
      cycles = KIN1_GetCycleCounter();
      KIN1_ResetCycleCounter();
      /* MY CODE END */

        /* Increment the RTOS tick. */
        if( xTaskIncrementTick() != pdFALSE )
        {
            /* A context switch is required.  Context switching is performed in
            the PendSV interrupt.  Pend the PendSV interrupt. */
            portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;
        }
    }
    portENABLE_INTERRUPTS();
}

Cycles end up averaging about ~71300 each time. Does that mean my clock is running at 71300 * 1000 = 71.3MHz? This seems close to my HAL_RCC_GetSysClockFreq() which returns 72MHz. What's causing the slight error between 71.3MHz and 72Mhz though (assuming my calculation is correct)?

A:

HAL_RCC_GetSysClockFreq() is correct for the CPU clock.  The discrepancy you're seeing between the measured number of cycles and the theoretical clock speed could be due to a number of factors; measurement error is the likely source of most of it (there will be latency in the calls to KIN1_GetCycleCounter() and KIN1_ResetCycleCounter), and you don't mention the nature of your clock source but it's possible that it's inaccurate.

