I think you have appreciate correct your problem. Could be a stack false
jump. I'll do it in a different way without too much simulation: split
your interrupt code in two, tmr0 related and int/rb0 related. Check if
both are going fine with your usart. If yes then :
-- check if you save and restore corectly all your registers
-- check if you deactivate the interrupt while you run specific interrupt
serviceing code
-- check the main code again, it could be a place which required to
deactivate the interrupts, maybe in the serial routine ?

regards, Vasile


On Thu, 13 Jun 2002, Brendan Moran wrote:

> I'm trying to write a serial transfer host on a PIC16F877 that uses two interrupt sources: TMR0 and RB0/INT.  The code appears to work fine at first, but after a while, I get a change on a pin that is not only unexpected, but has moderately disatarous consequences (i.e. aborts a transfer and the rest never recovers)
>
> What I'm wondering is if there is any way that I can extract the top value from the stack to read it, not return to it.
>
> When I simulate the software, it looks like it should be fine, but when I actually come to running it, there's that problem.  I think the reason it simulates fine is that there is no reasonable way to simulate the remote device that the host is communicating with.
>
> So, any ideas on how to determine whre in my code I am when I get this error?
>
> --Brendan
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body