Issue with timer overflow interrupt

[jrheisey]

Posted on April 28, 2008 at 12:23

Issue with timer overflow interrupt

[jrheisey]

Posted on April 25, 2008 at 00:54

See the code at the bottom of this message.

Note that WaitTimer::ForMicroseconds() is called during non-interrupt time. The problem I see is that there is some time period where the first call to CounterValue() will return a value such as 0x0999fff6. The next call in the loop might then return something like 0x09990000. A value less than the previously returned value. This is due to the interrupt service routine not being called prior to the CNTR register incrementing to 0x0000 so the s_uHighTime value has not been incremented yet. I would think that it would be more deterministic if the CNTR register is updated from 0xffff to 0x0000 *during* the overflow interrupt process. Anyone experience this? Anyone have a workaround? J.R. Heisey void WaitTimer::ForMicroseconds(unsigned int uWaitDuration) { // counter is configured for microseconds so no further // calculation is necessary. u32 uCount; u32 uInitCount = CounterValue(); u32 uDeltaTime; u32 uLastDeltaTime = 0; do { uCount = CounterValue(); uDeltaTime = uCount - uInitCount; if(uLastDeltaTime > uDeltaTime) { // detect rollover return; } uLastDeltaTime = uDeltaTime; } while(uDeltaTime < uWaitDuration); } MPCRAMFUNC u32 WaitTimer::CounterValue() { return (s_uHighTime << 16) + m_Handle->CNTR; } void WaitTimer::ISR() { if ( TIM_FlagStatus( m_Handle, TIM_TOF ) == SET ) { s_uHighTime++; TIM_FlagClear( m_Handle, TIM_TOF ); } } void WaitTimer::Initialize() { /* Enable the timer module interrupts */ EIC_IRQChannelConfig( m_IrqChannel, ENABLE ); EIC_IRQChannelPriorityConfig( m_IrqChannel, MPC_IRQPriority_WaitTimer); EIC_IRQConfig( ENABLE ); TIM_Init ( m_Handle ); // JRH, 2006/1/2 - The clock is 48 Mhz. A prescaler // value of 48 gives us 1 microsecond resolution. TIM_PrescalerConfig ( m_Handle, 48 ); // Enable the timer interrupts // The implementation for ForMicroseconds() does not // need the interrupt. TIM_ITConfig ( m_Handle, TIM_TO_IT , ENABLE ); // Clear the timer register values to start new counting TIM_CounterConfig ( m_Handle, TIM_CLEAR ); TIM_CounterConfig ( m_Handle, TIM_START ); }

[jrheisey]

Posted on April 25, 2008 at 14:41

I've also discovered that the timing of the generation of the overflow interrupt is completely nondeterministic with regard to the transitioning of the CNTR value from 0xffff to 0x0000. I have seen the interrupt increment s_uHighTime while CNTR is still a value of 0xffff.

So to account for this I've modified my WaitTimer::CounterValue() function as such. Not a perfect solution but it is more deterministic.

MPCRAMFUNC u32 WaitTimer::CounterValue() { 
 register u16 uCount; 
 while((uCount = m_Handle->CNTR) == 0 || uCount == 0xffff) 
 {} 
 return (s_uHighTime << 16) + uCount; 
} 

[kleshov]

Posted on April 28, 2008 at 12:23

I would think that it would be more deterministic if the CNTR register is updated from 0xffff to 0x0000 *during* the overflow interrupt process.

Even if that was the case, your function WaitTimer::CounterValue() would still fail, since the interrupt could happen _AFTER_ the value of the variable s_uHighTime is fetched from memory. It is unreasonable to expect that the counter will overflow during interrupt processing, since that implies that the interrupt is triggered _BEFORE_ it overflows. There would be many problems with such an implementation of a timer. Exactly when should the interrupt trigger? What if interrupts are temporarily disabled? And so on... Your function WaitTimer::CounterValue() should deal with the possibility of a timer overflow during its execution. I think the easiest way to do it is to compute the 32-bit value twice (don't forget to make s_uHighTime volatile), compare them and use either the first or the second one depending on whether the higher 16 bits changed.