CPU 315-2DP DB Data Loss After Shutdown: Memory Backup & Fixes

Problem Statement

After roughly 14 days of intentional shutdown on four production lines, each equipped with identical SIMATIC S7-300 CPU 315-2DP modules (MLFB 6ES7 315-2AG10-0AB0), data block (DB) contents reverted to their initial values at the next power-on. Symptom is identical on all four lines: on warm restart, the DBs were not retained, and OB100-style re-initialization occurred.

This article consolidates the engineering analysis of the failure, the S7-300 memory architecture that defines retentive behavior, and the configuration steps required to make DB actual values survive long shutdowns - both with and without battery backup.

CPU 315-2DP Hardware Identification

The article number printed on the CPU front module fully identifies its feature set:

Cross-check the firmware label printed on the CPU front before any upgrade decision: firmware V2.0 is in a non-upgradable state, while V2.6 onwards allows firmware updates.

S7-300 Memory Architecture Overview

The CPU 315-2DP uses a three-tier memory architecture. Understanding what lives in each tier is essential for any retentivity investigation:

The MMC always retains the program code and configuration because it is non-volatile flash. What it does not automatically contain are runtime-only actual values from the DBs: those values live in work memory and are only kept on shutdown when (a) a battery holds them, (b) a backup capacitor holds them, or (c) the user triggers an explicit save-to-MMC action before power-off.

Reference: Siemens KB 7302326 - Memory concept of SIMATIC S7-300 CPUs and C7 devices and the attached PDF Speicherkonzepte bei SIMATIC S7-300.

Why DB Actual Values Are Lost After Long Shutdown

The S7-300 CPU 315-2DP implements three retention mechanisms for RAM-resident data:

1. Battery backup - A removable lithium cell (3.6 V BA90) installed in the CPU front compartment keeps work memory alive indefinitely as long as the cell is healthy.
2. Capacitor backup - A supercapacitor on the CPU board buffers RAM during short power interruptions and after battery removal for cell replacement. Charge lasts days to weeks depending on revision, temperature and CPU duty cycle.
3. Explicit save to MMC - On firmware V2.6+ capable CPUs (and other supported S7-300 models), user code or an operator action can write the current DB and M actual values into the MMC, giving them a non-volatile home.

A 14-day shutdown exhausts capacitor backup. Once the capacitor charge drops below the threshold needed to maintain RAM cells, the CPU loses all volatile state. On the next power-on the CPU sees no valid retentive image and OB100 executes a full restart. DB actual values are then reloaded from the initial value field of the DB source (i.e., the values declared in the DB declaration), which is exactly the symptom reported.

Root Cause Matrix

Several independent faults can present the same symptom. Use the matrix below to drive the diagnostic interview before changing hardware.

HW Config: Configuring Retentive DBs and MBs

Retentivity on the S7-300 is global - it covers a consecutive range starting from the beginning of the DB or MB number space. Any DB or MB below the configured count is retentive; any above is volatile.

Procedure in STEP 7 V5.x

1. Open SIMATIC Manager and the project of the affected line.
2. Open HW Config and double-click the CPU 315-2DP slot.
3. Select the Retentive Memory tab.
4. Set Number of retentive DBs from the start of the DB number range (typical production setting: cover all DBs up to the highest used number).
5. Set Number of retentive MBs from the start of the MB number range (likewise cover all used MBs).
6. Click OK, then Save and Compile, and download the HW Config to the CPU.

Procedure in TIA Portal (V13 and later)

1. Project tree → expand PLC → Device Configuration.
2. In the Device View, select the CPU 315-2DP.
3. In the Properties pane, locate Retentive memory.
4. Set Number of retentive DBs and Number of retentive MBs accordingly.
5. Compile → download to device → select Download to target device.

Battery Backup - Installation and Replacement

Without the battery, only the integrated capacitor bridges outages. For multi-day shutdowns, a healthy battery is mandatory.

Required Battery

Replacement Procedure

1. Save actual values to MMC first via STEP 7 / TIA Portal (if available on this firmware). This way, even if the cell is completely flat, the database values are already on the MMC.
2. Power off the CPU.
3. Open the battery compartment; remove the old cell.
4. Install the new cell within the capacitor hold-up window (a few minutes - check the diagnostic buffer for 'loss of backup' before continuing).
5. Power on and confirm the diagnostic buffer no longer reports battery failure.

Save-to-MMC Function (Firmware V2.6 Capable)

On supported CPUs (firmware V2.6 in this MLFB family and beyond), the actual values of DBs and markers can be written explicitly into a non-volatile area of the MMC using a STEP 7 function or an operator-triggered action. This decouples data retention from capacitor / battery state.

Reference: Siemens KB 18778977 - How can you back up the actual values of DBs and markers?

Activation Paths

• STEP 7 / TIA Portal wizard: set the relevant CPU property for periodic or operator-initiated save.
• Operator panel: configure the function to a button on an HMI / OP and require operator confirmation before long shutdowns.
• Programmatic call: invoke via a system FB before the shutdown sequence when a controlled stop is executed.

Once values land on the MMC, they survive any duration of power-off without battery. Verify which operands are covered: typically the configured retentive DBs and MBs, with optional coverage of additional operands depending on firmware capability.

OB100 Restart Behavior Inspection

OB100 is the warm-restart block. Every CPU startup that cannot restore a valid retentive image routes through OB100. The user program inside OB100 has the responsibility of preparing the system - for example, opening PN/DP connections or initializing FB instance DBs.

Common Pitfall - OB100 Overwrites Retentive DBs

If OB100 contains explicit assignments to a DB's data area (e.g., DBxx.DBD0 := 0), then any retained values are unconditionally overwritten with the OB100 code. This is often the reason why 'retentivity was set in HW Config but the DB still resets'.

Pattern example for guarded initialization:

// OB100
IF "FirstCycleFlag" = FALSE THEN
  "FirstCycleFlag" := TRUE;
  // Initialize communication / FBs only
END_IF;
// Do not assign DB retentive data here.

Code review should look explicitly for assignment statements to DBs that must persist.

Event Buffer Diagnostics Procedure

The diagnostic buffer gives a timestamped history of every power-on, STOP, mode change and fault the CPU has seen. The entries around the outage event sequence are diagnostic gold.

1. Connect PG/PC to the CPU 315-2DP via MPI/PROFIBUS or Ethernet (via CP).
2. In STEP 7: PLC → Module Information → Diagnostic Buffer.
3. In TIA Portal: Online → Diagnostics → Diagnostic buffer.
4. Filter on the outage window and inspect: timestamp of last Power off, Power on, any STOP, any MRES, any Battery failure.
5. Correlate with the operator log / shift handover.

Every production line should show a clean transition 'Power off' → 'Power on (warm restart)'. A sequence that includes MRES means an operator performed a memory reset, which discards retentive data.

Firmware Considerations (V2.0 vs V2.6)

If the production fleet is on V2.0 and save-to-MMC is required, evaluate the cost/benefit of a firmware update versus installing batteries across all units.

Step-by-Step Restoration Plan

1. Audit all four lines: read diagnostic buffer; note battery install dates; verify firmware revision.
2. Replace batteries on every CPU 315-2DP with a fresh cell from the same lot.
3. Update HW Config with the correct retentive DB and MB counts; download to each CPU.
4. Code review OB100 - remove or guard any assignment to retentive data.
5. Trigger save-to-MMC after the production line is in steady state, before any planned shutdown.
6. Commissioning test: run for 1 hour → power off → power on; verify all retentive DBs and MBs. Extend to 24 h, 7 days, then 14 days.
7. Document the new SOP: 'operator must run save-to-MMC before extended shutdown'.

Verification Procedure

The retention guarantee must be proven empirically. Use the following reproducible test plan for each line after restoration:

1. Run the line to steady state. Capture current DB values via Monitor / Modify or HMI trend.
2. Trigger explicit save-to-MMC from STEP 7 / TIA Portal.
3. Power off the CPU.
4. Wait the test interval (1 h → 24 h → 7 days → 14 days).
5. Power on.
6. Compare actual DB values with the pre-shutdown snapshot.
7. For battery-only verification (no save-to-MMC), restart the test with a healthy battery and confirm capacitor-only path is not relied on beyond its design window.

Preventive Recommendations for Similar Fleet

• Adopt a battery replacement schedule across the S7-300 fleet (every 3-5 years), tracked against the CPU's event buffer battery test result.
• Maintain a retentive memory matrix per project that records: retentive DB count, retentive MB count, save-to-MMC flag, OB100 initialization footprint.
• Train operators that MRES is destructive to retentive data and must be authorized through the engineering function.
• Restrict the mode selector to RUN, or lock the cabinet. Mode selector drift to STOP-RUN during outage handling can re-trigger a warm restart without retentive validity.
• For any planned outage exceeding 48 h, trigger save-to-MMC as part of the shutdown checklist.

Edge Cases and Field-Proven Caveats

• Capacitor exhaustion profile: capacitor hold-up can degrade over the CPU's life. A CPU that retained data across a 10-day outage two years ago may fail to retain across a 5-day outage today.
• Temperature effect: capacitor charge loss accelerates at higher ambient temperatures. A cabinet in a hot plant may need batteries where the same model elsewhere can rely on the capacitor.
• Identical lines vs independent commissioning: four lines failing identically almost always points to a shared configuration choice or a shared battery fleet expiry. Treat this as fleet-level incident, not four independent incidents.
• Project change: any update to the CPU's retentive counters invalidates the existing retentive image on next restart. Coordinate any HW Config change with operations.
• OB1 writes through memory image: application code that runs in OB1 and writes to MB/DB areas (e.g., for handshake flags) will overwrite retention. The retention guarantee from HW Config only applies if user code respects the data area.

Related Standards and Documentation

The behavior is internal to the SIMATIC memory model; no third-party standard governs the retention time. The relevant Siemens technical user documentation for this family includes the S7-300 CPU 315-2DP manual and the memory concept FAQ linked throughout this article.

FAQ