Siemens S7 MMC Flash Program Transfer: Firmware Compatibility

1. Program Transfer Scenarios on SIMATIC S7 PLCs

MMC (Memory Micro Card) transfer is one of the fastest ways to deploy a STEP 7 or TIA Portal project to an S7-300, S7-400, S7-1200 or S7-1500 CPU. It avoids the Engineering Station (ES) download, removes the dependency on the project archive, and is the standard procedure when an identical spare CPU must take over a defective one with minimal downtime. Two field scenarios are critical:

1. Identical CPU order number and identical firmware version – usually a transparent swap. Diagnostic buffer stays clean and user program executes without modification.
2. Identical CPU order number but different firmware version – the swap physically works but the user program can execute differently. Symptoms include partial failure, modified timing behavior, and altered handling of asynchronous, motion control, or system-side instructions.

2. MMC vs. MCR / EPROM: Storage Architecture

The S7-300/400 generation stores the user program on the MMC (no longer EPROM or MCR modules after firmware 2.x on the 31x series). The SIMATIC S7-1200 and S7-1500 also load from an SD/MMC card. The relevant memory areas for a transfer are:

According to the SIMATIC S7-300 Automation System CPU 31xC and CPU 31x Operating Instructions, when the MMC is inserted and the CPU is powered, the load image is unpacked into work memory. The SDBs define the configured hardware topology. Any later online change to the hardware (inserting a module, modifying a slot) is written back to the MMC only if the project is downloaded or the user explicitly triggers a "Copy RAM to ROM" on S7-300, or "Download to device / Load to memory card" on TIA Portal.

3. Case A — Identical Hardware and Identical Firmware

This is the "transparent swap" path:

1. Source CPU and target CPU share the same order number (e.g. 6ES7318-3EL01-0AB0).
2. Source CPU and target CPU share the same firmware release (e.g. V2.8).
3. The MMC is inserted into the target CPU without modification.

Result: the CPU boots, the SDB topology matches the wired hardware, the user program executes unchanged. The diagnostic buffer will show the expected startup OB100 events. No additional verification is required beyond a process-side observation cycle of one full production sequence.

This is the scenario described by the field report: two S7-319-3 PN/DP V2.8 controllers on line A and line C. When the line C CPU failed, the line A CPU was moved to line C with its line C MMC inserted and the line ran with no algorithm change.

4. Case B — Identical Order Number, Different Firmware

The same physical CPU can ship with multiple firmware releases. For example, the 6ES7318-3EL01-0AB0 is documented as supporting firmware V2.x, V3.x and later. STEP 7 online mode will show the firmware mismatch in the "PLC → Module Information" view, and TIA Portal will display the project vs. online target version in the diagnostic toolbar.

Symptoms that appear after this kind of MMC transfer:

• OB1, OB35, OB82 all execute – no startup fault.
• Diagnostic buffer is empty or contains only informational entries.
• A subset of the user program behaves differently. The example from the source: 80 % of the line works, 20 % does not, and the failing area is not linked to a specific OB or FB number visible from the diagnostic buffer.

Three independent root causes contribute to this behaviour, and any combination of them can be present.

5. Root Cause 1 — Instruction Implementation Differences Across Firmware

Siemens releases firmware updates that change the implementation of high-level instructions while preserving the formal interface (the same FB / FC call signature, the same input/output pin names). The user program therefore still downloads successfully, but the internal timing, edge handling, or error reporting of the instruction can be different.

The field example: an S7-1511T fleet where eight machines ran on FW < 2.0 and four new machines shipped with FW > 2.0. The asynchronous instructions and the motion control instructions behaved differently. After recompilation and download the program still misbehaved; code optimisation was required to make it work on the newer firmware.

Mechanically, the migration impact is concentrated in:

6. Root Cause 2 — Data Block Initial Values

The single most common cause of a partial-failure scenario after an MMC transfer is the interaction between start values and actual values in data blocks. The behaviour differs by action:

This is the behaviour the field report explicitly observed: an uploaded program had start values in every data block, even though the engineering project did not specify those values. The CPU had rewritten the start values with the current actual values at the moment of upload.

Therefore: never use an "uploaded to PG" program as the starting point for an MMC transfer. The DBs in such a project carry the runtime state as their initial values, which will overwrite the freshly-installed CPU's state on its first start.

7. Root Cause 3 — Runtime-Created DBs and System Data Blocks

A second, less obvious cause is the runtime-generated DB family. Some FBs (and some Siemens library FBs, particularly on S7-1200/1500) instantiate DBs only on first call. The DB's actual content depends on the CPU's work memory state at the moment of instantiation. When the MMC is moved between two CPUs with different firmware, the ordering and the implicit initialisation of these DBs can be different.

Symptoms:

• Blocks compiled and loaded without error.
• A specific instance DB shows plausible-looking data but the values diverge from expectation.
• No SF / BF LED. The CPU is in RUN with no diagnostic buffer entry.

Detection: use Online & Diagnostics → Blocks to compare the online instance DB timestamp and content with a known-good reference. For TIA Portal projects the helper view is Project tree → PLC → Program blocks → System blocks → Resources, looking at SDBs with high "Generated by" version.

Field fix: delete the affected instance DBs in RUN (using the small "delete" button in the online view, only available if the FB allows it), then trigger a warm restart so the FBs recreate the DBs from firmware-correct defaults.

8. Root Cause 4 — Forced Variables and Retentive Memory

Forcing is a PG-driven feature that overrides a tag's actual value while the CPU is in RUN. Two important properties:

• Forced variables are not stored on the MMC. They live in the CPU work memory.
• Forced DB variables are not retained across a power cycle. After power off → power on, forced DB tags revert to the value determined by the DB start value / initialisation logic. Forced I/O points and forced bit memory (M) tags behave differently – the I/O peripheral force persists while the bit memory force is also cleared on stop→start transitions in many firmware versions.

Remediation:

1. Document every active force in the Force table and store it with the project archive.
2. After any MMC transfer, re-apply forces from the PG before re-enabling the line.
3. Verify with the customer engineering team that "no force" is the intended steady state. If a force is part of the operating procedure, it must be migrated to a controlled set/reset logic in the user program.

9. Diagnostic Procedure Before and After MMC Transfer

The procedure below is the field-proven pattern for a safe MMC transfer. It applies to both S7-300/400 (STEP 7 V5.x) and S7-1200/1500 (TIA Portal) environments.

9.1 Pre-transfer (on the source CPU)

1. Read the diagnostic buffer and export it as a CSV.
2. Open the Force table, export it, and record every forced tag.
3. In TIA Portal: Online → Back up → Online snapshot to save the actual state of the DBs.
4. In STEP 7 V5.x: use PLC → Upload Station to PG only as a fallback; this will overwrite DB start values with actual values and is therefore unsafe to re-deploy.
5. Document the firmware version of the source CPU via PLC → Module Information → Diagnostics (tab "General").
6. Document the MMC card type (capacity and Siemens order number). MMCs are not interchangeable across all CPUs – a 6ES7953-1xx00-0AA0 MMC may not be accepted by every CPU family.

9.2 Transfer and first boot

1. Power off the target CPU. Insert the MMC. Power on.
2. Wait until the CPU reaches RUN. Note the SF/BF LED state.
3. Connect the PG and read the diagnostic buffer. Expect OB100 entries referencing the new MMC as the source of the load image.
4. Compare the CPU's reported firmware against the project's configured firmware. A mismatch is an information, not an error – but it requires the verification in step 9.3.

9.3 Verification on every program path

1. Watch the OB35 (cyclic interrupt) execution time in Module Information → Time System. A spike in the OB35 runtime after a firmware change is a strong indicator of FW-sensitive instruction behaviour.
2. Cycle through every operating mode of the line: manual, semi-automatic, automatic, service, recipe changeover.
3. Compare each process variable against the reference line. Capture a 30-minute trend of every critical tag (flow, pressure, temperature, motor speed) using the Web server's "Watch tables" on S7-1500 or the WinCC tag logging on the HMI.
4. Document every deviation. A deviation is either an instruction-level implementation difference (Root Cause 1), a DB start value issue (Root Cause 2), or a runtime DB instance issue (Root Cause 3).

10. Safe Commissioning Procedure After an MMC Transfer

For production lines that cannot be stopped for a full re-commissioning, the following minimal procedure reduces the risk of a partial failure:

1. Build the engineering project for the source CPU from the PG archive (do not upload from the live CPU).
2. For the new CPU with newer firmware, open the project in TIA Portal, change the device version to match the target firmware, and recompile. Note every block where the compiler reports an interface change or a deprecated instruction.
3. For each reported block, review the runtime semantics. Update only the necessary blocks.
4. Download the corrected project to the CPU in STOP. Then perform a warm restart to RUN.
5. Verify the previous operator's manual override steps against the new build. Most partial failures reported in the field originate here: an override that worked because of the old DB initial value no longer works because the new DB initial value is different.

If the engineering project is unavailable, perform an upload as the absolute last resort and then immediately:

• Reset every DB's start values to the documented defaults.
• Compile the project (this re-applies the user-defined start values).
• Download with "Reset output".

11. Verification Checklist and Field Test Plan

12. Frequently Asked Questions