Transferring MMC Between Password-Protected S7-300 CPUs

When an S7-300 CPU fails and the only surviving artifact is its Micro Memory Card (MMC), the field engineer faces three questions: does the project move with the card, does the CPU password travel with it, and are retain / persistent data still valid in the new CPU? This reference consolidates the documented behavior of the SIMATIC S7-300 family on MMC transfer, password protection levels, and module replacement, with explicit cross-reference to the S7-1500 password-transfer mechanism described in current TIA Portal documentation. The information applies to the standard S7-300 CPUs (CPU 312, 314, 315-2 DP, 315-2 PN/DP, 317-2 DP, 317-2 PN/DP, 319-3 PN/DP) operated under STEP 7 V5.x or, where supported, the TIA Portal.

1. S7-300 Memory Architecture: The MMC as Load Memory

Unlike the S7-200 and S7-400, the S7-300 has no integrated non-volatile load memory. The MMC is the sole load-memory device: without an inserted MMC, the CPU has no executable project, no system data, no hardware configuration, and no blocks. The internal RAM of the CPU 31x family provides only work memory (code and data) backed by a capacitor or battery (depending on the CPU variant) for retain behavior.

Because the password record is stored on the MMC as part of the system data, the card is therefore the authoritative source of the protection configuration. Removing the card removes the password record along with the rest of the load image.

2. Password Protection Levels in STEP 7

STEP 7 (SIMATIC Manager) supports three password protection levels for S7-300 CPUs, configured in HW Config → CPU Properties → Protection:

1. Level 1 — Access password (CPU-specific): restricts read/write access to the CPU via PG/PC. The standard dialog "Authorize" appears for both read and write operations depending on configured mode.
2. Level 2 — Write-protection: disables write access to the CPU from the PG; the password is required to remove the protection.
3. Level 3 — Read/Write protection (both): both read and write access require password entry.

For S7-300F / S7-300F fail-safe CPUs, an additional F-password is required to operate the safety program. The F-password is bound to the F-CPU's serial number and is stored in the F-runtime group authorization, not on the MMC in plain form. The discussion thread that prompted this reference explicitly excluded the F-CPU case, and that distinction matters: the F-password behavior on MMC swap is more restrictive than for a standard CPU and is covered in section 7.

3. MMC Transfer to an Identical CPU — Documented Behavior

Inserting the MMC from a password-protected CPU into a new, identical S7-300 CPU produces the following sequence of events on the destination CPU:

1. Power-on with MMC inserted: the destination CPU performs a memory reset automatically because its internal work memory is uninitialized relative to the load image on the MMC.
2. Project load: HW Config, all blocks (OB, FB, FC, DB, SFB, SFC, SDB), and system data are copied from the MMC into the work memory.
3. Password record load: the CPU reads the protection configuration block (SDB) from the MMC and applies the same protection level on the destination CPU. The new CPU is now password-protected with the original password.
4. Retain initialization: retain variables are initialized from the retain area. If the new CPU has no battery / uncharged capacitor, retain values are lost; if it does, the retain image from the MMC (where applicable, see section 5) is restored.
5. Run-up to RUN: if the operating mode selector is on RUN or RUN-P, the CPU attempts to enter RUN after the OB100 / startup OB completes successfully.

The two operational questions are therefore answered as follows:

• Will the hardware configuration transfer? Yes. HW Config is part of the load image on the MMC and is fully transferred to the destination CPU.
• Will the destination CPU be password protected automatically? Yes. The protection level is a property of the loaded SDB, not of the source CPU, so it is replicated on the destination.

4. How the Password Travels With the MMC

Siemens does not store the CPU password in clear text on the MMC. It is hashed and stored inside the system data block that contains the protection configuration. On the S7-300 platform, this SDB is part of the load image and is re-applied to whichever CPU consumes the card. The S7-1500 family uses a refined variant of the same principle: the CPU "converts this input using a special algorithm" and stores the result, which the documentation explicitly frames in the context of password transfer upon module replacement. The S7-300 does not provide a public per-CPU key pair for module replacement the way S7-1500 does with its CPU-bound signature, but the net effect for identical-CPU replacement is functionally identical: the MMC-installed CPU is bound to the card's password record for the duration that the card remains inserted.

5. Mirroring the MMC with a Prommer

A field-grade prommer (e.g., SIMATIC Field PG, or any third-party Flash programmer that supports the MMC's 5 V / 3.3 V supply) can read the raw image of the MMC and write it to a second, identical MMC. The result is a bit-identical copy of:

• Project (blocks, HW Config, SDBs)
• Password record (SDB with hashed protection configuration)
• Recipe / additional data blocks placed in load memory

The mirrored MMC behaves exactly as the original when inserted into a compatible CPU: project loads, password protection applies, and the destination CPU is fully functional without ever entering the password at the PG. The original password is not required at any point during the mirror operation or during the subsequent CPU bring-up. This is the principal field-proven method for cold-spare backup of S7-300 stations.

6. Retain Variables and Data Persistence on MMC Transfer

Retain behavior in S7-300 is divided into two distinct mechanisms, and the distinction is critical when moving the MMC:

1. NVRAM-backed retain (selected CPUs only): the CPU has dedicated non-volatile RAM areas; retain data is stored in the CPU itself, not on the MMC. A new CPU with an uncharged backup capacitor or no battery will lose this data even if the MMC is identical.
2. MMC-backed "retain via load memory": the CPU does not have NVRAM; on every STOP-to-RUN transition the retain data is written to the MMC as part of the project image. Inserting the original MMC into a new CPU restores retain values to the most recent STOP-to-RUN snapshot.

CPUs that use NVRAM retain include the higher-end 31x variants; lower-tier CPUs (e.g., CPU 312 IFM, CPU 313) often rely on MMC-backed persistence. Always verify which mechanism applies to the specific CPU order number (MLFB) before assuming retain data is preserved across an MMC swap.

7. F-CPU (S7-300F) Considerations

The discussion in the source thread specifically called out a problematic case: an F-CPU with MMC that could no longer be accessed because the F-password was lost. Key facts for S7-300F:

• The F-password is bound to the F-CPU's serial number; it does not transfer with the MMC alone, because the new CPU has a different serial number.
• Inserting the original MMC into a different F-CPU will load the project, but the F-runtime authorization will fail and the F-CPU will not enter safety-relevant RUN.
• The only sanctioned recovery path is to delete the MMC, re-insert it into the new F-CPU, and re-transfer the safety project from a STEP 7 source that contains the F-password.

This is the reason the original poster's question explicitly excluded F-CPUs — the answer for an F-CPU is "no, MMC transfer is not a valid replacement path."

8. S7-300 vs S7-1500 Password Transfer — Behavioral Comparison

Although the documentation link in the additional research describes the S7-1500 mechanism, the parallel is useful because the engineering question ("does the password move with the card?") is asked on both platforms.

9. Step-by-Step: Backup and Replace Procedure for a Standard S7-300 CPU

The following procedure is the field-recommended sequence for cold-spare backup of a password-protected S7-300 station using a mirrored MMC.

9.1 Prerequisites

• Replacement CPU with identical MLFB and identical or newer firmware (older firmware is not supported).
• Blank MMC of equal or larger capacity (3.3 V SIMATIC MMC, e.g., 6ES7953-8LF20-0AA0 for 4 MB).
• Prommer capable of reading/writing S7-300 MMCs, or a SIMATIC Field PG with MMC adapter.
• STEP 7 V5.x installed on a PG for verification.
• ESD-safe handling for the MMC.

9.2 Backup procedure

1. Bring the source CPU to STOP; place the mode selector in STOP to ensure the work memory is quiescent and the retain image is fully written to MMC (if MMC-backed).
2. Power down the source CPU.
3. Remove the MMC; label it with station, CPU MLFB, project version, and date.
4. Insert the MMC into the prommer. Read the full image to a file. Compute and record a SHA-256 or MD5 hash of the image file for integrity verification.
5. Write the image to the blank MMC. Verify by reading the destination MMC back and comparing the hash to the original.
6. Store the original MMC in a labeled ESD bag. Store the mirrored MMC in a second labeled ESD bag as the operational spare.

9.3 Replacement procedure

1. Power down the destination rack. Replace the failed CPU with the identical-MLFB spare CPU.
2. Insert the mirrored MMC into the spare CPU.
3. Power on. The CPU performs an automatic memory reset, loads the project from the MMC, applies the password record, and (if the operating mode selector is on RUN or RUN-P) attempts to enter RUN.
4. Verify on the PG using Accessible Nodes in STEP 7 that the CPU is online and the protection level is active. The original password is required to read or write the project from the PG.

10. Verification Checklist

11. Troubleshooting Matrix

12. Frequently Asked Questions