[En-Nut-Discussion] AT91SAM7X256 TC1 Timer being disabled

[Coleman Brumley]

> It has been a while since I looked at it, but basically what happens is
> the OS stops interrupting because the second interrupt is never queued
> and therefore never cleared. Subsequent interrupts on the timer then
> are
> missed. The timer is still running, it just doesn't cause an interrupt
> in the OS. I have seen this on a logic analyzer and read out the CV
> register which continued to change.
> 
> The odd behavior would be TC0 stopping as well. I don't have an
> explanation for that.

I apologize for being inarticulate in my earlier postings.  In hindsight, my
post insinuated that the TC0 and TC1 _interrupts_ were stopping at the CPU
level. That's not accurate.  TC1 was stopping at the interrupt handler level
(this was fixed by Timothy's code), and I was never able to determine where
TC0 was stopping.  

What is happening is that the Nut/OS handling of the TC0 timer stops.  So,
the following code stops working.

timer5 = NutTimerStart(5, TimerCallback5, (void*)&event1, 0);

///////////////////////////////////////////////////////////////////////
//  raises an event every 5ms

void TimerCallback5(HANDLE timer, void* arg)
{
	NutEventPostAsync((HANDLE*)arg);	
}

I had toggled one of my I/O pins in TimerCallback5 and captured it on a
scope and the I/O pin stopped toggling.  This would also cause NutEvenWait
to never timing out.  So, anything waiting on event1 would not run.  The
problem seemed worse when the system was under heavy UART traffic.

Putting 2 and 2 together (from Harald's recent post about Nut/OS tasks):

"Right now the most time consuming interrupts are in the UART drivers,
because buffering incoming characters or acting on hardware handshake needs
to be done in shortest time."

And Timothy's description of their design failure in that one of their
interrupt handlers was taking too long...

Perhaps there's something broken in the UART interrupt handler that's
causing a long delay and therefore causing this problem?

> 
> > This sounds like a design failure somewhere else.
> >
> I agree. We resolved our design failure (other interrupt taking too
> long) and additionally added the "fix" for the timer stopping just
> because we don't want the timer to stop in production code.
> 

I've also implemented Timothy's fix because if the timer stops in production
code, then the product stops working all together.  

Regards,
Coleman