Hi Jeff (and everybody else)
>Andrei,
>
>Did you find the bug yet?
No, I didn't.
The possible issue with the PIT interrupt seems to have been teaser.
As we have seen from the various responses, it does not seem like you
have to do anything to acknowledge the PIT.
The problem that I was trying to track down was actually with the
TPU. When using the UART function, I would occasionally see a
doubling of the input characters and a mass retransmission of my
output buffers by my interrupt routines. After much head scratching
and searching I deduced that the interrupt routines were occasionally
triggered twice for a single event (I was getting two interrupts for
a single transmitter empty event, and two interrupts for a single
character received event). I really didn't expect to see an issue as
I only had 12 half UARTs running at 300 baud, one half UART running
at 9600 baud, two DIOs, and one PWM that was turned off.
I had never seen anything like this before, but I am using a new
compiler (GCC), and running at 4MHz instead of 16MHz, so the low
level routines for my OS (uC/OS-II) had to be reworked.
I eventually ran across an app note for the TPU UART that mentioned
the position of the interrupt clear instructions with respect to the
accessing of the data buffers, and how you CAN get doubling of interrupts.
After much head scratching and experimentation, I bolstered other
pieces of the system to be able to detect and throw away packets that
have the corrupted data.
>If not have you seen the errata about having an
>external device using the same interrupt level as the PIT? Could that be
>your problem?
No, I don't think so. I'll look for the errata sheet though. I'm not
using any external interrupts and the PIT is the only device assigned
to its interrupt level.
>(Sorry I don't have a reference for you.)
>
>Jeff
Thanks for your help,
Andrei