68300

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