Well, I haven't recieved any responses, but I got around the problem. Looks like my clock speed wasn't high enough, so I was getting interrupts on top of interrupts. I'm still interested in whether it's possible to debug a problem that requires finding where you are in your code without using an ICE. --Brendan ----- Original Message ----- From: "Brendan Moran" To: Sent: Thursday, June 13, 2002 3:53 PM Subject: [PIC]: Debugging interrupt driven code with no ICD or ICE 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 hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.