S7-1515F Error While Saving: STOP Mode Troubleshooting

Problem Overview

An S7-1515F (fail-safe CPU of the SIMATIC S7-1500 family) that reports "error while saving", drops into STOP, loses the time-of-day clock, and loses recipe data on a roughly two-hour cycle is exhibiting a classic persist-data fault. The periodicity is the single most important diagnostic clue: it is almost always the configured automatic retain-data save interval that is firing the failing write operation, not a random hardware glitch.

The S7-1500/F CPUs persist retain and global DB data by writing to the SIMATIC Memory Card (SMC) at operator-defined intervals and on every power-fail / stop-to-run transition. The write itself is a sequenced operation involving the file system on the SMC, the work memory, and (for F-CPUs) the F-monitoring time budget. Any single failure in that chain can either corrupt the retain image, the F-signature, or both, and the configured error response (OB priority, OB121/OB122 handling, F-runtime group behavior) determines whether the CPU recovers or escalates to STOP.

Because the symptom is identical for several very different root causes, the only reliable path to a permanent fix is to read the CPU's diagnostic buffer, classify the event ID, and then act on the specific fault class.

Symptoms and Failure Mode

Typical field observations on the affected S7-1515F system:

• CPU transitions from RUN to STOP on a cycle of approximately 2 hours.
• Recipe DBs that were created with the RecipeManagement library (or hand-rolled recipe DBs marked as retain) are wiped on each restart.
• The CPU's time-of-day clock is reset to a default value (often 01.01.2012 or 01.01.2000) on each restart, even when a battery or buffering capacitor is installed.
• An HMI alarm "Error while saving" or "Retain data inconsistent" appears on the screen a few seconds before the STOP.
• After the operator performs a manual Download to device from TIA Portal, the cycle re-starts and the next failure occurs two hours later.

The interval itself is the smoking gun. The default S7-1500 Save retain data automatically interval is rarely the source value of two hours — it is a number the programmer typed into the CPU properties. Verify the value under CPU Properties > System & Clock Memory > Save retain data automatically in TIA Portal. If two hours appears there, the failing write you are observing is that scheduled save attempting to flush retain data to the SMC and being rejected by the card.

Diagnostic Buffer Analysis (the First Action)

Open the project in TIA Portal (the same version or higher than the one used to program the S7-1515F), go online with the CPU, and navigate to Online & Diagnostics > Diagnostics > Diagnostic buffer. Export the buffer to a text file using the Save As button at the bottom of the dialog — this produces the same log the user can email for remote analysis.

For S7-1500/F CPUs, the relevant event ID classes are summarized in the table below. Match the event ID that appears in the buffer to the indicated action.

The full event-ID catalogue is published by Siemens in the SIMATIC S7-1500 / ET 200MP system manual and the online help of TIA Portal. For F-CPUs the S7-1500F / ET 200MPF fail-safe system manual adds the F- and W-event ranges.

For the 2-hour cyclic symptom, the pattern of events you will typically see in chronological order is:

1. 0x13A2 Backup of retain data to SIMATIC Memory Card failed
2. 0x13B0 Retain data not consistent – new power-up with default data (this is the fault the OS reports when the SMC write fails and the work-memory retain image is dropped)
3. 0x13E0 Time-of-day changed / clock lost
4. 0x35xx STOP transition reason (e.g. 0x3542 STOP by diagnostic interrupt from SFC/SFB)

This four-event sequence is the fingerprint of an SMC that cannot accept a save. The CPU's reaction (warning only, OB with a specific error response, or hard STOP) depends on the OB configuration in TIA Portal.

SIMATIC Memory Card (SMC) Verification

The SMC is the single most common root cause of the cyclic save failure on S7-1500. Treat the card as a consumable: S7-1500 internal flash wear-leveling is robust, but a card that has seen many thousands of power-fail writes, that has been written to with a third-party tool, or that has been formatted as FAT32 outside the S7-1500 ecosystem, will eventually fail mid-write.

Valid card types are restricted to Siemens catalog numbers. The current generation is the S7-1500 SMC family:

Confirm the following, in order:

1. Catalog number matches the card recommended for the firmware on the S7-1515F. Old 6ES7954-8LExx-0AA0 generation cards are not supported by firmware V2.9 and later on every variant — check the S7-1500 release notes for firmware compatibility in the manual collection.
2. Write-protect slider is in the unlocked position. The slider position is reflected in event 0x13C2 if the CPU has detected it.
3. File system on the card is intact. Open the card in a card reader and inspect via TIA Portal Project > Card Reader/USB. A long listing of orphaned LOGFILE directories, fragmented SIMATIC.S7S, or unexpected non-project files is a strong indicator the card was tampered with.
4. Free space > 30 % of the card capacity. A nearly-full card can accept the program download but fail the periodic retain write because the OS needs free blocks for atomic save.
5. Card age. S7-1500 cards have a rated endurance in the 100 000 write/erase cycles class. A card in a 24/7 process line that is more than 4 years old is a candidate for preventive replacement.

If the card passes visual and catalog inspection but the 0x13A2 event reappears, replace the card with a known-good SMC of the same catalog number and re-test. The 2-hour interval makes the test a no-cost verification.

Retain Data and Recipe Configuration

Recipe data in an S7-1500/F program lives in one of two places:

• Recipe DB in work memory, with the Set (retain) attribute on the instance DB or the global DB.
• Recipe file on the SMC, written by the Siemens RecipeManagement library or by the HMI/SCADA recipe system (e.g. WinCC, TIA Portal HMI recipes).

For the retain-DB case, the periodic save described in the previous sections is the only persistence mechanism. If the save fails, the next power-up reads default values from the offline project. For the HMI-side recipe case, the HMI writes the recipe to the SMC via the S7-1500 file system; a failing SMC breaks the HMI recipe storage but typically does not crash the PLC.

In TIA Portal, inspect and adjust the following CPU properties (right-click the CPU in the project tree > Properties):

1. System & Clock Memory > Save retain data automatically: confirm whether the box is checked and at what interval. The interval is in seconds. If the value is 7200, the cycle is literally two hours.
2. Protection & Security > Access level: a password-protected level can prevent a remote write that would otherwise update the retain image silently.
3. System diagnostics > Report system errors: enable this so the CPU raises a diagnostic interrupt on retain or SMC faults that the HMI can display.
4. For the RecipeManagement library: the recipe DBs must be marked as retain, and the RecipeManagement function block's SaveMode must be set to persistent rather than volatile.

Time Synchronization Issues

The time is lost symptom is closely related to the retain fault. The S7-1500 time-of-day clock is held by a hardware RTC backed by a buffer capacitor (no battery on the SMC-only variants; a replaceable CR2032 backup on the CPU itself for some types). On an uncontrolled restart caused by the STOP transition, the RTC may briefly drop to a default and resync to NTP.

Verify, in order:

1. CPU Properties > Time of day > Time synchronization: the mode should be set to NTP with at least two NTP servers, or to SIMATIC / Slave clock on PN for a master.
2. The NTP servers are reachable on PROFINET — the S7-1500 NTP client uses UDP/123.
3. The CPU's diagnostic buffer shows Time synchronized via NTP events; absence of these means the client never syncs and the clock drifts.

If the time loss is secondary to a save fault, fixing the SMC restore path will also restore the clock within one NTP poll interval. If the time loss is independent, check the backup battery of the CPU (the S7-1515F uses a replaceable lithium battery type 6ES7971-0BA00).

F-CPU Safety Runtime Considerations

On the 1515F, the F-runtime group executes inside a configured OB (typically OB35). The F-monitoring time is the maximum allowed time for the F-runtime group to complete; if the F-program exceeds it, the F-CPU passivates the group and, depending on the configured error response, can transition to STOP. A failing SMC write that is happening inside the F-runtime group window can consume a large slice of the configured time budget and tip the F-program into a violation.

Action items specific to the F-CPU:

1. Open CPU Properties > F-Parameters > F-Monitoring time. The default is typically 100 ms. If the user program does heavy retain-DB operations or recipe I/O in the same OB priority as the F-runtime group, raise the monitoring time proportionally and confirm the safety case.
2. Open Safety Administration > F-Runtime group in the project tree and verify the assigned OB. Move non-safety recipe code to a lower-priority OB (OB1 cycle tail or a dedicated OB).
3. After fixing the save fault, the F-runtime group requires acknowledge and reintegrate via the safety viewer in TIA Portal Online & Diagnostics > Safety (operator action on the HMI, with password).
4. Verify the F-signature is current: Safety Administration > Change log > Print/Accept. A failed retain save can sometimes leave the F-signature in a state that requires a re-acceptance. The S7-1500F system manual provides the procedure for re-accepting without an additional TÜV visit when the change is a parameter-only modification; for code changes, the full acceptance workflow applies.

PROFINET Ring and Network Stability

PROFINET is not directly involved in retain data, but a repeating PROFINET ring fault can cause the CPU to lose I/O data and trip an F-stop on the F-runtime group. With the S7-1500R redundant CPU, ring breakages spaced more than 1500 ms apart cause the redundancy role to change and the save to be aborted. Even on a non-redundant S7-1515F, ring flaps can steal scan time from the OB that owns the F-runtime group.

For the S7-1515-2 PN (6ES7515-2AN03-0AB0) and the 1515F variant, check:

1. Online & Diagnostics > PROFINET interface > Statistics: look for late telegrams, discarded telegrams, and Port 1 / Port 2 link state changes. A pattern of two link drops per two hours lines up with the save interval and indicates a noisy ring.
2. For S7-1500R/H systems: Diagnostics > R/H system shows the redundancy role and the standby CPU status.
3. Verify the MRP role (manager/client) of each switch and that the ring is closed. A single point of failure in a ring where the manager cannot be reached by the clients produces a cascade of port errors.

The detailed ring break timing and the resulting redundancy state changes are described in the S7-1500 / ET 200MP manual collection and the PROFINET commissioning manual.

Firmware, TIA Portal, and Library Compatibility

Save-related regressions have appeared in older firmware builds and have been fixed in subsequent releases. The current firmware for the S7-1515F (for example 6ES7515-2FM02-0AB0) is at firmware V2.9.x; each release note documents known issues with the SMC save path and the recipe DB. Before declaring a hardware root cause, check the firmware version of the affected CPU in the diagnostic buffer header and compare it with the latest version listed in the Siemens support entry for the 6ES7515-2FM02-0AB0.

Compatibility constraints to validate:

• The TIA Portal project version that the customer is using must be ≥ the firmware's compatible TIA Portal version. A project opened in a newer TIA Portal and re-downloaded to an older firmware can fail at save time because of a feature flag mismatch.
• The RecipeManagement library version must match the TIA Portal version. Mixing a V17 library with a V18 project, or vice versa, is a common source of cryptic OB121 errors that the OS reports as a save fault.
• The GSD files of any PROFINET device that is in the project tree must be at the version listed in the manual for the firmware; an outdated GSD can push the F-runtime group into a different priority than expected.

Save Mechanism Configuration in TIA Portal

The two-hour save interval can be adjusted in CPU properties. The relevant fields are:

For the cyclic failure, the highest-leverage change is to set the periodic save interval to a more conservative value (e.g. 6 hours) and rely on the power-fail save for emergencies. This keeps the retain data fresh and reduces wear on the SMC. If the SMC is replaced, the original 2-hour value can be restored once stability is confirmed.

Step-by-Step Recovery Procedure

1. Capture the diagnostic buffer from the affected CPU using TIA Portal Online & Diagnostics > Diagnostic buffer > Save As. Note the event IDs, the order, and the firmware version displayed in the header.
2. Classify the event pattern. If the sequence ends in 0x13A2 → 0x13B0 → 0x13E0 → 0x35xx, the root cause is a save-to-SMC failure. If the sequence ends in 0x10A1, the root cause is an F-monitoring time violation, possibly exacerbated by the save.
3. Stop the controller, place the plant in a safe state, and lock out the F-CPU per the safety plan.
4. Power down the S7-1515F. Remove the SMC.
5. Inspect the SMC: catalog number, write-protect slider, visual damage, free space (if a card reader is available, check the file system from TIA Portal Card Reader/USB).
6. Replace the SMC with a new card of the same catalog number, or re-format the existing card via TIA Portal Card Reader/USB > Format. Do not format with the host OS.
7. Re-transfer the project to the new card: either (a) download the project from TIA Portal to the new card via the card reader and insert it into the CPU, or (b) insert the new card into the CPU, download from the online project, and re-initialize retain. For F-CPUs the second method requires a safety acceptance log entry.
8. Power up the CPU and verify the diagnostic buffer shows a clean start with no 0x13A2 event.
9. Trigger a manual retain save by writing a recipe value from the HMI and confirm in the buffer that 0x13A2 does not appear. Alternatively, set the periodic save to a short interval (e.g. 60 s) for a 10-minute burn-in test, then return it to the original value.
10. Acknowledge and reintegrate the F-runtime group from the HMI or TIA Portal Safety viewer. Re-accept the F-signature if any F-parameters were changed.
11. Return the plant to operation and monitor the diagnostic buffer for 24 hours.

Verification, Prevention, and Field Best Practices

Use the checklist below during commissioning of any S7-1515F system that is configured to write retain data periodically.

1. Card class. Order the SMC from Siemens as a controlled spare. Do not source replacements from third-party resellers.
2. Card rotation. Replace preventive SMCs every 4 years in 24/7 applications, every 6 years otherwise.
3. Card lock. Confirm the card latch is locked and that the card cannot be pulled during RUN without breaking the lock. Event 0x13C1 must not appear.
4. Save interval. Configure the periodic save for 6 to 12 hours. The power-fail save is the primary protection mechanism; the periodic save is the secondary mechanism and should be set to a low wear value.
5. Diagnostic reporting. Enable Report system errors to an HMI and to SYSLOG. A 0x13A2 event should be loud — an alarm, not a console line.
6. Remote buffer access. Provide a VPN or maintenance port for the engineering team to pull the diagnostic buffer text file remotely. The 2-hour cycle in this case was lost to first-line analysis because the engineer was off-site.
7. Battery health. Verify the CPU's lithium backup battery (6ES7971-0BA00) is in the green zone of the diagnostic buffer's battery status. A weak battery can produce a 0x13B0 with a healthy SMC.
8. Firmware hygiene. Subscribe to Siemens Product Support notifications for the S7-1515F catalog number. Apply firmware updates only after testing in a non-production bench setup.
9. Time sync. Configure at least two NTP servers and verify the synchronization event appears in the buffer on each cycle.

Troubleshooting Matrix

FAQ