S7-300 CPU315-2DP Retentive Data Loss on Power Off/On

Problem Overview

The S7-300 CPU 315-2DP (Siemens order number 6ES7 315-2AH14-0AB0 / 6ES7 315-2AH14-0AB0) on firmware V3.3.7, equipped with a 512 KB Micro Memory Card (MMC, 6ES7 953-8LF00-0AA0) and programmed with TIA Portal STEP 7 V11 SP2 Update 5, can exhibit a rare but disruptive symptom: after a routine 24 V power-off / power-on cycle, the controller restarts successfully and the user program loads correctly, but every Data Block (DB) that should be retentive returns to its initial value – as if a cold restart had been executed. No diagnostic buffer entry is typically captured in time because the failure is non-reproducible by manual cycling.

The symptom is intermittent: most power cycles preserve all 24,564 bytes of declared retentive data, yet occasionally the controller boots with the entire DB set reset. Because STEP 7 reports a memory requirement of ~24 KB but the controller has 512 KB of MMC storage available, the problem is not capacity-related. It is a retention commit race condition between the bulk-capacitor hold-up window and the MMC write sequencer.

Upgrading the CPU firmware from V3.3.7 to V3.3.8 (the latest service pack for this MLFB at the time of writing) has been reported to suppress the symptom in field deployments, although the rarity of the event makes statistical confirmation difficult.

Affected Hardware and Firmware Identification

The CPU 315-2DP belongs to the SIMATIC S7-300 family. Unlike S7-400 controllers, the S7-300 family has no battery-backed SRAM; all retentive data must be committed to the MMC during the controlled power-down sequence. This is the foundation of the failure mode described here.

How the MMC Retentive Save Procedure Works

Siemens S7-300 CPUs implement the following retention commit sequence on 24 V supply loss:

1. The CPU's on-board voltage supervisor detects that the 24 V input has fallen below a hardware-defined threshold (typically ~19 V with hysteresis).
2. The supervisor asserts an internal POWER_GOOD_FAIL signal and triggers a non-maskable interrupt (NMI) routine.
3. The CPU firmware copies the configured retentive area (DB contents, marker bits, timers, counters) into an internal staging buffer.
4. The staging buffer is flushed to the MMC through the internal SPI/parallel MMC controller.
5. A bank of bulk capacitors (mounted on the CPU PCB) sustains the 5 V / 3.3 V logic rails during steps 2–4. The hold-up time is typically 50–80 ms, depending on the loaded I/O configuration and the amount of data to commit.

Per Siemens' functional description of S7-300/S7-400 CPUs, the S7-300 family supports only the "warm restart" startup mode after power return; there is no separate cold-restart class for production machines unless explicitly configured. A warm restart that ends up with all initial values is, by definition, an aborted commit of the retentive data set. The official documentation states: "S7-300 CPUs know only the 'warm restart' restart mode. To avoid loss of data in the retentive area …" – the operator is responsible for sizing the retentive area so that the commit can complete inside the capacitor hold-up window. See the official entry at Retentive behavior after loss of power (S7-300, S7-400).

MMC Write Constraints Specific to This CPU

• The MMC erase-before-write granularity is typically a 128 KB segment. Committing 24 KB of retentive data still requires the controller to read, modify, erase and rewrite a segment. Erase time alone is 100–300 ms on commodity NAND, but the CPU masks this latency by holding the bulk capacitor rail.
• If the bulk capacitor discharges below the brown-out reset threshold of the MMC controller before the write completes, the MMC contains a partially-flushed image and the CPU, on next boot, treats the retentive area as invalid – reverting to the initial values stored in the load object.
• Firmware V3.3.x added a CRC/checksum on the retentive image so that partial writes are detected and discarded instead of being silently accepted as corrupt data. This is why the symptom is "initial values" and not "garbage".

Root Cause Analysis

Three failure vectors can plausibly explain the symptom. Each must be ruled out by measurement before changing firmware.

Vector A — Insufficient Capacitor Hold-Up Time

The S7-300 internal capacitor bank was sized to commit the maximum retentive area specified for the firmware version. On early V3.x firmware, the commit routine was less optimized, and a fully-charged 24 KB set can approach the hold-up limit when:

• The bulk capacitor ESR has aged (typical design life 7–10 years at 40 °C ambient).
• The input voltage ramp-down is slower than the comparator design center, leaving less margin between detection and brown-out.
• The 24 V supply is a third-party PSU with a soft discharge curve that biases the bulk capacitors below the supervisor threshold before the comparator trips.

Vector B — Supply Spike / Inductive Kick at Power-Off

If the plant-side 24 V bus shares conductors with motors, solenoids or contactor coils, the inductive kick at de-energization can produce a negative-going spike that briefly exceeds the supervisor's tolerance band. The CPU may interpret the spike as a power failure (triggering the retention routine) and then recover before the write completes – effectively a "spurious commit" scenario.

Vector C — MMC Wear / Bad Block at Commit Address

SLC NAND used in MMC has a finite write endurance. After thousands of power cycles, the segment holding the retentive image can develop read-disturb or write-fail bits. The commit then fails its own CRC and the firmware safely rolls back to initial values. This is rare on Siemens 6ES7 953-xLFxx MMC, but it has been documented for third-party MMC clones.

Diagnostic Buffer Inspection Procedure

The S7-300 diagnostic buffer is the only on-board record of the commit attempt. Always retrieve it immediately after a symptomatic power cycle – the entries are timestamped by the CPU's hour-meter counter and may be overwritten during the next fault event.

1. Connect the programming device to the CPU via MPI/PROFIBUS or Ethernet (CP343).
2. In TIA Portal: Online & Diagnostics → Diagnostics Buffer.
3. In classic STEP 7: PLC → Diagnostics/Settings → Diagnostic Buffer.
4. Filter for events with OB-event class OB 81 (power error), OB 82, or firmware events of class SF with text containing "retentive", "MMC", "reset", or "memory reset".
5. Note the hour-meter count at the last successful commit versus the failed commit.

Power Supply Considerations

Using a third-party 24 V PSU on an S7-300 CPU is supported by Siemens provided the supply meets IEC 61131-2 criteria for industrial PLC power (ripple < 5 %, hold-up time > 20 ms at full load, inrush current limited). However, two specific behaviors of third-party supplies complicate retention:

1. Over-current foldback: When the 24 V bus is heavily loaded, a cheap PSU can collapse to ~10 V for 30–100 ms before recovering, instead of cleanly ramping down. The CPU supervisor sees this as an instantaneous brown-out and triggers retention – but the bulk capacitor is already partially discharged from the sag, so the commit window is short.
2. No power-good signal: A Siemens SITOP PSU outputs a relay contact or 24 V OK signal that can be wired into a digital input of the CPU to perform a controlled shutdown (writing retentive data on a planned stop). A third-party PSU typically lacks this signal, leaving the supervisor to react to a passive voltage drop.

Recommended PSU architecture for production machines:

• Dedicated 24 V branch for the CPU rack (PS 307 / SITOP smart / SITOP modular).
• Separate 24 V branch for digital inputs.
• Separate 24 V branch for digital outputs.
• Diode-OR between the CPU branch and a UPS-buffered branch (SITOP DC-UPS or buffering module 6EP1931-x…​) if the plant has frequent brown-outs.

Retentive Data Sizing

The retention routine must commit every byte flagged "RETAIN" inside every DB declared as retentive, plus all retentive bit memory (M), retentive timers (T) and retentive counters (C). The default STEP 7 configuration sets all DBs to retentive unless the programmer explicitly clears the "Non-Retain" checkbox in the DB properties. This default is the most common contributor to oversized retention areas.

How to Reduce the Retentive Area

1. Open each DB in the project tree.
2. Right-click → Properties → Attributes.
3. Uncheck "Non-Retain" for the entire DB only if the DB truly holds data that must survive a power cycle (recipe parameters, counters, calibration data).
4. For DBs that mix critical and volatile data, leave the DB retentive but set individual variables' "RETAIN" attribute to false in the variable table.
5. Re-compile the project and re-check the retentive bytes in PLC → Resources → System Resources or the TIA Portal equivalent PLC → Properties → Retentive Memory.

For this specific project (24,564 bytes), trimming non-essential retentive areas down to roughly 4–8 KB is realistic and well within the firmware's commit budget.

Firmware Upgrade Procedure

1. Download the FW V3.3.8 file from Siemens Industry Online Support (entry ID 6ES7 315-2AH14-0AB0 product page → Support → Downloads → Firmware). Verify the file's SHA-256 against the value published in the Siemens KB article.
2. Place the CPU in STOP mode via the mode selector or via online command.
3. Insert a SIMATIC MMC of at least 2 MB formatted in the CPU (or use the existing MMC if the project fits).
4. In TIA Portal: Online & Diagnostics → Firmware Update. Select the .upd file. Confirm.
5. Wait for the LED sequence STOP→blinking→STOP. Do not power off during this sequence.
6. Perform a memory reset (MRES) and reload the project.
7. Verify firmware version in Online & Diagnostics → Diagnostics → Module Information.

Configuration Best Practices for New Projects

1. Default to Non-Retain for every new DB. Opt-in to Retain only after consciously verifying that the data must persist.
2. Audit retention every code review. A simple rule "If you cannot justify the Retain flag, remove it" prevents retention bloat.
3. Avoid retentive bit memory (M) for non-recipe data. Use flags only for handshakes; do not put counters there.
4. Use separate parameter DBs. One DB per recipe or per machine configuration is easier to audit than a single "everything" DB.
5. Configure OB 81 (Power Error OB). Although it cannot prevent the commit failure, it records the brown-out event to the diagnostic buffer with millisecond resolution.
6. Use a SITOP buffering module (e.g., 6EP1931-2DC21 for 10 A / 200 ms hold-up) for installations with marginal supply quality.
7. Log the hour-meter counter alongside production counts so the diagnostic buffer can be correlated to the failure event.

Verification Procedure After Mitigation

After applying any of the fixes above, perform the following accelerated stress test:

1. Power on the CPU, let it reach RUN, and load production-equivalent data into the retentive DBs.
2. Record the retentive values into a reference file.
3. Cycle the 24 V supply 50 times with a 30-second off / 60-second on duty cycle. Use a controlled contactor or a SITOP buffering module bypass relay – do not rely on unplugging wires.
4. After each cycle, compare the retentive values to the reference. Any mismatch indicates a Vector A failure.
5. Inspect the diagnostic buffer for any 0x2521/0x2522/0x2523 events.
6. Repeat with a fast-discharge PSU (set bench supply to 24 V with 0.1 V ramp-down time) to test Vector B. The CPU must still preserve retentive data.

If 50 stress cycles preserve all retentive data and the diagnostic buffer is clean, the fix is validated.

When to Escalate (Hardware Fault)

Replace the CPU if any of the following are true after firmware upgrade and retention trim:

• Diagnostic buffer shows 0x2523 (MMC write error) but the MMC is a Siemens original of correct catalog number.
• Bulk capacitor voltage drops below 4.75 V (measured on the CPU PCB test points per the service manual) within 30 ms of 24 V removal.
• Diagnostic buffer records no entry at all on multiple symptomatic cycles – the supervisor itself is not firing.
• 24 KB retentive area has been trimmed to under 4 KB and the symptom still appears.

At that point, order a replacement CPU with the same MLFB and the same firmware (V3.3.8 or later) and migrate the MMC. Always transfer the original MMC to the new CPU so the retentive data and project load object are preserved.

Troubleshooting Matrix

FAQ