GPT frequency off and cannot figure out why

[Rick Burnett]

In the process of updating my code to a newer version of ChibiOs my GPT frequency seems wrong.

Hooking up an output derived from the GPT shows 1.333Hz instead of 2Hz. Multiplying the frequency internal by 1.5 speeds up the clock to 2Hz.

I tried in both tick and tickless mode, works the same.

I am using the system tick time to measure an input, and the calculations are correct for what I would expect (using a known external frequency generator). That just means that the math relative to the system clock is correct with regards to sampling time. (i.e., the tick frequency and when I measure something with it, stay consistent).

That leads me to believe that somehow, when the Hz value of the GPT2CFG I am creating is off, the math that converts that into the proper system tick times is wrong.

When you start a continuous GPT, how is the time out calculated from the hz value you pass in?

Here is a portion of my code:

Code: Select all

            gpt2cfg.frequency = (768*CH_CFG_ST_FREQUENCY)/(currentAverage);

            uint32_t pscCheck = ((GPTD2.clock / GPTD2.config->frequency) - 1);
            if( pscCheck >= 2<<15 ) {
               preScaleDivider=2;
               pscCheck = pscCheck >> 1;
               gpt2cfg.frequency = gpt2cfg.frequency << 1;
               while(pscCheck >= 2<<15) {
                  preScaleDivider =  preScaleDivider << 1;
                  pscCheck = pscCheck >> 1;
                  gpt2cfg.frequency = gpt2cfg.frequency << 1;
               }
               preScaleCnt=0;
            } else {
               preScaleDivider = 1;
            }

            chSysLockFromISR();
            uint16_t psc = (uint16_t)pscCheck;

            /* Timer configuration.*/
            GPTD2.tim->CR1  = 0;                          /* Initially stopped.       */
            GPTD2.tim->CR2  = STM32_TIM_CR2_CCDS;         /* DMA on UE (if any).      */
            GPTD2.tim->PSC  = psc;                        /* Prescaler value.         */
            GPTD2.tim->DIER = GPTD2.config->dier &        /* DMA-related DIER bits.   */
                    STM32_TIM_DIER_IRQ_MASK;
            GPTD2.tim->SR   = 0;                          /* Clear pending IRQs.      */

            gptStartContinuousI(&GPTD2, 2);
            chSysUnlockFromISR();
            

currentAverage is measured in system tick time, so if I had as many ticks as the current frequency, than the frequency I request would be 768Hz. (in other words, if my tick time is 1khz, and currentAverage is 1000, then I'm requesting 768Hz).

Also note, the timer is stopped before all this is done, then restarted. I used the prescalar mechanism you see before I switched from a much older version of the code base. All this has worked for a few years no problem. I'm just unclear what could be creating this timing issue.

Thanks!
Rick

[Rick Burnett]

Also note, my pre scalar values do not work now.

The code above detects when the pre scalar goes larger than 16-bit, so it keeps bit shifting (*2) the frequency and bit shifting the pre scalar (/2) till the value is in range for the timer. (this was necessary because I need to run the timer at a wide range with as much resolution as possible).

Previously this worked great. Whatever is causing the frequency of the timer to be off is affecting this as well.

Also note that I disabled the frequency check. For this application I want the timer to pick the closest frequency it can, which it does (I just commented out the assertion on mismatched frequency).

[Giovanni]

Hi,

Define "previously", then you could do a compare of the GPT driver between the working version and the current one.

Giovanni

[Rick Burnett]

I'm on 17.6.3 now, previously I was on 2.6.6.

The switch to tickless mode was the biggest change I did, so I am thinking something relative to that is what I am dealing with. Since I was using TIM2 already, I set this:

Code: Select all

#define STM32_ST_USE_TIMER                  5

I verified my clock settings in CubeMX just to make sure things made sense. All I can think is maybe TIM2 is being set to a different AHB in tickless mode maybe? Although the 3/2 relationship is still very strange.

Or, something to do with TIM5.

I measure with the system ticks which I would think is all TIM5, and set values in TIM2. I could see if it was a 2x difference since I believe that is the difference between both AHB clocks.

[Giovanni]

AHB cannot be changed, it is an HW thing.

Giovanni

[Rick Burnett]

I thought you could change which clock a timer is referencing?

One thing I notice is that in gpt_lld_start_timer, the interval has been changed.

Previously it was:

Code: Select all

gptp->tim->ARR   = (uint32_t)(interval - 1)

Now it is:

Code: Select all

gptp->tim->ARR = (uint32_t)(interval); 

Lots of little changes all over the place between both code sets, but that was the most obvious. I changed the pre scalar code to match, but that didn't change anything. So now I am going to experiment with the interval value I am setting.

[Rick Burnett]

Previously I had the interval set to 2, so I set it to 1 now, this fixes the strange relationship with the prescalar.

Now I just need to figure out the other timing differential.

Maybe I am misunderstanding how the interval works now.

Before I'd basically set my frequency to 2x the rate I wanted to check something, and set the interval to 2.

So if the frequency was set to 1000, and the interval was 2, then it would get called 500 times as second.

The only place I have a 3 in the numbers is my ST_RESOLUTION. I am unclear if the system timer counter has any relationship to the timer?

Code: Select all

#define CH_CFG_ST_FREQUENCY                 300000

[Rick Burnett]

Actually, that cleaned up both, so it was that interval that changed definition in the newer code.