Troubleshooting Siemens CPU 414-4H INTF and EXTF LED Flicker Fault

The Siemens S7-400H fault-tolerant CPU 414-4H (MLFB 6ES7 414-4HJ00-0AB0) may enter a hard fault state where the INTF (Internal Fault) and EXTF (External Fault) LEDs blink rapidly and the unit subsequently drops out of RUN, dropping both the redundant CPU and the entire H-station into the DEFECT operating state. This article documents the diagnostic procedure, firmware verification steps, and isolation methodology used by Siemens support engineers to determine whether the fault is recoverable in the field or whether the CPU must be returned for repair.

1. Affected Hardware and Firmware

The defective message reported by blinking INTF+EXTF is not version-specific but appears more frequently on 6ES7 414-4HJ00-0AB0 units running firmware prior to V 3.1.5. Always confirm the firmware status before attempting any other diagnosis.

2. LED Reference Table for the CPU 414-4H

Correct LED interpretation is the first diagnostic step. The front-panel LEDs of the 414-4H include INTF, EXTF, FRCE, CRST, RUN, and STOP. Their meanings are documented in the Siemens S7-400 CPU 414-4H Manual:

3. Root Cause Analysis of the DEFECT State

When a 414-4H enters DEFECT, the operating system has detected a condition it cannot clear autonomously. Documented causes, in approximate frequency order for the 414-4H family:

1. Firmware crash on hot restart. Older firmware (pre-V 3.1.0 and early V 3.1.x) had known issues during OB100/OB101 execution with large S7-Connection counts. Update to V 3.1.5 or later (see Operating System Update for CPU 412/414/417-4H).
2. Corrupted memory card. An MMC of the wrong type (MMC for S7-300 used in 400) or a card with bad blocks will prevent POST and force DEFECT. Required card type is 6ES7 952-1KM00-0AA0 (2 MB) or larger 6ES7 952-1KP00-0AA0 (8 MB).
3. Subrack / backplane fault. UR2/UR2-F power-rail failure on the redundant subrack. Test with the suspect CPU on a known-good UR2.
4. Synchronization module / fiber-optic fault. Sync module 1/2 plugged but fiber pairs crossed or broken. The H-system will refuse to come up and may cascade a DEFECT on both CPUs.
5. Hardware defect. Genuine CPU board failure (memory test failure, ASIC failure, watch-dog time-out). Visible only via diagnostic buffer from a successful boot, or via bench test.

4. Step-by-Step Diagnostic Procedure

4.1 Power-Cycle and Capture the Diagnostic Buffer

The diagnostic buffer is the primary source of fault information and survives a power cycle. Retrieve it from STEP 7 as follows:

1. Open SIMATIC Manager and the offline project that matches the PLC's hardware configuration. If the project is unknown, create a new project with the correct station configuration (PC-Interface must match the PC adapter used).
2. Select PLC → Diagnostic/Setting → Diagnostic Buffer in the menu.
3. If the CPU is in DEFECT it will normally still respond on MPI/Profibus. The buffer is downloaded automatically.
4. Save the buffer via File → Save As in CSV format and archive it. The first (most recent) entry contains the DEFECT cause event; the second-to-last entry typically contains the OB that failed (e.g. OB85, OB122, OB121).

Typical diagnostic-buffer entries for the failure pattern documented in this article:

4.2 Verify the Operating System Version

The firmware version is read either from the diagnostic buffer (PLC → Diagnostic/Setting → Module Information, tab General) or, when the CPU is in DEFECT, from the label on the memory card that was last inserted. Compatible firmware files are listed under the Siemens Support entry Operating System Updates for CPU 412-3H / 414-4H / 414-4H PG / 417-4H.

Firmware update procedure via memory card (no PG required):

1. Download the firmware S7FW file from the Siemens Support page listed above (e.g. S7C414H.V3.1.5.fw).
2. Prepare a FAT16-formatted MMC (6ES7 952-1xxx) and place the firmware file at the card root.
3. Insert the card into the defective CPU.
4. Switch the mode selector from RUN → STOP → MRES (hold 3 s until STOP blinks fast, release to STOP, repeat).
5. Power-cycle the CPU. The RUN LED will blink for the duration of the firmware load (3–8 minutes).
6. After the load completes, the CPU will remain in STOP. Pull the firmware card and insert the program card.

5. Standalone Isolation Test (Mandatory)

The fastest way to confirm hardware failure of the 414-4H is to remove the suspect CPU from the H-subrack and bench-test it as a standalone S7-400 station. Required hardware:

• UR2 subrack (6ES7 400-2JA00-0AA0) or UR1 (6ES7 400-1JA01-0AA0).
• PS 405 (10 A) or PS 407 power supply.
• Known-good MMC with the latest firmware.
• One DP or PN interface connected to a programming PG.

Test procedure:

1. Strip the CPU of all front-mounted modules: remove sync modules, fiber-optic cables, and any CP.
2. Install on the test UR2 in slot 3 (CPU slot).
3. Insert the firmware-only MMC (no user program).
4. Apply power. Observe the LED sequence during POST: STOP should illuminate within 5 s. After a further 30–60 s the RUN LED should blink during internal tests, then settle to RUN steady.
5. If the same INTF+EXTF fast-blink pattern repeats on the test rack with a known-good subrack and known-good firmware card, the CPU board is defective.
6. If the CPU comes up clean on the test rack, the original H-subrack, power supply, or sync modules were the root cause.

6. H-System Specific Considerations

Because the 414-4H is a redundant CPU, additional checks apply before opening a repair order:

1. Did both CPUs enter DEFECT, or only one? If only one CPU failed, swap the suspect CPU with a spare, restart the H-pair, and observe whether the spare goes into DEFECT in the same slot. If yes — subrack slot fault. If no — original CPU is defective.
2. Check the H-station redundancy status in STEP 7 (H-CPU → Mode). A single CPU loss in an H-pair should normally keep the process running on the master CPU. If the entire station went down with only one CPU failed, verify the user program handles OB70 (I/O redundancy loss) and OB72 (CPU redundancy loss).
3. Verify the synchronization cable plant. Use the H-Sync Test in the S7-400H manual. Distance limitation is 10 m between sync modules when using the standard plastic fiber. Fiber attenuation > 6 dB will cause the standby CPU to refuse to take over and may throw a CPU fault.
4. Verify firmware parity between the pair. Mixed firmware on an H-pair is rejected by the H-system manager. Both CPUs must run the same V-version.

7. Recovery Procedure After Confirming Hardware Fault

When the bench test confirms a CPU board defect, the supported recovery path is:

1. Order a Siemens repair or replacement via the local Siemens representative. Reference the MLFB 6ES7 414-4HJ00-0AB0 and the diagnostic-buffer dump.
2. While the replacement is en route, the second CPU of the H-pair will operate solo, providing reduced availability. Verify that OB72 and OB73 are loaded in the user program so that the process does not stop when only one CPU is present.
3. After replacement, the new CPU must be loaded with the matching firmware (typically V 3.1.5 or the firmware version currently in service on the H-pair), then joined to the H-station via PLC → H-CPU → Join.
4. After join, verify H-Sync is established (no diagnostic buffer entries of class 0x49xx) before returning the process to automatic control.

8. Verification Checklist After Repair / Update

9. Common Pitfalls

• Pulling the wrong memory card. The 414-4H does not boot without a card in slot 1. If both slots are populated, slot 1 takes precedence.
• Re-inserting a 300-series MMC. The MMC catalog number must be the 400-family type. A 300-series MMC mechanically fits but will not be recognized and the CPU will post DEFECT.
• MRES used incorrectly. Holding MRES for >10 s can re-trigger the DEFECT state on a marginal CPU. Use MRES only with a known-good firmware card present.
• Firmware downgrade attempt. Siemens does not support downgrade on the 414-4H. Downgrading from V 3.1.5 to an earlier V 3.1.x is blocked by the operating-system loader.
• Ignoring the H-station before RMA. Confirming a CPU fault on the bench is the only way to obtain an in-warranty repair. Returning a working CPU on suspicion will be refused.

10. Preventive Maintenance Recommendations

• Apply firmware V 3.1.5 or later across all S7-400H stations during the next scheduled outage. The release notes (see entry 16661594) list corrections relevant to the DEFECT pattern.
• Maintain a hot-spare 414-4H at the same firmware revision for fast swap.
• Quarterly export of the diagnostic buffer to a network drive for trend analysis. Repeated 0x13A2 or 0x49xx entries are an early warning of impending hardware failure.
• Inspect sync-module fiber-optic connectors every 12 months; replace plastic fibers showing yellowing.
• Verify the H-pair firmware parity check during every PLC backup procedure.

11. Quick-Reference Decision Tree

Use the following flow when called to a 414-4H with rapidly blinking INTF+EXTF LEDs:

1. Can the PG connect online? — Yes: read diagnostic buffer → branch on event class. No: continue.
2. Does the CPU contain a memory card? — No: insert known-good firmware card → power-cycle.
3. Does it boot on the test rack? — Yes: original subrack/sync plant fault. No: defective CPU, RMA.
4. After repair, verify the checklist in Section 8 before returning the line to production.