Advanced Transdata

I am using a Rice17A to emulate a PIC18C252. Having a lot of fun trying to
debug 2 timer-overflow based interrupts. One is high priority, one is low.
I can't single step because the timers keep right on running, so they
overflow and interrupt pretty much immediately, when single stepping. Now
I've got my Logic analyzer to trigger properly, and its trigger out goes
into the Rice's break input, which halts it (the Rice) pretty reliably- it
only "skids" 4 instructions, which I think is pretty good. I think my
problem lies somewhere in the interrupts the way they save context, and then
restore it and continue on. One of the interrupts uses the FSR0, and the
main program loop used that too, and I thought hey! thats how the data
changes itself, but I changed the main loop to use FSR1, and no change in
problem.

I have an alphanumeric display, and I compute the bit images in the main
loop. The low-prority timer overflow interrupt "paints" one image per
interrupt. Trouble is very infrequently, the bit image memory gets
corrupted slightly, in that the image for alphanumeric display which
supposed to be in postion 2 gets put into position 3, for example. This
causes the display to flicker very slightly, but it is unacceptable. This
only happens when the high priority interrupt is enabled (which is all the
time, in the final product), but this is maddening because that interrupt
has nothing to do with the displays. It doesn't even accesses the same
variables, except WREG,BSR, and a few others, which are saved and restored
the usual way.

What I'm getting around to is : is there a way to make the Rice17A break on
a data memory change? If I could see where the bit images get corrupted,
I'd be away!

I welcome, indeed beg for, any debugging ideas!

--
Bill

Bill Chernoff wrote:

> I am using a Rice17A to emulate a PIC18C252. Having a lot of fun trying to
> debug 2 timer-overflow based interrupts.
....
> I think my
> problem lies somewhere in the interrupts the way they save context, and then
> restore it and continue on.

One place to check is the errata for your chip:
http://ww1.microchip.com/downloads/e...Doc/80058h.pdf

Thad