[En-Nut-Discussion] AT91SAM7X256 TC1 Timer being disabled
Bernd Walter
enut at cicely.de
Sun Jul 12 14:32:55 CEST 2009
On Fri, Jul 10, 2009 at 11:12:41AM -0500, Timothy M. De Baillie wrote:
> Coleman Brumley wrote:
> > What I'm finding, though, is that after some amount of time (several hours,
> > for instance) the TC1 interrupt is being disabled. If I toggle a PIO pin in
> > TC1TimerIntr and the app gets in this state, then the PIO pin is not longer
> > being toggled. I can find no reference to NutIrqDisable for sig_TC1 in the
> > code though.
> >
> >
> >
> > Has anyone else come across this type of scenario? I'm using Nut/OS v4.6.4.
> >
> This is a problem we have seen on many occasions. The problem lies in
> that Ethernut does not allow re-entrance of IRQs. If you are to get two
> interrupts on your timer before you are able to handle them, then it
> causes the timer to just stop.
>
> The REAL solution is to rewrite the IRQ_ENTRY and IRQ_EXIT to allow for
> re-entrance of IRQs (and not disable IRQs).
Interrupts are disabled automatically during interrupt service.
You need to reenable them after saving old register context and vice
versa at the end.
Interrupt routines have a register set of their own, but since you
can interrupt another interrupt you have to take care about it's
context.
> Our temporary solution involves using a wrapping timer instead of a
> resetting timer. Additionally, if the timer's accuracy is highly
> important, you should check for overflow and handle it (ie: two
> interrupts before handler, should be detectable by amount in TC1_CV)
I fail to see how a missed interrupt can lead to timer stoping.
This sounds like a design failure somewhere else.
Reenabling interrupts adds more complexity, because interrupt routines
are not safe to modify global tables anymore - e.g. for posting an
event.
Of course loosing a timer interrupt is bad for acuracy.
Are there really any long running interrupt routines?
If there are this should be fixed instead.
--
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
More information about the En-Nut-Discussion
mailing list