Duration of timer's IRQHandler with PWM

[she]

Posted on October 26, 2015 at 16:29

I'm using STM32F303 Discovery board.

I try to evaluate how much code can be performed intimer's IRQHandler without causing desynchronization with PWM of the same timer.

//interrupt code
if (TIM_GetITStatus(TIMX.name, TIM_IT_Update) != RESET)
{
TIM_ClearITPendingBit(TIMX.name, TIM_IT_Update); 
GPIO_SetBits(GPIOE, GPIO_Pin_0);
for(aaa=0;aaa<6;aaa++)
__nop();
GPIO_ResetBits(PIOE, GPIO_Pin_0);
}

//some init strings
//---
base_timer.TIM_Prescaler = 8 
base_timer.TIM_Period = 20; 
base_timer.TIM_ClockDivision = 0;
base_timer.TIM_CounterMode = TIM_CounterMode_Up; 
//---
oc_init.TIM_OCMode = TIM_OCMode_PWM1; 
oc_init.TIM_OutputState = TIM_OutputState_Enable; 
oc_init.TIM_Pulse = 10; 
oc_init.TIM_OCPolarity = TIM_OCPolarity_High;
oc_init.TIM_OCNPolarity = TIM_OCNPolarity_High;
oc_init.TIM_OCIdleState = TIM_OCNIdleState_Set;
oc_init.TIM_OCNIdleState = TIM_OCNIdleState_Set;

So due to toggling pin inside IRQHandler i saw necessity that time of code performing was less then half of PWM duty cycle. I also try to use CCR2 interrupt but situation is the same. Can somebody explain the reason of such behavior? And maybe it's real somehowachievepossibility to use full time of PWM duty cycle fortimer's IRQHandler? Thank you!

[Tesla DeLorean]

Posted on October 26, 2015 at 16:33

I'm not sure what you're describing. How much time you spend in the handler would seem irrelevant to whether the timer ticks, and generates a pwm signal. Your GPIO is another matter, and is going to get butchered once you saturate the processor.

[she]

Posted on October 26, 2015 at 17:09

Thank you, Clive for so fast reply. Try to clarify my problem.

It's success situation when IRQHandler execution is less than half of PWM duty cycle. As you see software toggling of GPIO in IRQHandler (blue signal) follows toggling of PWM (yellow line) equidistantly (at the same time interval).

When IRQHandler execution is more than half of PWM duty cycle i saw

desynchronization

 of my software toggling with PWM toggling. I expected saw it in case when IRQHandler execution time is close to PWM duty cycle but not it half.

So what the reason of such behavior? And it's possible to chanhe it?

[Tesla DeLorean]

Posted on October 26, 2015 at 17:28

The processor gets to your IRQHandler when it can, at saturation it is going to directly tail-chain at exit back into the same IRQHandler. The latency is going to depend on how much time/cycles you are sucking up, it is not going to preempt itself. Just prior to saturation it will exit, pop context, and then very soon push context, and come back in. Seem to think that might eat 24 cycles. Joseph Yiu's book probably has a chart.

The system is going to saturate with interrupts at several 100 KHz.

Write your handlers more optimally? Doesn't the F3 want you to use CCM RAM? The Flash is very SLOW.

[Tesla DeLorean]

Posted on October 26, 2015 at 17:42

Does your system have other interrupts running of equivalent period and priority?

[she]

Posted on October 27, 2015 at 10:25

I understood it but as i said I expected saw that in case when IRQHandler execution time is close to PWM duty cycle but not it half. I have project with clear main loop and one interrupt for timer's update.

I try to change PWMpulse and understood that i was wrong with moment which corresponds to interrupt handler.

So problem is latency between PWM toggling (yellow) and software toggling inside interrupt (blue). What caused so big delay?

[re.wolff9]

Posted on October 27, 2015 at 12:03

Once the interrupt happens, the processor needs to save many registers onto the stack to be able to safely execute your interrupt routine. Even when the memory can be accessed in one cycle, that may take some time. 

It is entirely possible that there is some more processing going on beyond your interrupt handler. I recently had some trouble with an interrupt taking about 8 microseconds beyond my ''toggle the IO pin'' inside my handler......

[Tesla DeLorean]

Posted on October 27, 2015 at 13:56

You'd have to look at the code generated by the compiler, the calls, and the optimization settings.

You've presented a very narrow view of what you're doing with a selective cut-n-paste rather than present something that can be reviewed and compiled.

Figure every word from FLASH takes 4 cycles to fetch, vs 1 from SRAM, when computing cycles for assembler code emitted. You can burn 50-100 cycles pretty quickly and achieve very little.

[e1369008]

Posted on October 27, 2015 at 14:17

[deleted, please ignore]

[she]

Posted on October 27, 2015 at 16:07

That's all code without init part.

void TIM3_IRQHandler(void)
{
if (TIM_GetITStatus(TIMX.name, TIM_IT_Update) != RESET)
{
TIM_ClearITPendingBit(TIMX.name, TIM_IT_Update);
GPIO_SetBits(GPIOE, GPIO_Pin_0);
for(aaa=0;aaa<6;aaa++)
__nop();
GPIO_ResetBits(GPIOE, GPIO_Pin_0);
}
}
//-------------------------------------
int main(void)
{
int i;
HWinit();
TIM_ITConfig(TIMX.name, TIM_IT_Update, ENABLE);
TIM_CtrlPWMOutputs(TIMX.name,ENABLE);
TIM_Cmd(TIMX.name, ENABLE);
while(1)
{
}
}

So as i understood there is aconsiderable latency between event causing interrupt and its handler. But in this case how to work on frequencies about few MHz? It's interesting info about CCM RAM, will read about it for sure. But how it can be implemented in this case?

[Tesla DeLorean]

Posted on October 27, 2015 at 17:14

This would be more illustrative, less clutter between the entry point and the edge

void TIM3_IRQHandler(void)
{
GPIOE->BSSR = GPIO_Pin_0;
TIM_ClearITPendingBit(TIM3, TIM_IT_Update);
for(aaa=0;aaa<
6
;aaa++)
__nop();
GPIOE->BSSR = GPIO_Pin_0 << 16;
}

You're going to have to look at the code generated by the compiler to understand where the cycles are going. The context push is 12 cycles. You're not going to be able to interrupt at MHz rates. For that consider using hardware.