Resolving S7-400H Redundant CPU LED Flashing Work Memory Recovery

1. Problem Overview

The SIMATIC S7-400H redundant controller family (for example the CPU 414-4H and CPU 417-4H) uses two synchronized CPUs to maintain process availability. Under certain field conditions, the front-panel status LEDs on one or both rack-0 / rack-1 CPUs begin to flash in patterns that do not match the documented RUN, STOP, HOLD, or fault bitmaps. The fault is repeatable: the unit will not complete self-test, will not enter RUN, and the redundant partner will not assume master (MSTR) cleanly. Standard online download from STEP 7 does not clear the condition, and the user program is still present on the flash / EPROM card.

Field experience shows the condition is work memory (RAM) corruption caused by a mismatch between the contents of the volatile work memory and the load memory image on the flash card or EPROM. The CPU cannot reach a consistent state during startup, so the diagnostic LEDs cycle indefinitely. Because the S7-400H is designed to keep running through a single-CPU failure, the symptom on a redundant pair is often observed on only one CPU while the partner continues to control the process in solo mode.

2. Affected Hardware and Configurations

The recovery sequence in this article applies to:

• SIMATIC S7-400H redundant systems with one or two 414-4H or 417-4H CPUs in rack 0 and rack 1.
• Systems where load memory is implemented with a flash memory card (FEPROM) and the user program was downloaded online to RAM, with the option to burn to flash / EPROM / EEPROM for retention.
• Systems where EPROM is used as the load memory medium and a battery-backed RAM work memory is the volatile execution area.

Symptoms typically include:

• One or more front-panel LEDs flashing in a repeating pattern that is not the documented single-blink RUN or fault code.
• CPU will not reach a steady RUN or steady STOP state.
• Online diagnostics in STEP 7 report a work memory fault or a startup obstruction.
• Partner CPU has switched to solo / single mode and reports the failed CPU as not synchronized.

3. S7-400H LED Status Reference

Use this table to triage whether the observed pattern is normal startup behavior or the work-memory fault covered by this article. Refer to the Siemens S7-400H System Manual for the full LED state matrix.

If the RUN and STOP LEDs alternate in a pattern that does not match any documented startup state, or if the SF and BF LEDs flash together at a rate not associated with a known diagnostic interrupt, treat this as a work-memory integrity fault and proceed to recovery.

4. Root Cause Analysis

The S7-400H CPU uses a layered memory model:

• Load memory — non-volatile, contains the user program, system data, and configuration. Implemented on flash memory card (FEPROM) or EPROM.
• Work memory — volatile RAM, used for code execution and data blocks during RUN. Battery-backed so it survives power loss.
• System memory — counters, timers, flags, process image.

During normal startup, the CPU copies the load image from flash / EPROM into work memory, runs the self-test, and then transitions to RUN. Corruption of work memory can be introduced by:

1. Online programming / download operations that did not commit cleanly to non-volatile storage.
2. Loss of backup battery while mains was removed, leaving RAM contents in an undefined state.
3. Power-down during a flash write cycle, leaving the on-card image inconsistent with the internal checksum.
4. Electrostatic discharge or supply disturbance during a high-activity scan.

When the work memory is corrupt, the CPU's startup checksum or block consistency check fails, the LEDs cycle as the self-test retries, and the CPU does not reach a stable state. Re-downloading the program from STEP 7 only refreshes the RAM copy, so it does not fix the underlying problem if the load image is also inconsistent. The reliable recovery is to force a full reload from the non-volatile load image after a controlled power-down and a memory reset.

5. Pre-Recovery Safety Checks

Before any power-down on an S7-400H:

1. Confirm the process can tolerate a short loss of one CPU. On a properly configured H-system, the partner CPU should already be capable of solo control.
2. Check the HMI / SCADA for a loss-of-redundancy alarm and acknowledge it so the operator is aware the system is in single mode.
3. Verify the latest project archive is available offline (PG with STEP 7 + S7-H AddOn, or TIA Portal project with the H system block library). If a flash card is also suspect, the offline archive is your safety net.
4. Note the CPU order number (MLFB) and firmware version stamped on the front of the unit. The 414-4H ships in several firmware releases; the recovery procedure is identical but a re-load is a good moment to verify the project matches the installed firmware.
5. Confirm an EPROM programmer is on site if EPROM is the load memory medium and the project must be re-burned to it.

6. Step-by-Step Recovery Procedure

The sequence below is derived from field practice on 414-4H redundant pairs. It assumes the affected CPU is in rack 0; repeat the same sequence for rack 1 if it exhibits the same fault.

6.1 Isolate the affected CPU

1. Switch the H system to single mode via STEP 7 if the partner CPU is still healthy and controlling the process. In SIMATIC Manager, target the partner, then use PLC > Redundancy > Switch (or the equivalent TIA Portal command) to confirm the master is the healthy unit.
2. Confirm the master is the healthy CPU by checking the MSTR LED on the front of each unit.

6.2 Controlled power-down of the affected rack

1. Place the affected CPU in STOP from STEP 7. If the CPU is unresponsive to online commands, proceed to the next step.
2. Switch off the rack's power supply module (PS) using the on/off switch on the front. Wait at least 3 minutes for the internal capacitors to discharge and for any DC circuits on the backplane to decay.

6.3 Remove the battery

1. Open the front cover of the affected CPU.
2. Disconnect the back-up battery (one or two AA lithium cells, depending on the CPU variant). The battery is the round module connected to the two-pin polarized lead inside the CPU housing.
3. Wait a minimum of 30 seconds with the battery removed. This forces a true RAM cold-start by erasing the work memory contents.

6.4 Remove the flash memory card

1. Open the card slot cover on the CPU front panel.
2. Press the eject mechanism and withdraw the flash (FEPROM) memory card. Do not bend the card; store it in an anti-static sleeve.
3. Wait a further 3 to 5 minutes. The wait ensures that any residual charge on internal caches decays and the CPU's internal consistency checks reset.

6.5 Re-apply rack power and verify self-test

1. Re-apply the rack power supply.
2. Observe the LEDs. With work memory empty, the STOP LED should begin to flash slowly, indicating a normal stopped state with no valid load image. The SF LED may come on briefly during self-test; that is expected.
3. Allow the self-test to complete (typically 30 s to 2 min depending on the CPU and project size).

6.6 Insert the EPROM / flash card and reset memory

1. Switch the rack power supply off again briefly if required to insert the card safely. Many S7-400H CPUs support card insertion on a powered but STOPped CPU; consult the S7-400H System Manual for the specific CPU variant before relying on hot insertion.
2. Insert the EPROM (or reinsert the FEPROM flash card) into the slot until it latches.
3. Power the rack on. The CPU will detect the load memory and perform a memory reset automatically on the first cycle.
4. When the STOP LED becomes steady (not flashing), request a memory reset via STEP 7: PLC > Operating Mode > Memory Reset (MRES). Perform the MRES sequence exactly: turn the mode switch to MRES until the STOP LED flashes slowly, then back to STOP within 3 seconds, then to MRES again until the STOP LED stays on.

6.7 Return to RUN

1. With the STOP LED steady, turn the mode selector to RUN.
2. Observe RUN flashing at 0.5 Hz (STARTUP) followed by steady RUN. The SF and BF LEDs should extinguish as soon as the system data blocks are loaded and I/O is consistent.
3. Confirm redundancy is restored: the REDF LED on both CPUs should be off and MSTR should be on for the designated master.

7. Redundancy-Specific Considerations

On a healthy S7-400H pair, the recovery sequence can be performed rack by rack without a full process shutdown. The point to remember is order of operations:

1. Take the affected rack out of redundancy first (it is already out if it is faulted).
2. Perform the work-memory reset procedure on that rack.
3. Bring the rack back to RUN and verify synchronization is restored.
4. Only then, if the partner rack has the same symptom, perform the procedure on the partner.

If both racks are faulted simultaneously and the process has dropped, the same sequence applies to each rack in turn. The key is that a CPU with cleared work memory will load the project from the flash / EPROM card, so a coordinated reset on both racks is the correct fix.

8. Verification

After the recovery, run the following checks before handing the system back to operations:

1. LED sanity check. On both CPUs: RUN = steady green, SF = off, BF = off, REDF = off, MSTR = steady on the master, MSTR = off on the standby.
2. Diagnostic buffer. Open PLC > Diagnostic Buffer in STEP 7 / TIA Portal. The most recent entries should show MRES executed, restart (cold start), and STOP-to-RUN transition with no work memory error or block inconsistency fault.
3. Module status. Run PLC > Module Information on rack 0 and rack 1. All I/O modules should report OK and consistent online vs. configured.
4. Redundancy status. From the H system block library, evaluate FB 101 / FC 100 redundancy status word DB 100 in the user program. Both CPUs should report synchronized and master / standby roles as expected.
5. Online versus offline compare. Use PLC > Compare in STEP 7 to verify the on-line project in both CPUs matches the offline project. If a divergence is found, reconcile against the offline archive and re-download / re-burn.
6. Battery check. After the recovery, replace any battery that is more than three years old, or any battery that was disconnected for more than a few minutes during the procedure. A weak battery is the single most common root cause of work-memory inconsistency in S7-400H systems.
7. Card write integrity. If the load image was originally an EPROM, re-burn the EPROM from the offline project and reinsert it. If the original was a flash card, perform a save to flash operation from STEP 7 (PLC > Save to Memory Card) to ensure the on-card image is consistent with the now-running RAM image.

9. Firmware, Version, and Project Hygiene

The work-memory recovery sequence above is firmware-agnostic for the 414-4H and 417-4H CPU families. Two project-level items are still worth verifying during the recovery window:

• CPU firmware version. Each major firmware release for the 414-4H (for example V4.x, V5.x, V6.x families) corresponds to a STEP 7 / TIA Portal version that the project must match. If a firmware update is on the maintenance plan, the recovery window is the safest time to do it because the partner CPU is carrying the process.
• Online edits accumulated since the last flash burn. Engineers often accumulate online changes between scheduled shutdowns. When a work-memory fault occurs, the on-card image is older than the RAM image. After recovery, the on-card image must be refreshed by Save to Memory Card / EPROM burn, otherwise the next battery exhaustion will reproduce the fault.

10. Preventive Measures

To minimize the chance of recurrence on a redundant S7-400H pair:

1. Replace the lithium backup battery on a fixed 3-year schedule, regardless of the diagnostic buffer. The buffer's "Battery exhausted" event fires after the damage has already started.
2. Establish a written procedure: every online change is followed by a Save to Memory Card on both CPUs, or by a scheduled shutdown and EPROM re-burn. Do not let online changes accumulate across battery cycles.
3. Mount the rack on a clean ground. S7-400H is rugged but the I/O backplane shares ground with field wiring; a floating ground can corrupt RAM contents during field disturbances.
4. Use a UPS on the rack PS, sized for at least 5 minutes of hold-up. A clean power-down is far safer for the flash card than a hard brown-out.
5. Keep an offline project archive, versioned by date, on a network share that is itself backed up. The archive is the recovery net if both the flash card and the partner CPU are unavailable.
6. Periodically exercise the H-system redundancy by failing one CPU on purpose. The exercised partner will surface latent faults in the synchronization link before they become a production issue.

11. Troubleshooting Matrix

12. Frequently Asked Questions