Siemens S7-300/400 CPU Memory Concept: RAM, FEPROM, MMC

Overview

The S7-300 and S7-400 CPU families use a three-tier memory model that separates the program and configuration images from the runtime data structures. Understanding the distinction between load memory (Ladespeicher), work memory (Arbeitsspeicher), and system memory (Systemspeicher) is essential when sizing projects, choosing storage media, and performing online programming on brownfield systems. This reference consolidates the field-proven behavior of MMC, RAM, and FEPROM modules, explains why an internal load memory layer is required even when an external card is present, and provides the practical limits and hot-swap rules that prevent corruption during commissioning.

Cross-platform guidelines are taken from the official SIMATIC S7-300 CPU 31xC and CPU 31x technical specifications and the SIMATIC S7-400 CPU data manuals. Always verify exact firmware-specific behavior against the manual bundle for the exact MLFB (order number) in front of you, because the load memory layout has changed significantly between the early 312/314/315 generation and the current 315-2 PN/DP, 317, and 319F families.

Memory Architecture Layers

Every S7-300/400 CPU separates persistent and volatile storage into three logical layers. Each layer has a fixed role in the boot sequence and during normal cyclic operation.

The load memory is the persistent image of the project as the engineer wrote it. The work memory holds a runtime copy that the CPU's instruction dispatcher can fetch without flash access penalties. The system memory is reserved for the cyclic I/O image and the bit-memory/timer/counter address areas that ladder logic manipulates each OB1 pass.

When the CPU powers up, the boot sequence copies the active project from load memory into work memory. If a battery is fitted and the load memory is RAM, the same battery also preserves retentive M, T, C, and DB data. If load memory is FEPROM or MMC, the project is non-volatile even with the battery removed.

Why an Internal Load Memory Layer Exists

The internal load memory is the CPU's native boot source. It is technically feasible to boot directly from an external card, but the internal layer provides three field-proven benefits:

1. Boot determinism. The CPU always has a known-good image available on its own backplane before the card is interrogated. Card-slot, contact, or file-system failures are detected and reported as diagnostics instead of preventing the CPU from going RUN.
2. Speed of RUN transition. Internal load memory is mapped into a fast local region, so the copy-into-work-memory step completes in sub-second time on the larger S7-400 CPUs. Direct card-to-work-memory paths require a flash driver in the critical path, which lengthens the start-up time after every power cycle.
3. Diagnostic granularity. The CPU can flag a card/load-memory mismatch as a specific diagnostic buffer entry (event ID 0x49E1 "Comparison of the online and offline data", 0x45E4 "STOP due to memory reset request", and similar). Without an internal copy, the diagnostic granularity is reduced to "card is bad" with no fallback.

On a CPU 417-4H, the internal load memory is typically 256 Kbyte. This is intentionally smaller than the supported external card; the internal area is sized to hold the boot header, the active SDBs, and the project signature that the CPU verifies at each restart. The bulk of OB/FB/FC/DB code is held on the external card and copied into work memory on demand.

S7-300 Memory Concept

The S7-300 family has two distinct memory generations, and selecting the wrong card for a generation is the most common commissioning error.

Legacy S7-300 CPUs (pre-PN/DP, MC generation)

Older S7-300 CPUs (for example CPU 312, 312C, 313, 313C, 314, 314C, 315, 315-2 DP) ship with internal load memory and accept one of two optional external cards:

• FLASH EPROM card (non-volatile) for permanent projects that change rarely.
• RAM card (volatile, requires battery on the CPU) for projects that are rewritten often, because RAM cards support many more write cycles than flash media.

On these legacy CPUs the internal load memory remains the active source; the card is treated as an overflow or as the editable copy when you perform an "Online > Download to memory card" transfer.

Current S7-300 CPUs (PN/DP and F-generation)

Newer S7-300 CPUs (for example 312C-2 PN/DP, 315-2 PN/DP, 317-2 PN/DP, 319F-3 PN/DP) have no internal load memory at all. The Siemens MMC is mandatory; the CPU refuses to enter RUN without a project on the MMC. The MMC is the only load memory and is also the boot source.

S7-400 Memory Concept

Every S7-400 CPU has internal load memory and a dedicated card slot that accepts either a RAM or a FEPROM module. Both module types use the same 64-bit keyed connector and pinout; the difference is electrical and storage technology, not physical form factor.

The reason Siemens sells both media even though FEPROM is clearly the safer default is throughput and write-cycle economics. FEPROM sectors wear out at high write counts; an engineer performing dozens of online changes per hour on a RAM card never wears the card, while the same workflow on FEPROM would age the card in weeks. For OEM-series machines shipped into the field, FEPROM is the correct choice. For test stands and engineering workstations, RAM is the correct choice.

External Load Memory as Backup vs. Extension

The external card is simultaneously a backup and an extension. Which role dominates depends on the CPU generation:

• Legacy S7-300: internal load memory is the primary; the card extends it. The card is an overflow, not a backup of the internal area.
• S7-400: internal load memory is the primary; the card extends it. Removing the card does not erase the project from the internal area, but a download larger than the internal capacity obviously requires the card.
• Current S7-300 with MMC: the MMC is the only load memory. It is not an extension; the CPU has no fallback image. Losing the MMC means losing the project.

The reason a S7-400 CPU like the 417-4H ships with only 256 Kbyte of internal load memory while the smallest accepted FEPROM module is 1 Mbyte is operational, not technical: the internal area is sized for the boot headers, active SDB set, and runtime signature; the bulk user program is expected to live on the card. There is no requirement that internal capacity equal or exceed external capacity; the internal area is not a cache for the external area, and the CPU does not move code segments between them at runtime.

Sizing and Capacity Planning

Use the following procedure to size load memory for a new project. These rules are derived from typical S7-300/400 capacity tables and STEP 7 v5.5 / TIA Portal project-size reporting.

1. Compile the project in STEP 7 / TIA Portal and read the online > module information > memory usage page. The tool reports consumed work memory, consumed load memory (after compile/optimize), and remaining capacity per memory area. This is the authoritative number for the active build.
2. Add 20% to 30% headroom for future edits and SDB growth. Adding a single FB with associated instance DB can consume 4 to 32 Kbyte of load memory depending on its interface footprint, and adding a new SDB for a configured slave can consume 1 to 8 Kbyte.
3. Compare against the largest available MMC / FEPROM module for the target CPU. Available sizes are typically 64 Kbyte, 128 Kbyte, 512 Kbyte, 1 Mbyte, 2 Mbyte, 4 Mbyte, 8 Mbyte, 16 Mbyte, and 32 Mbyte depending on the product line.
4. Confirm that the work memory of the target CPU is not the limiting factor. Many projects that fit easily in load memory blow past work memory because every DB has to be loaded into the working set at runtime. The work memory limit is usually the tighter constraint.

Online Download and COPY RAM to ROM

The semantics of an online download depend on the target media. The following table summarizes the behavior.

The most common field failure mode is the engineer who performs an online download to a FEPROM-equipped S7-400, walks away, and returns the next morning to find the previous program running. The download went to RAM and the unbuffered power cycle erased the change. Always execute Online > Copy RAM to ROM at the end of an FEPROM commissioning session.

Hot-Swap Rules and Diagnostic Buffer Entries

For both S7-300 and S7-400, and for all card types, Siemens' documentation is explicit: do not remove or insert a memory card while the system is powered. Even if a CPU is in STOP, removing the card under power can corrupt the card contents and can produce an unrecoverable diagnostic buffer on the next start-up. The only safe workflow is:

1. Power the system down completely (PS off).
2. Wait for the CPU's display, if fitted, to go blank and for any internal discharge time (typically 5 to 10 seconds).
3. Insert or remove the card.
4. Restore power and observe the diagnostic buffer for card-related events.

If the user must change a card with the system live, the only supported alternative is to put the CPU in STOP first and remove the card only when the rack is fully de-energized. The user is sometimes told that "STOP mode is enough" because the CPU itself has stopped executing, but the card interface is still active; the safe-state card-removal rule is "system powered off", not "CPU in STOP".

Relevant diagnostic buffer event IDs to watch for after a card operation:

Retention, Battery, and Retentive Behavior

Three retention rules apply to the S7-300/400 system and they are easy to confuse:

1. Project retention (load memory): FEPROM and MMC hold the project without a battery. RAM cards require a battery.
2. Retentive data (M, T, C, DBs marked retentive): always requires the CPU battery on the S7-400, and on the legacy S7-300 with battery slot. The MMC and FEPROM do not back this up; the internal SRAM is what is retained.
3. Work memory (the runtime copy of OBs, FBs, FCs, DBs): reloaded from load memory on every power-up. Work memory is not retained; only the project on the card is retained.

The most common engineer mistake is to remove a battery from a S7-400, perform a power cycle, and conclude that "the program is gone". In reality, the program is intact on the FEPROM; what was lost is the retentive M, T, C, and DB contents. The CPU restarts in RUN with a fresh process image.

Troubleshooting Matrix

Verification Procedure After Any Memory Operation

1. Online > Compare online/offline: confirm the project in the CPU matches the STEP 7 / TIA Portal project. This catches a forgotten COPY RAM to ROM on FEPROM.
2. Diagnostic buffer review: scan the last 20 entries for any 0x45E*, 0x49E*, or 0x4Axx event IDs. A clean buffer is the strongest single evidence that the boot image is consistent.
3. Module information > memory: verify used and free load memory, used and free work memory, and the retentive area mapping. The numbers should match the project compile output within a few percent.
4. Power cycle test: turn off the PS, wait 30 seconds, restore power. Verify that the CPU returns to RUN, that the project signature in the diagnostic buffer matches, and that the retentive tags hold their expected values.
5. Watchdog test: for F1 / F-CPU systems, verify that the safety program signature is intact and that the F-signature matches the documentation. A FEPROM swap on a F-CPU is a critical safety event and must be followed by F-signature verification.

FAQ