S7-300 Program Retention After Long Power-Off: Battery vs MMC

Overview: S7-300 Retentive Memory Architecture

The Siemens SIMATIC S7-300 family spans two distinct retentive storage generations that determine whether the user program, configuration data, and remanent process values survive an extended loss of supply voltage. Identifying which generation your CPU belongs to is the first step in any power-off risk assessment, because the failure modes, replacement procedures, and recovery paths differ fundamentally between the two architectures.

Per the official SIMATIC S7-300 functional description, all S7-300 CPUs implement only the warm restart (Anlauf) startup mode following power return. Unlike S7-400, the S7-300 has no cold restart or hot restart mode; on power recovery, the CPU executes OB100, restores process image I/O, and reinitializes non-retentive memory. Whether the user program and remanent data are still intact at that moment depends entirely on the backing technology physically present on the CPU module.

The two technologies are:

• Battery-backed RAM + optional EPROM/FEPROM memory card — legacy S7-300 CPUs (most 312, 313, 314, 315, 315-2 DP, 316, 318 families through the late 1990s/early 2000s production runs).
• Micro Memory Card (MMC) only — no battery, no RAM for program storage — the modern S7-300 generation (CPU 31xC, 31x PN/DP, 319-3 PN/DP, plus many later 312/314 variants).

Conflating the two is the most common reason field engineers mis-diagnose program loss. A 3-month power cut on a battery-backed unit with a healthy cell should be invisible. The same 3 months on an MMC unit is also invisible. A 2-year cut, however, falls outside typical S7-300 lithium backup cell service life and is the point at which the two architectures diverge in field behavior.

Identifying Your CPU: Battery-Backed vs. MMC-Based Variants

The decisive document is the CPU’s MLFB (Machine-Readable Product Designation), printed on the front panel and on the module label. The structure follows the Siemens catalog convention 6ES7 3xx-yyyzz-0AB0 with significant digits that encode the firmware and feature set. Physical inspection is faster than reading the order code: a battery-backed CPU has a circular battery compartment on the lower left of the front cover and a horizontal slot for a 5 V FEPROM/EPROM card behind a flip-up door; an MMC CPU has only a vertical MMC slot and no battery holder.

Battery-Backed CPUs: Backup Duration and Long-Term Power-Off

Battery-backed S7-300 CPUs use a 3.6 V primary lithium cell to sustain the static RAM that holds the loaded user program, the system data, and the remanent area of bit memories, timers, counters, and instance-DB values. The relevant Siemens order number for the standard backup battery module is 6ES7 971-0BA00 (single cell, 3.6 V, ~2.3 Ah), which is documented in the S7-300 module data manual.

Field and Siemens-published service life ratings fall in the following bands, which the planner must verify against the actual production run of the installed cell:

Implication for the 3-month question: a battery-backed CPU with a healthy cell will retain its program and remanent data through a 90-day outage with margin. The BATF LED will, however, light at the next power-up if the cell was already near end-of-life before the outage.

Implication for the 2-year question: 2 years (730 days) of purely battery-backed retention substantially exceeds the de-energized service life of a single 3.6 V cell. By the time the rack is re-energized, the cell is exhausted, the static RAM contents are invalid, and the CPU will report RAM error at startup. If a FEPROM card was fitted and the program had been transferred to it, the CPU will boot from the FEPROM and only the most recent RAM-only changes (e.g., online block edits not back-flashed) are lost.

MMC-Based CPUs: Modern Non-Volatile Program Storage

From the early 2000s onward, Siemens replaced battery-backed RAM with the SIMATIC Micro Memory Card on the S7-300 platform. The MMC is a flash-based removable card that contains the user program, system data, and (since firmware V2.x on most 31xC models) the retentive DB content that the CPU would otherwise have maintained in battery-backed SRAM. No battery is present or required for program retention.

Relevant properties:

• Form factor: The MMC is a sub-MMC card that inserts into a vertical slot behind the front flap. Sizes 64 KB, 128 KB, 256 KB, 512 KB, 1 MB, 2 MB, 4 MB, and 8 MB are catalog items; ensure the size matches the project footprint.
• Write cycles: MMC wear is dominated by online block edits, recipe writes, and DataLog use, not by program load. Retentive DB values are mirrored to the MMC, so flash wear is non-zero even in steady state.
• Removal behavior: The MMC must remain inserted while the CPU is running. Hot-removal is not supported and will trigger an storage card not inserted diagnostic and an SF LED.

For an MMC-based CPU, the 2-year power-off scenario is harmless from a program-retention perspective: the program, configuration, and most persistent data are preserved on the MMC. The CPU performs a warm restart on power return and reinitializes the process image from the I/O.

Power-Off Scenarios: 3 Months vs. 2 Years

Working through the two scenarios raised in the field report against the architectures above:

Diagnostic Indicators: SF LED and BATF LED Behavior

When the rack is re-energized after a long outage, the front-panel LEDs and the diagnostic buffer in STEP 7 (Online > Accessible Nodes > Module Information > Diagnostic Buffer) provide the ground truth on what the CPU found in memory.

• SF (System Fault): On after a failed memory check. Typical entries: “RAM comparison error,” “Memory card not inserted,” “FEPROM error,” “MMC error,” “User program not valid.” Resolve by reloading the project.
• BATF (Battery Fault): On if the battery is missing, exhausted, or below the low-voltage threshold. Replace the cell and acknowledge via STEP 7 (PLC > Clear/Reset) or power cycle.
• STOP with red SF and flashing BATF: Classic signature of a battery-backed CPU whose RAM was lost. The CPU halts because the loaded project is invalid.
• STOP with SF only, MMC indicator flashing: Classic signature of an MMC CPU that cannot read or has lost the card. Reseat the card; if the error persists, format the card and reload.

The diagnostic buffer entries that should be reviewed in order are: power-down event, power-up event, OB100 start, any “Memory reset” or “RAM error” entries, and the time stamps that establish the actual outage length.

Verifying Retentive Memory Configuration in STEP 7

Before declaring the recovery complete, verify that the retentive area declared in the project matches what the CPU actually preserved. In STEP 7 V5.x:

1. Open the hardware configuration (HW Config) and select the CPU.
2. Open Object Properties > Retentive Memory (in German installations, Remanenz).
3. Confirm the number of retentive bit memories (M), timers (T), and counters (C) and the list of retentive data blocks (DB).
4. Compare to the actual values observed online (Monitor/Modify > Variable Table). Any divergence indicates a configuration mismatch that can be remediated by re-downloading the project with corrected retentive settings.

For OB100-related warm-restart behavior, review the CPU properties for the active startup type. The S7-300 only supports manual warm restart, automatic warm restart, and warm restart with preset configuration per the official functional description. Selection of an unsupported mode in the project will cause the CPU to STOP at power-up with a configuration diagnostic event.

Program Recovery Procedure from Backup Sources

The recovery path is dictated by what source artifacts exist in your documentation:

1. STEP 7 project archive (.s7p or .zip) on the engineering station or file server: Open in STEP 7, perform a full download (PLC > Download to Target > Complete). This writes the program, system data, and configuration to RAM and, on MMC CPUs, to the MMC.
2. FEPROM card in a known-good slot: Insert the FEPROM, power up. Older S7-300 CPUs will offer an automatic FEPROM → RAM copy on first power-up if the RAM area is empty. Use STEP 7 to verify block consistency.
3. MMC card from a sister machine or pre-commissioning backup: Insert, power up. The CPU runs the project on the MMC directly. Remanent DB contents are those of the donor card; DB values specific to the unit must be re-initialized via OB100 logic or a one-time commissioning routine.
4. No backup, no FEPROM, no MMC: Recreate the project from the as-built documentation. This is the worst case and the strongest argument for adopting a backup policy that mirrors the program to a FEPROM/MMC on every accepted change.

After any reload, force the PI/M (Program Identification / Module) comparison in STEP 7 (Online > Compare Online/Offline) to confirm that the loaded blocks match the project source exactly.

Battery Replacement Procedure

For battery-backed CPUs, the cell replacement must be performed with the supply voltage applied to the CPU so that the RAM contents are not lost. The procedure:

1. Confirm the cell is the correct type. The standard S7-300 backup cell is a 3.6 V lithium-thionyl chloride primary cell in the Siemens housing, MLFB 6ES7 971-0BA00. Substitution with off-brand cells is possible only if voltage, capacity, and connector polarity match exactly.
2. Open the front cover of the CPU. Locate the battery compartment on the lower left.
3. Remove the depleted cell by pulling the connector; do not pry the cell body.
4. Insert the new cell within the connector’s rated mating time (typically < 5 seconds) with the supply voltage still present, to avoid dropping RAM.
5. Close the compartment and verify the BATF LED clears. The diagnostic buffer will record “Battery test successful.”

If the battery is found depleted and the rack has been de-energized, the cell replacement must be combined with a project reload per the recovery procedure above. There is no way to reconstruct lost RAM contents.

MMC Card Replacement and Program Reload

For MMC-based CPUs, a failed or missing MMC is treated as a no-program condition. The procedure:

1. Open the front flap and eject the MMC by pressing the ejector.
2. Insert a same-size (or larger, up to the CPU maximum) blank MMC. STEP 7 will format it on first download.
3. Connect a PG/PC to the CPU’s MPI/DP or PN interface and establish an online connection.
4. Perform PLC > Download to Target > Complete with the CPU in STOP. The download writes the program and configuration to the MMC.
5. Switch the CPU to RUN; verify OB100 executes and the SF LED clears.

Note that on CPU 319-3 PN/DP, the MMC size is limited by the part number; consult the module data sheet before procuring a replacement card.

Field-Proven Commissioning Checklist

Use the following compact checklist to bring an S7-300 CPU back online after a long power-off:

1. Visually inspect the rack: LEDs off, no thermal damage, no bulging battery cell, no corrosion on the MMC slot pins.
2. Record the CPU MLFB and confirm whether it is battery-backed or MMC-based.
3. For battery-backed CPUs: measure the existing cell voltage under load if possible (<3.0 V indicates replacement). Replace if date code is >5 years old.
4. Power up the rack and observe the LED sequence. Document SF and BATF status in the maintenance log.
5. Read the diagnostic buffer and verify OB100 start, time stamps, and any memory errors.
6. Establish an online connection from STEP 7 and compare online/offline blocks.
7. Verify retentive M/T/C/DB values against last-known-good values; acknowledge any deliberate resets.
8. Test I/O at the terminals, not just in the process image, to confirm field wiring has not been disturbed during the outage.
9. For MMC CPUs, archive a copy of the live project to the engineering server as a baseline.

FAQ