Long delay in setting TIM status register bits

[HWhit.1]

Hi,
I am trying to use CC1 and CC3 inputs on TIM2 of STM32H7A3 to do some time-critial tasks (very ns fast time-stamping). I need to identify which CCxIF tiggered. Using STMCUBEIDE the skeleton interupt code worked fine in debug mode without the lines comented with //WAIT. The countersTrigger_events_1 and Trigger_events_2 incremented as intended. In Run mode the code did not identify which flag in
the status register was set and did not count the interrupts. Adding the //WAIT lines waits (with a timeout) till one or both of the CCxIF flags in TIM2 status register is set.

While this workaround works in the skeleton code, it will decrease time dependancy which is important for my application.

In the reference manual it states:
"If channel CC1 is configured as input: this bit is set when counter value has been captured
in TIMx_CCR1 register (an edge has been detected on IC1, as per the edge sensitivity
defined with the CC1P and CC1NP bits setting, in TIMx_CCER)."

I am surprised that the interupt handling is faster than the internal setting of the interrupt flags. I might guess that
capturing the count to the CC register would´be fast (< 1-2 clock cycles) and certainly faster than stacking the registers and interrupt handling.

I wonder if anybody has a good explanation for this apparantly long delay with setting the interupt flag? or an idea in howto avoid the large time dependency. I looked but did not find anything on this specific effect.

/****************************************************************************
* TIMn TIMER EVENT INTERRUPT HANDLING
***************************************************************************** */
void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef * htim)
{
/****************************************************************************
* TIM2 Time stamp event
***************************************************************************** */
if (htim == &htim2) // Check it was TIM2
  {
  if(active_flg & (! Step_inhibit_flg) )
  {
   uint32_t cntr = 0 ; //WAIT
   while( ! (TIM2->SR & 0xb)) //WAIT
    { //WAIT
    cntr ++ ; //WAIT
    if ( cntr >= 200) {break ; } //WAIT
    } //WAIT
  if (TIM2->SR & 0x2)
    {
    ticks = TIM2->CCR1; // This resets the CC1F
    Trigger_events_1 ++ ;
    }
   if (TIM2->SR & 0x8)
     {
     ticks = TIM2->CCR3; // This resets the CC3F
     Trigger_events_2 ++ ;
     }
   TIM2->SR = 0x0b ;
   }
}

[waclawek.jan]

IIRC Cube clears the status flags before calling the callback, you are supposed to check a variable (Channel?) to find out, which channel has been captured. 

Cube is open source, red it to find out how exactly does it work. 

I don't use Cube 

JW

[HWhit.1 · Accepted solution]

HI Jan,

Thanks for the suggestion I tried this and it worked! The issue of if one should not use HAL in conjunction with STM32CubeIDE I can understand.  I find it takes a lot of digging into but for most things it is fast and convenient.

Thanks for your good advice!

•