STM32L Possibility of timer expiry missing

[darla14]

Posted on March 25, 2016 at 11:51

I have Timer1(TIM1) channels configured @ different frequencies.I have loaded appropriate values inside the uhCCRX_Val register as well.The frequencies for channel 1,2 and 4 are 10,100 and 1 Hz , that means i must get the timer expiry at 100,10 and 1000 ms respectively.Since they are multiple of each other , is there a possibility of missing the timer expiries for any one.

for example T1--channel1-->100ms,T1--channel2-->10ms,T1--channel4-->1000ms,so at 1000ms I will get the expiries for channel 2 as well 4 after 10 and 100th time respectively besides for channel4 after 1th time.Is there any possibility that I may miss the expiries for any oneof them or all three expiries are bound to be captured.  #timers #discovery #stm32f4 #!stm32

[Tesla DeLorean]

Posted on March 25, 2016 at 15:31

The timer latches each channel individually, provided you check and clear the TIM->SR properly you should not miss any.

If your time base is 10ms, you could set you SysTick to that, and service your secondaries at 10x and 100x intervals. Much would depend on the run time of your routines, which if excessive in the TIM case would really need pre-emption to function properly.

[darla14]

Posted on March 26, 2016 at 08:49All channels for TIMER1 are configured in Output Compare Toggle Mode configuration.All the code is being run from the usr application mode(e.g ISR doesn't calls a function shared by main but it does sets flag on the basis of which the code in main calls appropriate function.I dont think there is any premeption set for each channel.

[Tesla DeLorean]

Posted on March 26, 2016 at 11:25

Ok, and in this configuration are you demonstrably missing the timer channels?

Make sure you are NOT using this 'TIMx->SR &= xyz' form to clear interrupts/flags Make sure the run time of your routines, when combined, does not exceed the time granularity for the most frequent call periodicity.

[darla14]

Posted on March 28, 2016 at 05:56

Ok, and in this configuration are you demonstrably missing the timer channels?

>> I am not sure about this.But when I put a log break in the IAR work-spaces I see lesser number of logs on the most frequently called routine(called by the expiry of the timer channel called most frequently , lesser time period).Make sure you are NOT using this 'TIMx->SR &= xyz' form to clear interrupts/flags>> I am clearign the intterupt using macro ->  __HAL_TIM_CLEAR_IT(htim, TIM_IT_CC1); , which eventualy expands to -->  ((__HANDLE__)->Instance->SR = ~(__INTERRUPT__))Make sure the run time of your routines, when combined, does not exceed the time granularity for the most frequent call periodicity.>>>You mean the max time of execution of each routine should be less than the min time-period of the all the channels.

[Radosław]

Posted on March 28, 2016 at 12:38

>>>Make sure you are NOT using this 'TIMx->SR &= xyz' form to clear interrupts/flags

>> I am clearign the intterupt using macro ->  __HAL_TIM_CLEAR_IT(htim, TIM_IT_CC1); , which eventualy expands to -->  ((__HANDLE__)->Instance->SR = ~(__INTERRUPT__)) Typical shit from cube.  Interrupt should looks : ISR { uint32_t isr; isr = TIM->IER & TIM->SR; TIM-> SR = 0;  if(isr & TIM_ST_FLAG) { } ..... }

[Tesla DeLorean]

Posted on March 28, 2016 at 13:34

TIM-> SR = 0;

And wouldn't that manifest the exact hazard I'm suggesting he avoid?

[Radosław]

Posted on March 28, 2016 at 13:48

What hazard in this situation?  This is save operation.

More save will be TIM->SR = ~isr;  But few cloks is nothing.  But double read SR. Wow. stupidity.

[Tesla DeLorean]

Posted on March 28, 2016 at 16:01

Writing zero is not safe, the authors of the SPL and HAL just understand that hardware better. You should review the register definitions more carefully, and perhaps be less ignorant.

Remember the timer is typically running twice the bus rate, and writes are going to take several cycles to close.

[Radosław]

Posted on March 28, 2016 at 16:13 >>Writing zero is not safe, bullshit. writing zero is  more safa option. NOT & or any BB access. this: tim->SR = ~isr; 100% safe. >> he authors of the SPL and HAL just understand that hardware better. Next bullshit. >>Remember the timer is typically running twice the bus rate, and writes are going to take several cycles to close. When this same interrupt will arrive more frequently? ISR handler will be to long for this interrupt frequecy.