Resolving S7-400H CPU 414-4H Fault LED and Download Failures

1. Problem Statement and Scope

An S7-400H redundant controller exhibits a persistently illuminated fault LED, the standard MRES (memory reset) sequence does not clear the indicator, and STEP 7 / TIA Portal cannot push a new project to the device. The fault condition has been observed on a CPU 414-4H (6ES7 414-4HJ00-0AB0 and 6ES7 414-4HJ04-0AB0) and CPU 417-4H. Because MRES is non-responsive, the controller is outside its normal recover-in-place envelope and standard online > download user program operations will be rejected by the CPU's operating system guard.

The recovery ladder for a stuck H-CPU fault LED runs through five rungs:

1. LED-pattern triage to separate hardware from firmware faults.
2. Diagnostic buffer extraction if PG/PC communication is still partially functional.
3. Mechanical reset (MRES, then power-cycle).
4. Test rack isolation to remove field wiring and rack noise from the equation.
5. Firmware / operating-system recovery through a prepared flash card, returning the module to a state where the project can be reloaded.

Each rung has acceptance criteria; do not advance to firmware recovery until the field, rack, and grounding checks are clean.

2. S7-400H System Architecture and Why a Stuck Fault LED Matters

The S7-400H is a fault-tolerant PLC system built around two CPUs running in synchronized hot-standby. Both CPUs execute the same user program against identical process images. A fiber-optic synchronization link (or the integrated PN/DP link on -5H variants) carries the data exchange that keeps the two substates in lockstep. The redundancy status is held in the system data block OB 70 (redundancy I/O fault), OB 72 (CPU redundancy loss), and OB 80 (time error).

Because every S7-400H CPU also contains a 417-4H class execution core in the lead role, a single CPU failure should not bring the process down. The H system is designed so the standby takes over in <100 ms. A stuck fault LED combined with a refused download indicates that the controller has degraded in one of three ways:

Only the second mode - firmware corruption - is recoverable in the field without RMA. The other three demand physical intervention. Pinning down which one you have is the entire purpose of the LED triage that follows.

3. CPU 414-4H vs CPU 417-4H: Specifications That Affect Recovery

Both CPUs accept a wide range of external flash cards (the same family as SIMATIC S7-300/S7-400 MC card slot, type 5V flash). The 4 HJ04-0AB0 build is the one that ships with HW version 4 and a firmware version that must match the project's target firmware in STEP 7. Mixing project firmware and CPU firmware is the single most common reason an S7-400H rejects a download with no clear error string in the buffer.

4. LED Triage: What the Lights Actually Mean

All H-CPU faceplates share the same LED layout. Reading the pattern correctly avoids hours of bad diagnostics.

For the present symptom, the most informative patterns are:

• SF only, solid red: internal CPU fault. Recovery path: firmware/OS update first; if it persists, RMA.
• SF + STOP solid red/yellow: CPU is held in STOP, no program execution. MRES still possible in this state.
• All LEDs blink synchronously at ~2 Hz: firmware is corrupt; CPU is in bootstrap and looking for an external flash with a valid OS image. Insert a prepared flash card to recover.
• All LEDs off and no display response: power supply or backplane issue. Check PS 405 / PS 407 output, then rack power rail.

5. Diagnostic Buffer Extraction

If the CPU is not completely unresponsive - meaning the PG can still handshake over MPI/PROFIBUS/PN - capture the diagnostic buffer before any reset. The buffer is the single most useful artifact for support tickets.

1. Connect the PG to the same PROFINET subnet as the H station or to the MPI/DP port directly.
2. Open STEP 7 V5.x (the H-CPU requires classic STEP 7, not TIA Portal, for full buffer access in many firmware builds) or TIA Portal V17+ with HSP 218.
3. Navigate: Online > Accessible Nodes, select the CPU IP or MPI address.
4. Open PLC > Diagnostics/Settings > Diagnostic Buffer.
5. Export the buffer to a CSV with timestamp and event ID. Typical relevant event IDs:

Save the export and attach to the Siemens support request if escalation becomes necessary. The buffer, the buffer's full event description, and the SDB 0 snapshot are the only artifacts Siemens will request first.

6. MRES Sequence and Power-Cycle Reset

The standard memory reset on the CPU faceplate uses a 3-position selector: RUN → MRES → RUN within a precise window. If MRES does not clear the fault LED, the CPU is either in a permanent hardware-fault state or the operating system is so corrupted that the reset vector is unreachable.

1. Turn the selector to STOP. Confirm the STOP LED is solid.
2. Hold the selector in MRES until the SF LED begins to blink (roughly 3 s).
3. Release for less than 1 s, then turn back to MRES and hold until the SF LED goes off and STOP LED illuminates solidly (about 3-5 s).
4. Return selector to RUN.

If the SF LED returns within seconds, the fault is in non-volatile memory. Repeat the sequence with the external flash card removed - this forces the CPU to reset to factory-empty state and rules out flash corruption. When the flash is reinstalled, the CPU should load the user program from it.

If MRES still has no effect with the flash removed, the OS itself is suspect; advance to the firmware recovery path below.

7. Test Rack: How and Why

A test rack is a minimal S7-400 / S7-400H backplane populated with the suspected CPU, a power supply, and the required synchronization module, with no field I/O connected. The purpose is to take the rack, grounding, wiring, and slave-network environment out of the failure equation.

1. Power the test rack and confirm the PS 405/407 DC OK LED is solid green.
2. Insert the suspect CPU, power up, observe the LED pattern.
3. If the fault LED is OFF in the test rack, the field environment is the cause. Move to the grounding and wiring checks.
4. If the fault LED is ON in the test rack, the CPU itself is suspect. Move to firmware recovery.

8. Grounding, Shielding, and Field Wiring Checks

A single H-CPU with a fault LED that clears in the test rack and reappears in the field is a wiring problem until proven otherwise. Standard checks:

• Confirm the ground reference is at a single point and bonded to the cabinet PE rail with ≤ 1 Ω.
• Verify 24 V supply return is grounded at the same point as the signal returns.
• Check that the FO sync cables are run in a separate tray from the power cables, with a minimum 200 mm segregation.
• Inspect the DP and PN cable shields. They must be bonded to the cabinet ground at both ends, with EMC-compatible glands.
• Confirm no IO module is hot-swapped while the H system is in RUN. A hot-swap event can be enough to dump a CPU into a hardware fault if the module insertion latch is misaligned.

9. Firmware / OS Update via Prepared Flash Card

For an H-CPU that fails MRES, the OS update path is the only field-recoverable option. Siemens delivers OS update packages that include a self-extracting image suitable for transfer to a SIMATIC flash card.

1. Identify the exact MLFB. For the 414-4H: 6ES7 414-4HJ00-0AB0 or 6ES7 414-4HJ04-0AB0. The 04 variant ships with a newer firmware baseline than the 00 variant; they are not interchangeable.
2. Download the matching OS update from the Siemens support portal. The package is typically named S7-400H_xx_xx_xx.exe with a corresponding hotfix version list.
3. Prepare a flash card on a PG that has STEP 7 V5.x installed. The card can be programmed with the standard PG function PLC > Update Firmware using the OS update file as the source. A card with at least 8 MB of free space is recommended; 32 MB is the practical maximum and provides headroom for the user program.
4. Power down the suspect CPU, insert the prepared flash card into the slot on the faceplate.
5. Power up the CPU. The faceplate LEDs should perform their self-test, then either load the new OS automatically (solid SF during the write, then transition to STOP) or - if the OS is corrupt - enter bootstrap mode and pull the image from the card.
6. Wait for the write to complete. On a 414-4H this can take 3-8 minutes; on a 417-4H, 5-12 minutes. Do not interrupt the power during this window.
7. After the update, the CPU should come up in STOP with a clear diagnostic buffer. Reload the user program.

10. Flash Card Types and Sizing

For an H-CPU used as a recovery target, a fresh 16 MB or 32 MB card is the working choice. The OS update only requires a few MB, but the user program, F-blocks, and any DBs shipped with the station will quickly consume the rest. The card type must be a SIMATIC-branded card; consumer SD-to-flash adapters will not work in the H-CPU's proprietary slot.

11. MTBF and Service Life Reference

Siemens publishes MTBF and service-life data in the fault-tolerant system manual for the S7-400H and on the support portal. The numbers below are typical references; verify against the latest data sheet for your specific MLFB.

The MTBF is a calculated reliability reference, not a service-life guarantee. The H system's self-test is the actual mechanism by which a degraded module is detected and taken out of service. A field MTBF lookup is useful for planned end-of-life budgeting; for the immediate recovery problem, treat MTBF as a context number, not an indicator.

12. Escalation: Siemens RMA and Repair

When firmware recovery has been attempted at least twice with fresh flash cards and the fault LED remains, the CPU is in the RMA envelope.

1. Capture the diagnostic buffer export, the flash card contents (via PLC > Upload to PG if possible), the MLFB, the serial number, and the firmware version.
2. Open a support request via the Siemens Industry Online Support portal under the S7-400H product tree.
3. Request a Repair Service Order (RSO). Siemens typically provides a swap unit or a repair quote within 2-5 business days depending on the regional service center.
4. Ship the unit in an antistatic bag inside a cushioned box. The flash card stays in the field with the replacement; do not ship it back to Siemens.

13. Verification Checklist After Recovery

1. CPU powers up with no SF, no EXTF, no BUSF. STOP LED is solid until the project is loaded.
2. Diagnostic buffer is empty of 0x80xx events.
3. User program downloads without error. STEP 7 reports Download to target device completed without errors.
4. CPU transitions to RUN. The standby CPU synchronizes within 30 s. REDF remains off.
5. Force a standby switchover via the H-system operator panel. Verify the secondary CPU takes over in < 100 ms and that OB 70 / OB 72 events are entered once only.
6. Monitor the diagnostic buffer for 24 hours with the system in normal production. No recurring events at the same time of day = recovery is stable.

14. Field-Proven Edge Cases

Three situations that show up often enough to be worth listing:

• H-CPU in solo mode (single CPU on the rack). The REDF LED will be solid because there is no partner. That is normal. The SF LED is the indicator of concern.
• Sync cable hot-plug. Removing or inserting a sync fiber while the system is in RUN will trigger an OB 72. The fault clears on the next cycle. If the SF LED sticks, the FO module itself may have been damaged by the event.
• Flash card write cycle exhaustion. Repeated project downloads wear the flash. The MAINT LED will eventually turn on. Plan a flash swap on the next scheduled downtime, even if no fault is currently active.

FAQ