Fix Siemens S7-1200 CPU Stuck in STOP: HW Configuration Inconsistent

An S7-1200 CPU that compiles, downloads, and reports matching order numbers in the diagnostics buffer can still refuse to enter RUN mode if its online hardware configuration diverges from the offline project. This article documents the field-proven recovery procedure for the "Pending startup inhibit(s): HW configuration inconsistent (TIA portal activity) - Manual warm start required" condition on firmware-level CPU 1214C DC/DC/DC (order number 6ES7 214-1AE30-0XB0) and other S7-1200 CPUs, and explains why a basic Download to Device in TIA Portal is not enough to clear it.

1. Problem Description

The fault presents the following symptoms on a SIMATIC S7-1200 (CPU 1214C DC/DC/DC, MLFB 6ES7 214-1AE30-0XB0, firmware release V4.x):

• TIA Portal project compiles without errors.
• Initial download to the CPU completes and reports success.
• CPU remains in STOP state; pressing RUN in the online panel produces brief RUN/STOP, ERROR, and MAINT LED activity plus network Rx/Tx on the PROFINET port, then the CPU returns to STOP.
• Online > Diagnostics > Diagnostics buffer lists:
  • "New startup inhibit information - Current CPU operating state: STOP"
  • "Pending startup inhibit(s): - HW configuration inconsistent (TIA portal activity) - Manual warm start required"
  • "The loaded configuration and the offline project are not identical. The online and offline module configuration data are different. Order number: 6ES7 214-1AE30-0XB0 / Configured order number: 6ES7 214-1AE30-0XB0"
• Online > Accessible nodes shows the CPU with identical MLFB on both sides.
• MRES via the online panel does not clear the inhibit.
• Replacing the CPU with a brand-new unit of the same order number reproduces the fault immediately after download.

The key diagnostic clue is that the order numbers reported for the online and offline configuration are identical, yet the CPU still claims the configurations are different. This is a flag set by the CPU because the system data blocks generated by TIA Portal do not match the system data currently loaded in the target.

2. Affected Hardware and Software

For background, see the official SIMATIC S7-1200 Programmable Controller system manual on the Siemens Industry Online Support portal: SIMATIC S7-1200 Programmable Controller - System Manual (entry ID 91696622).

3. Root Cause Analysis

The S7-1200 boot loader validates the system data blocks (SDBs) loaded into the work memory against the detected module topology at power-on. A "HW configuration inconsistent" startup inhibit is raised when the SDB checksum or the module list produced by the offline build of the hardware configuration does not match what the CPU has in its load memory.

Three common upstream causes lead to this state:

1. Stale SDBs in load memory. A previous compile/deploy sequence (or a partial download of program blocks only) leaves old system data behind. Subsequent edits to the device configuration in the project tree are saved to the offline project but are not propagated to the CPU until a full Download to device with Replace system data semantics runs.
2. Missing "Compile > Hardware (rebuild all)" step. When the device or rack configuration is edited (adding/removing signal modules, changing PROFINET device names, swapping the CPU type, or modifying slot assignments), the offline hardware configuration must be recompiled before it is downloaded. Without this step, the SDBs delivered to the CPU are stale even though the project itself looks consistent.
3. Program-only download in a previous session. An earlier Download to device configured for "Download to device: program blocks only" or "PLC program only" loaded the user blocks but did not overwrite the system data. The CPU's runtime check then fails when the next startup compares the new program against the old SDBs.

The user's report confirms the third cause: the project compiled cleanly, the user expected TIA Portal to push the new hardware configuration "automatically" or "during the next software download", and that expectation was wrong. The fix is to force a Compile > Hardware (rebuild all) followed by a Download to device > All that explicitly overwrites the existing SDBs in load memory.

4. Solution Procedure

Execute the following steps in TIA Portal. They are written for TIA V16/V17/V18 and are functionally identical in V15.1.

4.1 Prerequisites

• Project opens without consistency errors in the project tree.
• PG/PC interface is set to the correct network adapter (accessible nodes must list the CPU).
• You have administrator rights on the engineering station; TIA Portal writes to %ProgramData%\Siemens\Automation\ during compile/deploy.

4.2 Step-by-step recovery

1. Open the project and select the CPU in the project tree (e.g., PLC_1 > CPU 1214C DC/DC/DC).
2. Recompile the hardware configuration. In the project tree, right-click the CPU or the Device configuration editor and choose Compile > Hardware (rebuild all). Wait for the compile to finish; check the Info / Compile pane for errors and warnings.
3. Open the Devices & networks editor and verify the rack, slot assignments, and any distributed I/O (PROFINET devices) match the physical layout. The order number for the central CPU must equal the MLFB printed on the front of the physical unit.
4. Re-select the PG/PC interface. Online > Accessible nodes, pick the CPU from the list, then close the dialog.
5. Use a full, replacement download. In the project tree, right-click the CPU and choose Download to device > All (not "Program blocks only"). In the Download preview dialog, confirm that the action shows:
   • Replace system data in target (or equivalent "Overwrite system data") is selected.
   • The Consistent download option is selected, not Download to device: program only.
6. Click Load. If the CPU asks to stop, accept. If it prompts for an Assign IP address or Assign PROFINET device name, accept and confirm.
7. Restart the CPU in warm restart mode. After the download completes, TIA Portal typically offers Start module / Finish & start. Click Start module to issue a manual warm start. The startup inhibit will clear because the system data now matches the offline build.
8. Verify RUN state. The RUN/STOP LED should be solid green; ERROR and MAINT LEDs should be off.

4.3 Alternative recovery when the CPU still refuses

If the inhibit persists after a successful full download, the load memory has residual data that survives the download. Use one of the following escalation paths:

1. MRES to factory default via the online panel. In the project tree, right-click the CPU > Online & diagnostics > Operation > Memory reset (MRES). Choose Format / delete user program and reset to factory settings. Then repeat steps 4.2-1 through 4.2-7 with a fresh full download.
2. Reset via the physical mode switch. Set the mode switch to STOP, then perform the MRES sequence: STOP, switch to MRES, hold for ~3 s, return to STOP. The CPU will flash the MAINT LED; cycle power and download again.
3. Reset IP and PROFINET name first. Some engineers find that the inhibit reappears when the IP or PROFINET device name on the CPU still matches an older project's SDBs. From Online & diagnostics > Functions > Assign IP address and Assign PROFINET device name, reset to defaults, then download.

5. Verification

Confirm the fix has been applied correctly by running all of the checks below:

6. Diagnostic Buffer Event Reference

When reading the diagnostics buffer in TIA Portal (Online & diagnostics > Diagnostics buffer), the following events are the canonical signatures for the fault described in this article. Use this table to triage other reported "STOP / inconsistent" events.

For more detail on the diagnostics buffer and its event ID encoding, see the SIMATIC S7-1200 system manual and the S7-1200 function manuals in the Siemens Industry Online Support portal: S7-1200 Automation System - Manual Collection.

7. Prevention: Engineering Workflow Checklist

To prevent this class of startup inhibit from recurring, standardize the following workflow for every project edit cycle on S7-1200 and S7-1500 systems:

1. Edit the device configuration first. Any change to the rack, modules, IP address, or PROFINET device name must precede the next compile.
2. Always run Compile > Hardware (rebuild all) after editing the device configuration. TIA Portal does not push the SDBs unless a clean compile has produced new ones.
3. Use Download to device > All for the first download and any download that includes HW changes. Reserve Program blocks only for hot fixes that do not touch the device configuration.
4. Check the download preview dialog for the "Replace system data" toggle. If it is greyed out or missing, the target does not yet have matching SDBs and the download is incomplete.
5. Always finish with a manual warm start when the diagnostics buffer reports "Manual warm start required". Do not assume a power cycle is equivalent; the inhibit can survive power-on if SDBs are still inconsistent.
6. Version-control the project (e.g., TIA Portal project under Git or SVN). A corrupted or partially modified offline project is a frequent root cause that is invisible until the next download.
7. Keep the TIA Portal installation consistent across the engineering team. Mixing TIA V16 and V17 on a project that targets a V4.4 firmware CPU can produce SDBs that the older runtime rejects with a "HW configuration inconsistent" event.

8. Common Edge Cases and How to Recognize Them

The error pattern described in this article has several look-alike faults. Use the matrix below to triage.

9. Related Firmware and Tooling Notes

The S7-1200 firmware V4.x line has historically been stable for the diagnostics-buffer error described here, but the following practices reduce the chance of seeing it on a fresh deployment:

• Match the TIA Portal version to the CPU firmware capability set. For firmware V4.6 CPUs, use TIA V18 or later. For firmware V4.4, TIA V17 is the minimum supported tool.
• After upgrading TIA Portal, run Project > Compile > Software (rebuild all) and Compile > Hardware (rebuild all) before the first download to a CPU.
• Use the S7-1200 firmware update tool (SIMATIC Automation Tool or the firmware assistant in TIA Portal) only when the CPU is in STOP. Do not interrupt a firmware update; a bricked CPU will need a factory reset and a serial-mode recovery.

For official firmware notes and known issues, see the Siemens Industry Online Support entry for the SIMATIC S7-1200: SIMATIC S7-1200 product page and the Siemens Industry Online Support portal.

10. Engineering Field Notes

Three principles to keep in mind when a S7-1200 CPU refuses to leave STOP after a download:

1. Trust the diagnostics buffer, not the order-number string. An identical MLFB on both sides is the most common confusing case, but the system-data checksum below the MLFB is what the CPU is actually comparing.
2. Replace the CPU last. The fact that the fault reproduced on a brand-new CPU of the same MLFB is itself a strong signal that the offline project (or the TIA Portal install) is the culprit, not the hardware. Engineers who swap the CPU first usually end up with two bricked PLCs and the same problem.
3. Use the full download path. The phrase Download to device > All in TIA Portal is not a marketing term; it is the specific menu entry that overwrites both the program blocks and the system data in the target. The "program blocks only" toggle exists for a reason (fast iteration on user code) and that reason is not HW configuration changes.

11. Frequently Asked Questions