A TM172PDG28R that prints System fault, WDT : 0 during boot and then restarts on every power-up has a stored application that overruns the watchdog before the first scan completes. The controller is not defective. Because the stored program faults at every start, the unit cannot stay up long enough to accept an ordinary download, so recovery goes through a USB download of an empty program.
Watchdog overrun as the cause of the power-on reboot loop
A watchdog timer (WDT) is a supervisory timer that the firmware restarts each time the program cycle completes. If the application holds the CPU past the permitted time, the timer expires and the controller forces a system fault and reset. The application is stored in non-volatile memory and starts automatically at boot, so the sequence repeats: boot, load application, overrun, fault, reset.
The typical program-side cause is an unbounded loop, for example a loop whose exit condition never becomes true. Any logic that blocks the cycle for longer than the watchdog limit produces the same result.
Check 1: watch the boot sequence over several power cycles. Expected reading: the message System fault, WDT : 0 appears every time, and the unit restarts without ever reaching normal run. A repeatable message on every boot points to the stored application. A message that appears only occasionally points elsewhere (supply or wiring).
The evidence gives no meaning for the trailing 0 in the message. Read the fault-code table in the manufacturer's M172 documentation before assigning it a meaning.
Separating an application fault from a hardware or wiring fault
Remove field wiring and outputs from the controller, then power it from the supply alone. A watchdog fault that persists with all I/O disconnected cannot originate in the field wiring, because the scan-time overrun is generated inside the program.
Check 2: power up with I/O disconnected. Expected reading: same WDT : 0 message and the same restart loop. If the unit boots normally with I/O removed, the program depends on an input state, and the loop condition is tied to a signal; inspect those input-dependent branches first.
Locating the loop that starves the watchdog in the program source
Open the offline project and review every construct that can iterate without a guaranteed exit:
- Loops (
WHILE,REPEAT,FOR) whose exit variable is changed elsewhere, or only by an input, an event, or a later scan. - Loops whose upper bound is a variable that can reach a very large value or wrap around.
- Waiting on a condition inside one cycle, for example polling a flag that only updates at the start of the next scan.
Check 3: for each loop, confirm that the exit condition is modified inside the loop body on every iteration. Expected reading: a bounded, provable iteration count. A loop that fails this check is the candidate. Replace it with a state-machine step that advances one increment per scan.
Building the empty-program USB package
The stored application cannot be removed through the normal programming link because the controller resets before the link is usable. The recovery route is a USB memory device carrying a program with no logic. The upload from USB begins before the application logic starts, so it replaces the faulting program before the loop can execute.
- Create a new empty project for the same controller reference,
TM172PDG28R, with no application logic. - Build the project and export it to a USB memory device using the download-to-USB function in the programming software. The exact file structure and export command are defined in the manufacturer's M172 programming guide; follow that document rather than copying files by hand.
- Use a USB device the controller supports, formatted as the guide specifies.
Check 4: mount the USB device on the engineering PC and inspect it. Expected reading: the exported package created by the software is present, with a creation timestamp matching the export you just made.
Forcing the empty program into the controller at boot
- Remove power from the controller.
- Insert the USB device with the empty-program package.
- Apply power and leave the USB device in place until the boot sequence finishes.
- Remove the USB device only after the controller has completed its start-up.
Check 5: observe the boot sequence. Expected reading: no System fault, WDT : 0 message, no restart, and the controller reaches a stable state. With no logic loaded, a stable state proves the old application was the cause.
Check 6: power-cycle once more without the USB device. Expected reading: the same stable start. If the fault returns, the empty program did not load; repeat the export and confirm the USB device format against the manufacturer's guide.
Redeploying the corrected program and confirming a stable run
- Correct the loop in the offline project as identified in Check 3.
- Download the corrected application through the normal programming link.
- Perform a full power cycle and run for a period covering the longest normal machine sequence.
Final verification 1: after each of several consecutive power cycles, the boot message contains no WDT fault. Expected reading: normal start every time.
Final verification 2: exercise every code path that contains a loop, including paths driven by rare input states. Expected reading: no restart and no fault message during the sequence. A restart during a specific path identifies a loop that still lacks a bounded exit.
Final verification 3: reconnect the field I/O and repeat a start-up. Expected reading: normal start with I/O connected, matching the result from Check 2.
FAQ
How do I clear System fault, WDT : 0 on a TM172PDG28R?
Replace the faulting application with an empty program using a USB memory device inserted before power-up. The USB upload starts before the logic runs, so it overwrites the program that causes the watchdog overrun. Then correct the program and download it normally.
How do I stop an M172 restarting at every power-on?
Identify the loop or long-running logic that exceeds the watchdog time and remove or bound it. Recover the unit first with the empty-program USB package, because the controller resets before a normal download can complete.
How do I find the code that triggers a WDT fault?
Review the offline project for loops without a guaranteed exit, such as WHILE or REPEAT loops whose exit variable is not changed inside the loop body. Convert each to one step per scan and repeat the power-cycle test.