3
votes

I have a problem with using Software Watchdog Timer on a MPC875 cpu:

The timer triggers reset signal VERY fast: I get less than about half of a second betwen turning the timer on and receiving the reset signal, although I set Countdown value (SWTC) to maximum with prescaling enabled.

Here is how I do it (the JTAG script):

CF   TAR      875
CF   GRP      400F

INN

SR  PLPRCRK 0x55CCAA33
SR  PLPRCR  0x1A4D5000  ; Configure Phase-Lock Loop

SR  SCCRK   0x55CCAA33
SR  SCCR    0xF47F0002  ; Configure System Clock

SR  SYPCR   0xFFFFFF87  ; Enable the Software Watchdog Timer


SR SWSR 0x556c  ; Reset the timer
SR SWSR 0xaa39

SR SWSR 0x556c
SR SWSR 0xaa39

SR SWSR 0x556c
SR SWSR 0xaa39

SR SWSR 0x556c
SR SWSR 0xaa39

SR SWSR 0x556c
SR SWSR 0xaa39

SR SWSR 0x556c
SR SWSR 0xaa39

SR SWSR 0x556c
SR SWSR 0xaa39  ; The HRESET issued after few moments from this point

With prescaling enabled (SWP bit in SYPCR) it asserts HRESET signal in about a half of a second after the last counter reset (the latest SR SWSR command). And if I disable the prescaler the HRESET signal asserted even before even betwen first modification of the SWSR register (very short time). Thus, it seems the Timer in some way responds to the setting changes, but it is something wrong with the timing.

The System Clock and Phase-Lock Loop supposed to be configured correctly because we get same configuration on already established and running application (on top of VxWorks), but with the Watchdog Timer turned off.

Also I tried to clear SWF bit in SYPCR register to prevent the Timer counting while JTAG stopped the cpu (by asserting FRZ signal): then it works only until I exit from break/stepping mode, when I run an application the reset occurs in a very short time.

According to the Reference Manual the Timer works in the following way:

MPC885 Software Watchdog Timer diargram

There is a down-counter, when it reaches zero the circuit asserts HRESET signal or raises a System Reset Interrupt. The counter is two bytes long optionally prescaled by a factor of 2048. It is decremented at rate of System Clock divided by 2048. So the expected timeout with the prescaler enabled and maximum counter value is 1 / (80MHz / 2048) * (65535 * 2048) which is about of 3435 seconds. With the prescaler disabled it should be about 1.7 seconds. Actual values are far smaller: about 0.5 seconds with the prescaled counter and much smaller (can't even measure) with the prescaler turned off.

According to the Diagram the SWT depends only on Core Clock and the SYPCR register, here is the register description:

MPC885 System Protection Control Register - diagramMPC885 System Protection Control Register - fields descriptions

I set the value 0xFFFFFF87 (actually tried different options), which means:

  • SWTC: 0xFFFF (Timer Count, the maximum value is loaded into the internal down-counter (see diagram) upon writing magic sequence to the SWSR register).
  • BMT: 0XFF (Bus Monitor Timer Count, the maximum value)
  • BME: 1 (Bus Monitor enabled, and there is no sence to turn the bit off because it is always enabled with JTAG regardless of the configured value).
  • SWF: 0 (the timer counts even when JTAG asserts FRZ signal).
  • SWE: 1 (Watchdog is Enabled).
  • SWRI: 1 (configured to assert HRESET, switching to NMI didn't helped).
  • SWP: 1 (SWTC is prescaled by a factor of 2048).

Any suggestions?

1
"..VERY fast: I get less than about half of a second..." This is contradicting, half a second is not fast in embedded systems, it is very slow. It sounds like a typical watchdog timeout to me. I don't know your CPU but surely the watchdog time can be configured?Lundin
Lundin, thanks for your interest. I edited the post and added the description of expected values. The timeout is really too fast for this particular cpu.Dmitry
It would seem that the first step is to verify that your system clock and PLL are ok. Have you measured the clock with an oscilloscope?Lundin
No I didn't and have no such ability in near future (the remote setup). But there is There is a working application on top of VxWorks running on this board with this configuration of the System Clock. There is a bunch of timers, clocks, serial consoles and other time-based things - they simply would not work if something wrong with the clock, but everything else is ok, so I suppose the clock is is configured correctly. Is there a reason to doubt?Dmitry
can you possibly outline the differences between the working setup and the one that is failing? that might help narrow it down. From what I'm gathering here you're attempting to pull the processor out of reset via JTAG with this script but its resetting before you get too far?ThePosey

1 Answers

1
votes

Are you sure of your formula ? It looks weird. I would expect something like 1/(80MHz/2048/65536)=1.5 sec to be the correct value for the maximum period of the watchdog.