Sounds like when it runs right (stable), you've set up everything right so the COP doesn't bark. I would say first you should expect all the strange things it does when the power is not stable, because anything can change (not run correctly). The COP watch dog's job is to avoid running normal code when unstable conditions could be harmful.
To plan appropriately, you should not expect to immediately run normal code without problems, considering the power may still be unstable. Make sure the COP vector runs special code, not just the normal init. For example in the surgical lasers I worked on, it disabled all triggers, displayed "COP" and stayed in infinite loop. You probably do need to clear the COP flag which explains why yours kept resetting until cycling power. I don't have the specs but I think it needs a 1 written to the flag bit or something. Always check these things in the specs; you don't want to wait for someone else to read it for you.
If you expect only temporary fluctuations, when it barks you could disable COP and just wait a sec or so, then jump to normal init code. That way there is more chance it will init properly and not mis-configure the COP.
--- In email@example.com, "Wade" <warm38@...> wrote:
> that SHOULD always be a 1 Sec timeout. We "pet the puppy" (as in watch dog timer) about every 5-40 milliSec, but SOMETIMES when power is flaky or some such problem it acts like we loaded the OPTION register with #$10 which is a 16 milliSec COP. Once it hits the COP it does not matter how often we "pet the puppy" the COP bites us and goes back to a reset.
> Any flags or bits we need to set/clear to make COP reset act like a PowerOn reset or at least respond to "petting the puppy"?
> code for petting the puppy so he don't bite.
> LDAB #$55
> STAB COPRST
> LDAB #$AA
> STAB COPRST
> Any ideas what I am missing with COP?