Resolving S7-400H CPU 414-4H Reserve CPU STOP LED Blinking

1. Problem Description

Engineers commissioning or maintaining a Siemens S7-400H redundant station built around the CPU 414-4H (order number 6ES7 414-4HM14-0AB0) frequently report a two-stage fault signature immediately after a STEP 7 program download, a cold restart, or a forced re-link of the redundant pair:

• Rack 0 (master) completes the download and reaches RUN within seconds. The user program executes and the process responds to the I/O.
• Rack 1 (reserve) remains in STOP with the STOP LED blinking continuously at the slow self-test rate. The reserve never issues a LINK-UP request and never enters redundant RUN. In some plants the master also reports Partner not available or Update aborted.

The same signature has been reproduced on the CPU 412-3H (6ES7 412-3HJ14-0AB0) and the CPU 417-4H (6ES7 417-4HT14-0AB0) when both racks carry firmware V4.5.0. The fault is not a wiring, fiber-optic, or backplane problem. It is a known firmware defect (event 4550 8F37 0039) caused by the interaction between the forcing function and the code memory self-test.

2. Affected Hardware Matrix

All three H-CPUs share the same firmware branch and the same forcing engine. The defect is documented in the Siemens product support database for firmware V4.5.0 with active force job and code memory test enabled. Always verify the order number on the front-panel label; mixed order numbers in a redundant pair are not supported and produce a different link-up failure mode.

3. H-System Operating States from POWER ON to Redundant RUN

The transition path the reserve CPU must follow is fixed by the S7-400H firmware. Knowing the path is the fastest way to localize which transition is stuck when the STOP LED blinks indefinitely.

1. POWER ON → STOP (both racks): After the PS 405 or PS 407 power supply comes up, both CPUs sit in STOP. The rack is electrically healthy but no program runs.
2. Master → STARTUP: The CPU in Rack 0 is the master by parameter assignment (or by the lowest rack number when both racks are equally configured). It executes OB 100 (restart) or OB 102 (cold restart) according to the startup type set in HW Config.
3. Master → SINGLE mode: After a successful startup the master runs alone. The reserve is still in STOP. During the upcoming LINK-UP no block may be open in the Monitor window and no variable table (VAT) may be active; closing them in STEP 7 prevents an inadvertent re-trigger of the V4.5.0 forcing race.
4. LINK-UP request from the reserve: The reserve CPU (Rack 1) requests LINK-UP. The master and reserve compare their user program images block by block. If differences are detected, the master pushes the program to the reserve over the fiber-optic pair.
5. UPDATE phase: After a successful LINK-UP, the master copies all dynamic data to the reserve: process image of the inputs (PII), process image of the outputs (PIQ), timers (T), counters (C), bit memory (M), and data blocks (DB).
6. REDUNDANT mode: Both CPUs run the user program in lockstep. Event-synchronous I/O updates occur on the active backplane bus, and either CPU is hot-swap-capable.

Total time from cold restart of Rack 1 to redundant RUN is dominated by the code memory self-test. A healthy V4.5.0 station typically completes the test in 20 to 30 minutes; a station carrying the forcing defect can stay in the self-test for up to 90 minutes and then fail with diagnostic event 4550 8F37 0039.

4. Cold Restart and Self-Test Timing

The slow STOP LED blink (about 0.5 Hz) is the H-system code memory self-test. The blink rate is fixed by firmware and is identical on every H-CPU; the duration scales with the work-memory footprint and the number of blocks in the program.

When SFC 90 is used to disable the test (see Section 7), the self-test no longer runs and the reserve typically reaches LINK-UP in 3 to 5 minutes regardless of program size.

5. Root Cause: V4.5.0 Forcing + Code Memory Self-Test Collision

The forcing function of H-CPUs at firmware V4.5.0 collides with the code memory self-test when both are active in the same time window. The collision does not produce an immediate error; instead it corrupts the force-job table in a way that surfaces only after several minutes of sustained forcing.

Siemens categorises the failure as a two-sided defect: both the master and the reserve CPU are affected, and the diagnostic buffer of the CPU that crashes first records the event before the partner CPU drops out.

5.1 Trigger Conditions

• Firmware V4.5.0 installed on both H-CPUs.
• A force job is active in STEP 7 (or TIA Portal) and has been applied for an extended period.
• The code memory test is enabled in the CPU properties (default in H-CPUs at V4.5.0).

5.2 Typical Time to Failure

The defect is reported in the field across a window of 1 to 90 minutes of sustained forcing. A short force pulse (a few seconds for a single bit) does not trigger the bug; the crash probability grows with the total time the force table remains active. Forcing during a switchover is the worst case because the force table is being moved between CPUs at the exact moment the memory test runs.

6. Diagnostic Buffer Event Decoding

The diagnostic buffer of an S7-400 CPU uses a four-level event record. The forcing fault records as follows:

If a force job has been running for several minutes, the diagnostic buffer of the first CPU to fail will contain event 4550 8F37 0039 within one minute of the actual fault. The partner CPU records a partner-loss entry (typically 65280 0001 0001) within the next cycle. Read the buffer on the master first; the reserve may have already crashed before the buffer could be written to the MMC.

7. Workaround: Disable the Code Memory Self-Test via SFC 90

The official workaround from Siemens for plants that cannot immediately upgrade to V4.5.1 is to disable the code memory self-test in the user program. This is the only field-proven mitigation; clearing the force job alone is not sufficient because the test continues to run in the background and re-triggers the race.

7.1 Required Block Call

• Call SFC 90 (code memory self-test control) once in the startup OB.
• Use OB 100 for warm restart or OB 102 for cold restart.
• Set MODE := 20 (function code: code memory test control).
• Set SUBMODE := 1 (action: disable code memory test).

7.2 STL Snippet for OB 100 / OB 102

      CALL  SFC   90
       MODE   := 20           // code memory test control
       SUBMODE:= 1            // 1 = disable test
       RET_VAL:= MW 100       // error code (0 = OK)
      BE

7.3 SCL / Structured Text Equivalent

// Place at the end of OB 100 / OB 102
"SFC90_DB".MODE    := 20;
"SFC90_DB".SUBMODE := 1;
"SFC90_DB".RET_VAL := 0;
SFC90_DB();

7.4 Download and Restart Procedure

1. Open the project in STEP 7 V5.5 SP4 or later (TIA Portal V13 SP1 or later also supports S7-400H).
2. Insert the SFC 90 call at the end of OB 100 and/or OB 102.
3. Save and compile. Resolve any compiler warnings about the instance DB.
4. Take Rack 0 offline; download the entire program to the master in standalone mode.
5. Power down Rack 0; power up Rack 1 and download the same program to the reserve in standalone mode.
6. Power up both racks. The reserve will now skip the self-test and reach LINK-UP in 3 to 5 minutes.

8. Alternative Workarounds

1. Remove all force jobs before commissioning or switchover. With the code memory test still active and forcing absent, the V4.5.0 bug cannot trigger. This is the simplest field mitigation.
2. Disable forcing in HW Config CPU properties for the duration of the test campaign. This is acceptable for new commissioning but blocks in-process debugging.
3. Run only one rack at a time (single mode). With Rack 1 powered down, the redundant code path is not exercised and the collision cannot occur. This is a temporary measure only; the station loses hot-standby redundancy.
4. Shorten force duration to seconds at a time. The race condition is probabilistic; force jobs under about 30 seconds rarely trigger the bug.

None of the alternatives replace SFC 90 in production. Treat them as stopgaps until V4.5.1 can be installed.

9. Forcing and Manual Switchover

A second related symptom appears during manual switchover with a force job still active. The operator initiates a switchover (HMI switchover button, STEP 7 Switchover command, or a loss-of-master condition). The reserve CPU, which was previously the partner, becomes the new master and re-runs its startup. The force job, which was set on the previous master, is not part of the redundant data set - it is local to the CPU that received it. The new master therefore restarts without the force table, and any logic that depends on forced bits in OB 1 behaves as if the forces had been cleared.

The reported signature is: The standby CPU went to RUN by warm restart during switchover, but my forced values disappeared. This is expected behaviour on H-CPUs at V4.5.0 and is the same mechanism that triggers the V4.5.0 crash when the test runs at the same time.

9.1 Recommended Procedure Before Manual Switchover

1. Open STEP 7 and connect online to the active master.
2. Select Force > Stop Forcing (or Force > Delete Force Job).
3. Confirm the force table is empty: Force > Display Force Jobs should show zero entries.
4. Wait at least one full OB 1 cycle so the force table is de-allocated from the work memory.
5. Issue the switchover command. Both racks must return to redundant RUN within 3 seconds.
6. Re-apply forces on the new master only after redundant RUN is established.

10. Step-by-Step Commissioning Procedure on V4.5.0

1. Verify order numbers. Both CPUs must show 6ES7 414-4HM14-0AB0 (or the equivalent 412-3H / 417-4H MLFB). Mismatched order numbers are an instant red flag and are not supported by the H-system link-up.
2. Check firmware version. In HW Config, right-click the CPU > Object Properties > Diagnostics / Information. Confirm both racks show firmware V4.5.0 or newer. Mixed firmware in a redundant pair is rejected by the link-up check.
3. Power up Rack 0 alone. Wait for RUN. This validates the master image, the user program, and the SYNC-module fiber-optic link.
4. Insert the SFC 90 workaround in OB 100 / OB 102 (when no F-program is present) before the second rack comes online.
5. Download to the master with PLC > Download to Target System > Entire Program. This transfers OB 100 / OB 102 with the workaround to the running master.
6. Power up Rack 1. The reserve will now skip the self-test and reach LINK-UP in 3 to 5 minutes instead of 20 to 30 minutes.
7. Verify redundant RUN. In STEP 7, PLC > Redundancy > Operating State must show both CPUs as RUN (redundant).
8. Test switchover. Trigger a manual switchover. Both racks must reach RUN within 3 seconds; the diagnostic buffer must contain the partner-specific switchover entry.
9. Plan the firmware upgrade to V4.5.1 at the next planned outage. V4.5.1 is a free-of-charge firmware update; it removes the forcing + memory test collision and allows the SFC 90 workaround to be removed.

11. Firmware Upgrade Path to V4.5.1

The corrected firmware V4.5.1 is the recommended long-term fix and is required wherever an F-program is in use. The upgrade procedure is asymmetric because both racks must be in the same firmware state before they can re-link.

1. Obtain the firmware file from the Siemens Industry Online Support portal under the CPU 414-4H entry (or the equivalent 412-3H / 417-4H entry). Typical file name pattern: CPU_414-4H_V45_1.fw.
2. Power down Rack 1. Upgrade the reserve first using SIMATIC Manager > PLC > Update Firmware.
3. After Rack 1 returns to RUN, switch over so the upgraded CPU becomes the master.
4. Power down the former master (now reserve) and upgrade it.
5. Re-link the pair and verify redundant RUN. The SFC 90 workaround can now be removed.

12. Verification Checklist and Troubleshooting Matrix

12.1 Verification Checklist

12.2 Troubleshooting Matrix