- if we failed to clear the WDT timer (set ARMCOP = 0x55 and 0xAA as stated in datasheet), MCU would go to a predefined address in vector table (0xFFFE) then get itself rebooted, and I tried to set ARMCOP to other values in my code to check if internal WDT is enabled. It turne out MCU could be reset normally this way.
COP on S12(X) has dedicated reset vector, not FFFE, but FFFA. Unless you do serious mistake and attach too big capacitor on /RESET pin, or perhaps using push-button reset chip, which could sense /RESET pulled low by CPU and extend /RESET low pulse, fooling this way MPU to not distinguish any more internal reset sources with external one, then yes, MCU would take reset vector at FFFE, no matter what causes reset.
The sequence of such reset is not like you write, please study documentation. In shot MCU is reset, including all (if not the most) of registers, then on reset specific reset vector is taken and CPU jumps to it.
- When I attached debugger to to MCU at this time, I saw the PC pointer would always point to several same addresses (0x0003 and 0xFF12 as I noticed), and the COPCTL registor value became 0 instead of 0x47
Debugger could fool you. First of all, on reset breakpoints and the rest of debug HW is reset as well, so you shouldn't expect any breakpoint hit. If you simply click connect in debugger (assuming you don't allow it to reupload code), usually it resets CPU again into normal single chip mode, so you shouldn't expect and meaningful register state, reflecting what went wrong. To connect without reset, you should use, eh, IIRC CodeWarrior debugger calls it Hotplug, which wouldn't reset target and try to BDM connect without mode change.
Unlike CME and COP reset, which can be distinguished by vector taken (don't forget to remove cap on /RESET etc), other reset sources, ILAD, LVR, POR can be distinguished reading bits in CRGFLG.
