Troubleshooting Siemens S7-400H CPU 417-4H PCS7 Cold Restart

1. Problem Overview

The Siemens S7-400H (High Availability) automation system, built around one or more CPU 417-4H controllers, is the redundancy backbone of nearly every SIMATIC PCS 7 process control installation in oil & gas, power, water, and chemical plants. A hallmark failure mode reported by field engineers is the controller demanding a project download every time power is restored, or — worse — entering STOP mode immediately after a power-on self-test (POST) sequence. Typical symptoms include:

• Operator Station (OS) reports "Connection to AS lost" after every maintenance power cycle.
• The CPU's STOP LED is lit, the SF (System Fault) LED is steady or flashing red, and the BATF (Battery Fault) LED on the PS 405 or PS 407 power supply module is on.
• STEP 7 / PCS 7 prompts "Download required to CPU" even though the project has not changed.
• Diagnostic buffer entries of type "STOP caused by battery failure / memory reset" or "OB not loaded" with W#16#43xx hex codes.

Although the temptation is to assume a corrupt MMC, defective flash, or a software project issue, the overwhelming root cause in the field is a depleted backup battery in the H-station's power supplies. This article documents the diagnostic path, the RAM-vs-FEPROM decision tree, and the commissioning checks a maintenance engineer should perform before opening a support ticket.

2. The 417-4H Memory Architecture

Understanding the load memory / work memory / retentive memory split is essential before blaming either hardware or software.

When the S7-400H powers up, the firmware performs this sequence:

1. POST on both redundant CPUs.
2. Fibre-optic link-up via the sync modules (last event 11..14 of the H-system).
3. Memory test on load and work memory.
4. If a battery is present and healthy → the contents of the RAM work memory and the RAM load memory card are retained → the controller performs a warm restart (Anlauf) and resumes at OB100 in seconds.
5. If no battery is present (or BATF = on) → the firmware assumes a cold start → all retentive flags/DBs/timers/counters are zeroed → a cold restart (Kaltstart) is performed via OB102 after a 5+ minute housekeeping and copy-from-load-memory cycle.
6. If neither battery nor valid load memory is available → the CPU enters STOP and demands a project download.

This is why a "fresh download every time" symptom almost always points to the backup battery — the work memory is being wiped on every power-down, the data block checksums no longer match the load image, and the firmware treats the controller as unconfigured.

3. Root Cause Analysis: The BATF LED and Why Batteries Matter

Each PS 405 10A, PS 405 4A, PS 407 10A, or PS 407 4A power supply fitted to the H-rack contains:

• One or two backup battery slots (3.6 V lithium thionyl chloride, catalog 6ES7971-0BA00 or the wider 6ES7971-0CA00 holder with two cells).
• A battery monitor switch on the front of the power supply (BATT.INDIC. / BATT.MON. / BATTERY MONITOR).
• A BATF LED (battery fault) and a relay contact wired to the CPU's DI inputs for central alarming.

If the battery monitor switch is set to OFF, the power supply will not raise BATF — but it will also not maintain RAM contents. If the switch is set to ON and the cells are below ~2.6 V, the BATF LED comes on and the CPU writes an entry into the diagnostic buffer of both H-CPUs:

Event ID 0x4310   - Backup battery voltage below threshold
Event ID 0x4311   - Backup battery exhausted, RAM cleared
Event ID 0x4312   - Battery monitoring active, no battery fitted
Event ID 0x43F2   - Memory card removed/inserted under voltage

In the source case the user reported "checked the battery and the memory card, everything is fine" but the actual reading — taken under load with the controller running — showed the cells collapsed the moment the charger resistor was loaded. The fact that replacing the batteries solved the issue confirms this classic single-point failure.

4. RAM vs. FEPROM in the 417-4H: Engineering Decision Tree

The legitimate workflow in a PCS 7 plant is therefore:

1. Commissioning & early life: Use a RAM card (typically 4 MB / 6ES7952-1AM00) with battery monitoring enabled. This permits the >300 downloads typically required to debug interlocks, CFC/SFC logic, and HMI tags.
2. Project freeze: Once the FRS (Functional Requirement Specification), FAT, and SAT are signed, perform a final "Download to target — complete" with STEP 7, then unplug the RAM card under voltage only if BATT.MON. is OFF, and replace it with an FEPROM card of equal or greater size.
3. Series production / spare controllers: Pre-flash FEPROM cards off-line using a STEP 7 "RAM-to-FEPROM" transfer operation, label the cards with project number + checksum, and store them in ESD bags.

Doing the inverse — i.e., starting with FEPROM from day one — locks the plant into a "card swap per change" cycle, which on a live H-system is an unplanned shutdown risk and is rejected by most plant owners. The original poster's instinct to consider FEPROM is therefore wrong for the H-system in service but correct for spare controllers.

5. The Cold Restart vs. Warm Restart Behaviour of the H-System

An S7-400H without a working battery cannot perform a warm restart. Instead, every power-up executes the cold-restart sequence:

1. Both CPUs power up. They negotiate master/standby via the fibre-optic sync modules (synchronisation time < 50 ms with the latest sync module firmware).
2. Each CPU runs POST (~30 s) and the H-system extended self-tests (~3–5 min, in which the EXPANSION LEDs on the IM-H may blink, the OK LED is steady green, the IFM may briefly go to STOP).
3. The load memory (integrated flash or FEPROM card) is copied to the work memory. For 4 MB this takes ~12–25 s depending on revision.
4. OB102 (cold-restart OB) is called. If OB102 is missing or has a programming error the CPU will STOP with diagnostic event 0x4307 "OB not loaded".

With healthy batteries, the warm restart is ~3–5 s, OB100 is called, and the H-system can perform a bumpless master->standby switchover at any time. This is the only mode acceptable for IEC 61508 SIL 2/3 process automation.

6. Step-by-Step Diagnostic Procedure

Use the following flowchart on the maintenance workstation (ES) connected to the H-station via PROFIBUS or Industrial Ethernet (X5 / X8 of the CPU 417-4H, default IP 192.168.0.1/0.2).

1. Open the project in STEP 7 / PCS 7. Verify you are pointing at the correct AS station (S7 Program > AS01 > Hardware).
2. Read the diagnostic buffer of both CPUs (right-click > PLC > Diagnostic/Setting > Diagnostic Buffer). Note the last 30 events. Look for the hex codes in the table below.
3. Inspect the BATF LED on both PS 405/PS 407 modules with the controller live and the battery monitor switch in the ON position.
4. Measure battery voltage at the holder terminals (BAT+ / BAT-) with a calibrated Fluke 87V or equivalent. Healthy ≥ 3.4 V, weak 2.6–3.3 V, replace < 2.6 V or any voltage dropping more than 50 mV under a 10 mA load.
5. Check the memory card: open the front flap, eject the card, inspect the contacts for oxidation, re-seat, and verify the controller recognises it (STEP 7: PLC > Memory > Memory Card Information).
6. Verify the PCS 7 / STEP 7 version: in the source thread the maintainer was specifically asked for the PCS 7 version and CPU MLFB. Confirm CPU 417-4H MLFB (6ES7417-4H??-0AB0), firmware version (read from PLC > Module Information > Firmware), and PCS 7 V8.2 / V9.0 / V9.1 SP?. A PCS 7 V7.1 SP4 on a 6ES7417-4HL04-0AB0 behaves differently from a PCS 7 V9.1 on a 6ES7417-4HT14-0AB0.
7. Run a minimal program test: temporarily load an empty S7 program containing only OB1, OB70, OB72, OB80, OB82, OB85, OB86, OB87, OB100, OB102, OB121, OB122. If this test project also goes to STOP with OB1-x errors, the issue is hardware; if it stays in RUN, the issue is the production project (refer to SIMATIC S7-400H Fault-Tolerant Systems manual (entry ID 11177407)).

6.1 Diagnostic Buffer Hex Codes (S7-400H / CPU 417-4H)

7. FEPROM Configuration Procedure (When Approved)

If the project has been formally frozen and the change-management procedure permits FEPROM, the safe configuration is:

1. Open STEP 7, go online to the AS.
2. Read the current project from the CPU (target system → PC).
3. Compare the project (target ↔ offline) to ensure zero diffs.
4. Open PLC > Memory > Download User Program to Memory Card.
5. Select the FEPROM card as the target. The wizard will compile the entire load image and erase / write the FEPROM.
6. Set the battery monitor switch on the power supply to OFF.
7. Remove the FEPROM card. The controller will continue running from the integrated 4 MB flash. Power down.
8. Insert the FEPROM card. Power up. The CPU will copy the FEPROM image to the integrated load memory and perform a cold restart (no batteries → OB102).
9. From this point, every cold restart is automatic and reproducible. Every hot online change requires swapping the FEPROM for a RAM card and re-downloading.

8. Battery Replacement Procedure

1. Open ES (engineering station) online to the AS.
2. Switch the CPU 417-4H from RUN to STOP on the primary (master) CPU. The standby CPU takes over. The OS will show "AS redundancy degraded" — this is expected.
3. Set the battery monitor switch on the PS 405/407 of the master to OFF.
4. Pull the old cell out of the holder. The new cell must be a Siemens 6ES7971-0BA00 (single cell, 3.6 V) or 6ES7971-0CA00 (double-cell holder). Never solder directly to the holder.
5. Insert the new cell with the correct polarity (positive terminal towards the holder spring).
6. Set the battery monitor switch back to ON.
7. Verify the BATF LED is OFF after ~30 s. The diagnostic buffer will record 0x4311 "battery replaced".
8. Repeat on the second power supply. The same procedure must be applied on both PSUs of the H-rack.
9. Switch the master back to RUN. The H-system re-synchronises within seconds.

8.1 Battery Lifetime Reference

9. Verification Steps After Repair

1. Read the diagnostic buffer of both CPUs and confirm the last entry is the "battery replaced" event (0x4311) and the "warm restart" event.
2. Force a power-down of the primary PSU (CB off, wait 5 s, CB on). Measure the time from power-up to RUN: must be < 10 s with batteries and OB100 executed.
3. Repeat for the secondary PSU.
4. Force a master->standby switchover from STEP 7 (PLC > Operate > Switchover). Both CPUs should be in RUN after < 50 ms.
5. Verify the H-station reports "redundancy OK" on the WinCC OS and PCS 7 Maintenance Station.
6. Check that all retentive DBs and M flags still contain their pre-power-cycle values (a quick test is a counter in DB100 that increments every cycle; after power cycle it must resume at the same value).
7. Log the change in the PCS 7 Maintenance log and close the work order.

10. Common Mistakes and Field-Engineering Caveats

• Mistake #1: Using 1.2 V NiMH cells because they were on the shelf. The BATF LED will be on, RAM will clear, and the cells will vent within a week.
• Mistake #2: Disabling the battery monitor switch to silence BATF. The CPU will still wipe RAM on power-down, and the standby CPU will refuse to take over for ~5 minutes. This is the worst possible configuration for an H-system.
• Mistake #3: Plugging in a fully erased MMC into a CPU 417-4H. The CPU will treat it as a new card and demand a download. This is not a fault.
• Mistake #4: Forcing online program changes to a CPU that is running from FEPROM. The CPU will reject the change with "target system uses FEPROM load memory".
• Mistake #5: Replacing a single battery instead of both power supply batteries in the H-rack. The other PSU will soon fail and the station will silently lose redundancy.
• Mistake #6: Powering off both power supplies simultaneously during maintenance. The H-station tolerates a single PSU loss but not a sudden 24 V drop below 19 V on both rails, which can corrupt RAM card contents and force a download.

11. Preventive Maintenance Schedule

12. Related Component Checklists

Before declaring the issue closed, run these final sanity checks against the H-system's other components — a 417-4H controller that repeatedly goes to STOP often has a coincident fault somewhere in the loop:

• Sync modules: green LINK LED on both ends, fibre-optic loss < 0.5 dB on the patch cable (clean with IEC-recommended lint-free wipe if contaminated).
• Interface modules IM 460-3 / IM 461-3: terminated, terminating resistor ON only on the outermost rack.
• DP slaves / PROFINET devices: any passivated device will not stop the H-system but will generate OB70; rule out before going deeper.
• Time master: a broken SICLOCK or NTP source can fill the diagnostic buffer with OB80 and confuse the operator.
• Firmware: keep both CPUs at the same firmware level. Mismatched firmware on master/standby is a hard-stop condition that BATF is not involved in but presents as "download required every time".