I was thinking of ways that I could provide diagnostics from a running PIC project, via a serial interface, but have not been able to come up with any way that will be able to provide all the useful info, to allow a problem to be debugged later.

I have had several ideas, but have had to disregard them all, so if anyone has any other ideas, I would be interested to hear them. The ideas I have thought of are as follows:

- Use the hardware watchdog - this doesn't allow anything other than a processor reset, which doesn't help diagnose what went wrong.

- Use a software watchdog, running from one of the internal timers, which is reset everytime that the watchdog is prodded. If the timer actually gets to generate an interupt then dump diags.

I thought I was getting somewhere with my second idea, but then the most important bit of information that needs to be dumped is the program counter, but by jumping into the interupt routine, the PC has been lost, and the data sheet for the 16F877, that I'm using, says that the call stack is not readable by my program.

Anyone any ideas on this problem, or are there any other solutions, other than using in circuit debugging, as I would like to leave my system running, but if it does fail, I would like to be able to get more info.

Thanks

Nick
Posted on 2004-07-14 09:37:21 by Nick
Hi, Nick,

Yes, the H/W stack can be a pain sometimes, but there is nothing we can do about it. I suppose it has to be a H/W stack in part due to the size of the opcode, which is not 8 bits in any PIC.

Anyway, I thought I'd mention this dumb idea:

1. Use the WDT to catch a failure, but after reset, test the /TO bit in the STATUS reg and if it's 0 you know the WDT caused the reset and wait there in a loop until you can retrieve the data.

Now the dumb part:

2. Use one timer clocked by the internal Tcy. After each goto instruction record the value of the timer in RAM (that will cost you 2 instructions per goto).
So you need to set aside enough locations for the more important goto's. If the program fails, these will be the data you retrieve. They can give you an indication of where the program failed, since you know which location is associated with which goto and the timer really gives you the number of instruction cycles it took to get there. If it took more or fewer cycles, at least you can take a closer look at that code.

Just a thought...
Posted on 2004-07-19 16:20:16 by VVV