S7-1200 Remanent Memory Errors Causing CPU Stop and IP Reset

Problem Overview

Field reports on the S7-1200 family (CPU firmware V2.x through V4.x) describe a recurring anomaly in which a CPU that previously ran cleanly transitions to the STOP state shortly after a restart or power cycle. Concurrent with this transition, the configured IP address disappears and the controller reverts to a default address such as 192.168.1.101 or, in some legacy projects, the topology-discovery range 192.168.0.0/24. The visible symptom reported by commissioning teams is: (a) PG/PC loses connection to the CPU, (b) the Web server is no longer accessible at the project IP, (c) HMI tags report "Partner not found" or "No connection", and (d) the diagnostic buffer shows one or more entries related to remanence / load memory / work memory.

The phenomenon is closely tied to the way the S7-1200 allocates remanence areas in Data Blocks (DB) and to the way the IP address is sourced from the project file versus from a SIMATIC Memory Card. This article collects the underlying mechanisms, the diagnostic event identifiers you should look for, and a deterministic recovery procedure using TIA Portal and the memory card workflow described in the SIMATIC S7-1200 Programmable Controller System Manual.

S7-1200 Memory Architecture and Remanence

Every S7-1200 CPU separates non-volatile and volatile storage into three logical regions. Understanding which region is involved is essential for the recovery.

Remanence is not automatic. For DBs, you must open the DB properties in TIA Portal and explicitly enable "Snapshot of the actual values of the data block after the restart of the CPU" via Optimized block access > Snapshot or via the classic "Set/reset of retentivity" column when Standard access is used. For tags (M, I, Q), the remanent range is configured under PLC tags > Default tag table > Remanence. Tags that fall outside that configured range revert to their initial values on restart and are not part of the persistent snapshot.

Root Cause: Why the CPU Enters STOP and the IP Resets

The IP address of an S7-1200 is part of the project configuration stored in load memory. There are several IP source-of-truth paths:

1. Project only — The IP is in the online project's Device configuration; it lives in the load memory image. If the CPU falls back to a clean factory state, it may recover the IP from internal flash.
2. Memory card transfer — When the project was loaded to a SIMATIC Memory Card and the CPU booted from the card, the IP travels with the card; this is the path used in field reports (an OEM commissioned the followers with a card, then assigned IP 192.168.120.10x where x identifies the solar tracker).
3. DCP / PROFINET discovery — The IP can be reassigned from a DCP-capable controller or from TIA Portal's Accessible nodes dialog.

When a remanence fault occurs, the S7-1200's firmware reaches an internal state where it cannot guarantee that the snapshot stored in retain memory matches the structure defined in the project. Three mechanisms can trigger this:

In all three cases, the firmware's defensive action is to transition the CPU to STOP, log a diagnostic event, and require operator intervention. The IP address, which is part of the load memory image, may also be re-initialized to a default address because the operating system of the CPU has effectively dropped to a clean boot context. This is not a bug in the firmware — it is the documented behavior of the S7-1200 CPU Diagnostic Functions.

Diagnostic Events to Capture

Connect to the CPU with TIA Portal (Online > Go online > Accessible devices) and open Online & Diagnostics > Diagnostics buffer. Filter for the entries most relevant to remanence and STOP transitions:

Pre-conditions for Recovery

Before opening TIA Portal, gather the following so the recovery is a single contiguous operation. A half-finished recovery can leave the CPU in a less recoverable state.

• The most recent project file from engineering (TIA Portal version aligned with the CPU's actual project; mismatch yields additional retentive errors).
• A SIMATIC Memory Card of the same or larger size as the one originally used (SanDisk SDHC industrial-grade card recommended; consumer cards frequently cause 0x0152 / 338 faults).
• The PG/PC Ethernet adapter configured with an IP in the same subnet as the CPU's known IP (192.168.120.10x) and a fallback in the discovery subnets 192.168.0.x and 192.168.1.x.
• Physical access to the CPU's mode switch and to the SD slot.
• Knowledge of whether the CPU is on PROFINET or simple TCP/IP communication — if PROFINET devices will also need to be recommissioned.

Step-by-Step Recovery Procedure (Software Path)

Use this procedure when the CPU is reachable (still showing in TIA Portal's Accessible nodes) but is in STOP.

1. In TIA Portal, open the project that matches the on-card project revision. Do not modify the project until the CPU is back online at RUN.
2. Right-click the device » Online & Diagnostics » confirm the diagnostic buffer entries described above and export the buffer to CSV.
3. Navigate to Functions > Reset to factory settings. Acknowledge the warning. This erases the retentive area and the internal user program.
4. Once reset, the CPU will boot with the default fallback IP. On modern firmware it is 192.168.1.101; on older revisions and on devices that lost the project-on-card it can surface as a 192.168.0.0-class address reachable only via Accessible nodes » Show All Accessible Nodes.
5. From the TIA Portal project, compile the device (Compile > Software (rebuild all)) and Download to the CPU using the same IP that the CPU is currently exposing. TIA Portal will warn if the IPs differ; accept and proceed — the download reshapes the IP back into the project value.
6. Start the CPU (Online > Start CPU or flip the mode switch to RUN). Watch the diagnostic buffer for any new event; none should appear if the download was clean.
7. Verify the IP via Online & Diagnostics > Ethernet interface » IP addresses. The value should now match the project.

Step-by-Step Recovery Procedure (Memory Card Path)

Use this when the CPU is unreachable at its project IP, the memory card is the source of truth, or the card contents are needed to refresh a corrupted internal flash image — the scenario described in the original OEM commissioning workflow.

1. Power down the CPU. Remove the memory card.
2. In TIA Portal, open the originating project. Insert the card into a card reader. Use Project > Card Reader / USB Memory > Write to Memory Card. Select Transfer [Card → CPU] as the operation mode on the card's Properties so a power-on transfer is enforced.
3. Confirm that the card's project IP matches the device IP you intend to write (192.168.120.10x). For fleet deployments where the IP changes per unit, do the edit on the engineering workstation, not directly on a card pulled from a follower.
4. Insert the card into the CPU; power up. The CPU will transfer the project and IP from the card on first power-on. Watch the LED pattern: RDY and BF/FD flashing indicates transfer; a steady RDY indicates RUN.
5. If the card carries the wrong project or wrong remanence layout, the CPU will go back to STOP and post a new remanence event. In that case repeat from step 1 and use Reset to factory settings before re-inserting.
6. Confirm the IP at the operator panel or via HMI diagnostics. The IP is now 192.168.120.10x (matching the card's project) and not the original 192.168.1.101.

Verification Steps

The recovery is not complete until each line below is green.

Preventive Design Practices

• Pin retention explicitly. Use the TIA Portal DB editor's Retain column for every member you want persistent. Avoid enabling entire DBs globally; partial retention reduces checksum risk because small retain regions are easier to validate.
• Match DB revisions. Treat any DB change (Type, size, UDT instance configuration) as a code version increment that requires a Reset (warm restart) to clear the old retain snapshot before the next download. The Programming and Operating Manual confirms that the retain layout follows the project, not the runtime.
• Industrial-grade memory cards only. Siemens validates specific card part numbers; catalog references include 6ES7 954-8LF03-0AA0 (4 GB) and 6ES7 954-8GB03-0AA0 (12 GB). Cards outside the validated list are a known cause of 0x0152 events.
• Power quality. Protect retain write operations at restart with a UPS sized to ride through at least one full mains loss event; a hold-up below the CPU's minimum brown-out recovery window produces partial writes and subsequent CRC errors.
• Version control on the IP. If the IP is parameterized from the card and there are multiple followers (e.g., solar tracker x), generate the card image from a TIA Portal script rather than editing in isolation. Build the IP for follower x as 192.168.120.100 + x and verify before writing the card.
• Disable the retain properties between firmware updates. When upgrading from V4.2 to V4.6 or to a major V15.x line, temporarily disable retention, perform the load, then re-enable. This is documented in the S7-1200 System Manual firmware release notes.

Field-Proven Troubleshooting Matrix

Edge Cases and Lessons from Field Reports

Case — Solar follower fleet: the controller IP 192.168.120.10x depends on the unit's tracker number. If the commissioning technician downloads the project from a different station's card, the IP becomes that station's x, masking itself as an "IP reset" while in fact it is a mistaken IP. Always validate the IP shown on the HMI against the project IP after each card transfer.

Case — Optimization pass without reset: changing a DB from Standard to Optimized block access reorganizes the retain layout. After such a change, the CPU will refuse to start with the old snapshot. The fix is Reset (warm restart) with retain retention disabled, restart, then download the updated DB. The Programming Manual lists this case explicitly as an unsupported transition with retain enabled.

Case — Firmware mismatch: a CPU on V4.4 firmware running a project compiled in TIA Portal V17 will stop immediately with a firmware diagnostic event. Roll the engineering version back or update the CPU firmware first. See the firmware compatibility matrix in the S7-1200 System Manual.

FAQ