S7-400 Memory Card Selection: RAM vs Flash EPROM Technical Reference
Selecting the correct memory card (RAM or Flash EPROM) for a SIMATIC S7-400 CPU is a fundamental design decision that affects commissioning speed, runtime behavior, CPU STOP risk during online program changes, and synchronization time on S7-400H redundant systems. This reference consolidates the official Siemens memory-area specifications, the MLFB (order) numbers of currently shippable cards, and the field-proven rules for choosing between volatile RAM and non-volatile Flash EPROM storage on S7-300/400 CPUs.
1. S7-400 Memory Architecture Overview
The S7-400 CPU subdivides its memory into three regions defined by the IEC 61131-3 model and by the Siemens S7-300/S7-400 functional description (Siemens: What you should know about memory cards for S7-400):
- Load memory – non-volatile storage for the user program, configuration, and connection data. Implemented as integrated Flash plus an optional plug-in memory card.
- Work memory – volatile, battery-backed RAM used for runtime code and data. Always integrated on the CPU.
- System memory – counters, timers, bit memory, and process-image partitions.
The plug-in memory card only expands the load-memory region. It cannot be used to enlarge work memory or system memory. Both card types – RAM and Flash EPROM – therefore operate in the same logical address space (load memory only).
| Memory region | Volatile? | Battery required? | Expandable with card? |
|---|---|---|---|
| Load memory (card slot) | Depends on card type | Yes if RAM card, no if Flash | Yes |
| Work memory (integrated) | Yes | Yes (backup battery in CPU) | No |
| System memory (integrated) | Yes | Yes | No |
2. RAM Memory Card – Technical Specifications
A RAM card is a battery-backed static RAM module that sits in the memory-card slot of the S7-400 CPU. The CPU's backup battery (type 6ES7971-0BA00, 3.6 V lithium, AA-size) maintains the card contents indefinitely as long as the battery is healthy and installed. Pulling the card while the CPU is unpowered and the battery is depleted results in total loss of the load-memory image.
Key characteristics:
- Re-writable in microseconds, ideal for repeated download of small program changes.
- No write-cycle wear-out concern for typical engineering volumes.
- Retains content only while the CPU backup battery is intact, or while the card remains powered inside a running CPU.
- Typical use: commissioning, hot-iteration development, and S7-400H standby synchronization.
Common RAM card MLFBs (5 V, long design, for S7-400):
| Order Number (MLFB) | Capacity | Form factor |
|---|---|---|
| 6ES7952-1AH00-0AA0 | 64 KB | Long, 5 V |
| 6ES7952-1AK00-0AA0 | 256 KB | Long, 5 V |
| 6ES7952-1AL00-0AA0 | 1 MB | Long, 5 V |
| 6ES7952-1AM00-0AA0 | 2 MB | Long, 5 V |
| 6ES7952-1AP00-0AA0 | 4 MB | Long, 5 V |
| 6ES7952-1AS00-0AA0 | 8 MB | Long, 5 V |
| 6ES7952-1AY00-0AA0 | 16 MB | Long, 5 V |
3. Flash EPROM Memory Card – Technical Specifications
A Flash EPROM card is non-volatile NAND-flash silicon that the CPU can read and write directly without an external programming device. It retains the load-memory image indefinitely with no battery, and is the storage medium Siemens recommends for the production / final-commissioned state.
Key characteristics:
- Retains content without battery backup across decades (data retention typically 10 years per Siemens datasheet).
- Write endurance is finite (~100k cycles per sector in commercial-grade flash). Negligible for typical engineering use, but a constraint to keep in mind if automating bulk parameter saves.
- Block-erase programming model: erasing a sector costs milliseconds; writes to the same logical area can incur longer latencies than RAM.
- Hot-swappable for read on most CPUs; the CPU must be in STOP to swap a Flash card while the CPU is powered.
Common Flash EPROM card MLFBs (long design, 5 V, for S7-400):
| Order Number (MLFB) | Capacity | Form factor |
|---|---|---|
| 6ES7952-0KF00-0AA0 | 64 KB | Long, 5 V |
| 6ES7952-0KH00-0AA0 | 256 KB | Long, 5 V |
| 6ES7952-0KK00-0AA0 | 1 MB | Long, 5 V |
| 6ES7952-0KL00-0AA0 | 2 MB | Long, 5 V |
| 6ES7952-0KM00-0AA0 | 4 MB | Long, 5 V |
| 6ES7952-0KP00-0AA0 | 8 MB | Long, 5 V |
| 6ES7952-0KS00-0AA0 | 16 MB | Long, 5 V |
| 6ES7952-0KT00-0AA0 | 32 MB | Long, 5 V |
| 6ES7952-0KY00-0AA0 | 64 MB | Long, 5 V |
4. RAM vs Flash EPROM – Side-by-Side Comparison
| Attribute | RAM card | Flash EPROM card |
|---|---|---|
| Non-volatile without battery | No | Yes |
| Battery backup required | Yes (CPU backup battery) | No |
| Average write latency | Microseconds | Milliseconds (block erase + program) |
| Write endurance | Unlimited (effectively) | ~100,000 cycles per sector |
| Erasable externally with prommer | No | Yes (and via CPU download) |
| Risk of CPU STOP during online download | Low (typically stays in RUN) | Higher; depends on CPU and amount of changed data |
| S7-400H sync time impact | Minimal | Can extend link-up and resync time on Flash erase cycles |
| Recommended phase | Development / commissioning | Production / final state |
| Cost relative | Lower | Slightly higher |
| Field-typical use case | Iterative download during FAT/SAT | Frozen, signed, archived program |
5. Commissioning Workflow – RAM First, Flash for Release
The standard Siemens-recommended workflow used by experienced commissioning engineers follows a two-phase pattern:
- Phase 1 – Engineering and FAT/SAT: Insert a RAM card. Download the project repeatedly from STEP 7 (Classic) or TIA Portal without worrying about flash wear. Online edits remain in RUN on most CPUs (e.g., CPU 414, 416, 417) because the load memory on RAM can be patched in microseconds.
- Phase 2 – Site acceptance and release: Perform a final, complete download to a Flash EPROM card. From this point, every cold restart boots from non-volatile flash, the program is independent of the backup battery, and the load-memory image is identical to what was archived in the engineering repository.
After the Flash card is in place, future modifications still require either:
- An online edit (allowed within working memory without disturbing the Flash card) — small block changes only, or
- A new full download via STEP 7 / TIA Portal, which erases and re-programs the Flash card. This operation may force the CPU into STOP depending on the amount of logic changed.
6. CPU STOP Behavior During Program Download
A common field observation is that loading a project into a Flash EPROM card is more likely to drop the CPU into STOP than loading into a RAM card. The technical reason is the Flash block-erase time: while the CPU holds the bus to erase a Flash sector, OB1 execution cannot continue, and the watchdog can elapse on certain older firmware versions.
To minimize STOP risk on Flash:
- Place the CPU in STOP manually before the download when feasible (downloading to Flash while in RUN is supported but not always risk-free).
- Update the CPU firmware to the latest released version. Siemens shipped multiple firmware revisions (e.g., CPU 416-3 V8.x) that explicitly improved Flash download behavior.
- Avoid erasing the Flash card from a powered-up CPU and re-inserting it without a CPU restart — this can leave the card in an inconsistent state.
- For S7-400F / S7-400FH safety CPUs, observe the safety lifecycle: any program change requires a password, signature, and reacceptance.
7. S7-400H Redundant System Considerations
On an S7-400H (high-availability) system, two redundant CPUs run in parallel and synchronize their internal state over fiber-optic link modules. Memory card selection has a direct impact on hot-sync and cold-sync timing.
Field-proven guidance:
- Use RAM cards during commissioning and during any phase where the standby CPU may need to take over within milliseconds. RAM allows near-instantaneous link-up and event-driven resynchronization.
- Avoid Flash on a redundant CPU while the system is in RUN for routine online changes — the Flash erase latency inside the standby CPU can extend failover time beyond the configured tolerance and may trigger an SF (system fault) on the link.
- For long-term production storage of the H-system, Flash is still acceptable for the cold-restart image, but you should schedule the Flash programming during a planned maintenance window with both CPUs in STOP.
The H-system sync mechanism is independent of memory card technology — the redundancy is built into the work memory and CPU-to-CPU fiber link — but the time to reload a fresh image from the card into work memory does depend on whether the card is RAM or Flash.
8. S7-400F / S7-400FH Safety System Considerations
For safety-class CPUs (CPU 416F, CPU 417FH):
- Program changes require a safety password and a new acceptance test.
- Both RAM and Flash are supported; the safety signature is stored alongside the program and is verified at every restart.
- Always archive the safety signature and program together with the project revision.
9. Inserting, Removing, and Replacing Memory Cards
- Power off the CPU (or place in STOP for Flash on supported CPUs).
- Open the memory-card cover on the front of the CPU.
- Insert the card with the label facing outward, gold contacts down.
- Push until the ejector tab locks.
- Power on (RAM) or perform a memory reset (MRES) to bring the CPU to a defined state.
10. Diagnostics, Buffer, and SF LED Behavior
The CPU diagnostic buffer logs events related to memory card insertion, removal, checksum error, and battery state. Typical SF-LED triggers linked to memory cards:
| Diagnostic event | SF LED | Likely cause |
|---|---|---|
| "Memory card removed / inserted during RUN" | On briefly | Hot swap of card |
| "Checksum error in load memory" | On, CPU in STOP | RAM card lost battery, or Flash corrupted |
| "Battery low" | On (BAT LED also on) | Replace backup battery immediately |
| "Memory card incompatible" | On | Wrong voltage (3.3 V card in 5 V slot) or wrong firmware class |
11. Selection Decision Matrix
| Scenario | Recommended card | Rationale |
|---|---|---|
| Initial FAT / SAT with frequent program changes | RAM | Fast iteration, no wear, no STOP risk |
| Production release, archived program | Flash EPROM | Non-volatile, battery-independent |
| S7-400H commissioning | RAM | Fast link-up, no sync latency |
| S7-400H production with planned stop windows | Flash | Stable long-term image, accepted maintenance outage |
| S7-400F safety system | Either, with safety signature workflow | Safety lifecycle drives the choice, not the card type |
| Spare CPU in cabinet, cold standby | Flash with current revision | Zero-maintenance, ready to swap |
12. Verification Checklist After Card Installation
- CPU powers up to RUN without SF.
- Diagnostic buffer shows "Memory card recognized" event.
- Battery test passes (BAT LED off, diagnostic buffer reports OK).
- Project in STEP 7 / TIA Portal online view matches the offline archive (compare path: Online > Compare offline/online).
- For S7-400H: both CPUs reach redundant mode and link LEDs on the fiber modules are steady green.
- Memory card contents archived to the engineering repository (TIA Portal: Project > Card Reader / USB Memory Card > Read).
When should I use a RAM card vs Flash EPROM card on an S7-400?
Use a RAM card during commissioning and any phase with frequent online changes — the card holds its image on the CPU backup battery and accepts new downloads in microseconds. Switch to a Flash EPROM card for the production / released state so the load-memory image survives a depleted battery and matches the archived project revision exactly.
Why does my CPU go to STOP when I download to a Flash EPROM card?
Flash programming requires a block erase followed by a program cycle, both of which can take milliseconds. On older firmware revisions the watchdog can elapse during this window. Update the CPU firmware, place the CPU in STOP before the download, or temporarily move the project to a RAM card if you must stay in RUN.
Can I edit a program that is stored on a Flash EPROM card?
Yes. Online edits modify the work memory copy and the integrated Flash; the plug-in Flash card is only re-programmed on a full download. For larger changes you must re-flash the card, which typically forces a STOP.
Which card type should I use for S7-400H redundant systems?
Use RAM cards during commissioning and any period where fast standby takeover matters. Flash cards are acceptable for the long-term production image, but program the Flash during a planned maintenance window with both CPUs in STOP, because the Flash erase latency can extend link-up or resynchronization time.
What happens if the backup battery fails while a RAM card is installed?
Both the RAM card contents and the CPU work memory lose their images on the next power-down. On the next power-up the CPU reports a checksum error in the diagnostic buffer, the SF LED lights, and the CPU remains in STOP until a valid project is downloaded again. Replace the battery immediately when the BAT LED turns on to prevent this scenario.