Resolving S5-155U CPU 948 EPROM Load Failures and Stop LED Faults

When a SIMATIC S5-155U CPU 948 (6ES5 948-3UA11 / 6ES5 948-3UB11 / 6ES5 948-3UC11) refuses to load a user program from a Flash EPROM submodule, the symptom is almost always the same: the green RUN LED stays dark, the red STOP LED flashes at approximately 1 Hz, and the CPU never advances to RUN even after a clean overall reset. This article is a field-proven troubleshooting matrix for that exact failure mode, built around the 6ES5 374-1FH21 Flash EPROM, the S5-155U backplane architecture, and the CPU 948 block-handling rules documented in the S5-155U CPU 948 Programming Guide (6ES5 998-3PR21).

1. Hardware and Firmware Identification

Before chasing the EPROM, log the exact catalog numbers. The CPU 948 is a 32-bit RISC-based processor module occupying one slot in the SIMATIC S5-155U central rack (CR or ER). Variants matter because the Flash EPROM interface and the system program base differ between them.

The Flash EPROM submodule is plugged into the dedicated socket on the front-edge of the CPU module, behind a small sliding cover. Siemens published a compatibility list of all approved Flash EPROMs at Entry ID 4202137. Approved submodules for the CPU 948 are listed in the table below; using an unlisted module is the single most common cause of a non-loading EPROM.

2. Decoding the Stop LED Behavior

The CPU 948 uses its STOP LED to communicate the boot state. Three distinct cadences are emitted, and each maps to a different fault class. Reading the cadence correctly is the first diagnostic step.

The "fast flash" condition in the third row is the symptom in the source case. It is the CPU 948's signal that it has detected a Flash EPROM in its socket whose contents have not yet been transferred to internal RAM. The CPU is not "stuck" — it is explicitly waiting for the operator to acknowledge the new memory image by performing an overall reset.

3. Why the EPROM May Not Load — Root Cause Matrix

The source case is a classic example of a successful EPROM burn followed by an unsuccessful EPROM-to-RAM transfer. Seven root causes account for the vast majority of field failures, ranked by frequency.

4. STEP 5 EPROM Header and Image Layout

The Flash EPROM image is not a raw concatenation of compiled STL blocks. The 948 firmware expects a structured image with a fixed header followed by block entries. Writing a raw block dump is the most common source mistake in the field, including the failure mode reported in the field report.

4.1 Image structure

Offset       Length   Field
0x0000       2 bytes  Magic word — must be 0x5A5A
0x0002       2 bytes  Block count (little-endian)
0x0004       2 bytes  Reserved (0x0000)
0x0006       2 bytes  Block table offset (typically 0x0020)
0x0008       24 bytes Reserved (project ID + timestamp, filled by STEP 5)
0x0020       8 bytes  Block entry #0:
                          2 bytes block type (0x01=OB, 0x02=PB, 0x03=SB,
                                            0x04=FB, 0x05=FX, 0x06=DB)
                          1 byte  block number (0-255)
                          1 byte  block length / 256 (high byte of length)
                          2 bytes block length in words (low 16 bits)
                          2 bytes checksum (CRC-16 of block body)
0x0028       8 bytes  Block entry #1
...
0xNNNN       ...      Block bodies, packed contiguously

STEP 5 generates the entire image transparently when you use File > EPROM > Write from a complete offline project. If you used a third-party EPROM programmer with a raw binary file (e.g. a S5-DOS file, *.S5D), the image almost certainly lacks the header and the CPU will refuse to load it.

4.2 What the 948 actually loads

On overall reset, the CPU 948 reads the EP header, iterates the block table, copies each block into the corresponding RAM partition, recomputes the RAM CRC, and only then transitions to RUN. If any block in the table fails the CRC, the CPU aborts the transfer and reverts to the fast-flashing STOP LED state without copying any further blocks. This is why writing the blocks "in a different order" does not matter, but a single bad block aborts the entire transfer.

5. System Function Blocks (SFB) and FX Handling

The source question — "Isn't it because the program contains system function blocks?" — is a sharp observation. The CPU 948 does use a class of system function blocks, called FX blocks (Funktionsbausteine fester Adressierung, "fixed-address function blocks"), which are different from regular user FBs.

5.1 Why FX blocks are the trap

FX blocks are loaded by the CPU 948 firmware at boot and are the only way to call standard Siemens runtime libraries such as PID, floating-point math, and the S5 communication primitives. They live in the EPROM image. When the EPROM is missing the FX set, or contains an FX set from a different firmware version, the CPU 948's STOP LED will fast-flash indefinitely — exactly the symptom in the source case.

The supported procedure is:

1. Confirm the firmware version of your CPU 948 (read from the front label or via PG > PLC > Information).
2. On the original (working) CPU — or from the project backup — use STEP 5 to File > EPROM > Directory and read the FX list.
3. Compare the FX list against the list in the offline project. Each FX has a checksum that STEP 5 displays.
4. If any FX is missing or checksum-mismatched, the EPROM image is incomplete. Re-burn the EPROM using the offline project that contains the correct FX set.

5.2 DB handling — the second trap

The field report includes a key observation: writing all blocks including DBs into the EPROM, and then trying to skip the DBs in a second attempt, caused a new PLC error. The reason is that data blocks are not required in the EPROM image on a cold start. The CPU 948 initializes the data area from the initial values compiled into the FBs, and then lets the running program overwrite them. Writing a populated DB into the EPROM is harmless; not writing one is also harmless, as long as the FB initial-value segments are present. But if you delete the DB entry from the EP header (as the source engineer tried), the table offsets become invalid, the CRC chain fails, and the CPU stays in fast-flash STOP. The fix is always to let STEP 5 generate the EP image with the same DB entries the project declares — do not hand-edit.

6. The Correct EPROM-Burn Workflow

Use this sequence for any S5-155U CPU 948 EPROM service job. The sequence is derived from section 3.5.2 of the 6ES5 998-3PR21 programming guide.

6.1 Prerequisites

• PG 7xx, PG 720, PG 740, or PG 760 with STEP 5 >= V7.23 installed.
• Approved Flash EPROM submodule from the table in Section 1.
• Complete, working offline project, with FX set matching the target CPU's firmware.
• PG-to-CPU online connection (COM1 serial or MPI adapter).
• Buffer battery verified above 3.0 V on the CPU.

6.2 Step-by-step burn

1. Connect PG online. From STEP 5, PLC > Display > Information. Confirm the online CPU is the same firmware and MLFB as the target.
2. Upload to PG. PLC > Upload to PG. This produces a complete offline image including all FBs, DBs, and the runtime FX references.
3. Verify offline integrity. File > EPROM > Directory. The block count must match the project block count exactly. Any mismatch indicates a corrupt upload.
4. Insert EPROM. Power down the CPU. Open the front cover. Insert the Flash EPROM with the keyed notch in the socket. Power on.
5. Write EPROM. File > EPROM > Write. STEP 5 erases, programs, and verifies the Flash. The progress bar must reach 100% with no "verify error" line.
6. Power down the CPU. The 948 cannot hot-swap the EPROM safely.
7. Reinsert EPROM if removed for programming, or leave in place. Power the CPU back on.
8. Watch the STOP LED. The fast flash is expected on the first power-up with a fresh EPROM. Do not stop the CPU yet.
9. Perform overall reset (MRES). See Section 7 for the exact selector sequence.
10. Watch the transition. After MRES, the CPU should pulse STOP for 1-2 seconds, then transition to RUN. If RUN lights steady green, the EPROM is good and the system is live.

7. The MRES (Overall Reset) Sequence

The mode selector on the front of the CPU 948 has four positions: RUN, RUN-P, STOP, and MRES. MRES is spring-loaded and only active while held. This is the exact sequence that the 948 expects:

1. Place the selector in STOP. Wait until the STOP LED is steady (not flashing).
2. Hold the selector in MRES for at least 3 seconds. The STOP LED goes off briefly, then returns.
3. Release to STOP within 1 second. The STOP LED begins to flash briefly.
4. Re-hold MRES for at least 3 more seconds. The STOP LED goes off, then on steady.
5. Release to STOP. The CPU is now reset; RAM is cleared.
6. Toggle the selector to RUN (or RUN-P). The CPU begins loading from EPROM. The STOP LED should be on briefly, then RUN should light steady within 5 seconds.

8. Verification Steps After the EPROM is Loaded

After RUN lights steady, perform these verification steps before declaring the job done.

1. Block list parity. From the PG, PLC > Information > Block List. Compare against the project block list. All OB/PB/SB/FB must match. DBs may differ in contents (because they are RAM-resident at runtime) but must exist with the correct lengths.
2. FX integrity. File > EPROM > Directory. The FX list must show every FX the project references, and the CRC of each must be non-zero.
3. Buffer battery monitor. PLC > Information > System Data. The BATT field must read "OK".
4. Scan-time check. PLC > Information > Cycle Time. Compare against the project's documented scan time. A 2x or larger deviation indicates the CPU is interpreting block boundaries differently than the project intended.
5. I/O handshake. From the PG force one input and one output briefly to confirm the bus is responding.
6. Loss-of-power test. Power down for 30 seconds. Power back up. The CPU should boot from EPROM and reach RUN without any PG intervention. If it does, the EPROM is fully functional. If it does not, the EPROM has bit-rot or the buffer battery is dragging the RAM contents during power-down.

9. Common Pitfalls and Their Signals

10. Field-Validated Diagnostic Flowchart

The following decision tree is the shortest path from "fast-flash STOP" to a working system.

11. Edge Cases and Special Conditions

11.1 Cold start vs. warm start

The CPU 948 distinguishes between cold start (OB 20) and warm start (OB 21). On overall reset followed by RUN, the 948 performs a cold start: it copies the EPROM image to RAM, executes OB 20, and then enters cyclic mode. If OB 20 is not in the EPROM image, the CPU immediately enters STOP. A working PG upload will always include OB 20 implicitly via the system preheader, but a hand-edited EPROM image may strip it.

11.2 Multiprocessor rack

In an S5-155U multiprocessor configuration, only one CPU is the boot master. The EPROM is read only by the boot master. The other CPUs receive their program via the coordinated multiprocessor interface. If the wrong CPU's EPROM socket is populated, the boot master will fast-flash STOP with a slightly different cadence — typically a four-flash burst indicating "no coordinator program".

11.3 Memory expansion modules

If the target CPU 948 is the -3UC11 variant with the 6ES5 941 memory expansion module, the EPROM is still loaded into the CPU's internal RAM partition, not into the expansion. The expansion module only affects the runtime workspace, not the boot image.

11.4 Firmware updates

When the CPU 948 firmware is updated, the FX set version changes. Any pre-existing EPROM must be re-burned with the new FX set or the CPU will fast-flash STOP. Siemens publishes FX sets with every firmware release as a STEP 5 library file (typically S5FX948xx.ST).

12. Safety and Field-Engineering Notes

• Always power down the CPU before removing or inserting the EPROM submodule. Hot-swap can corrupt the Flash and damage the socket.
• Static-discharge precautions apply; use a wrist strap. The 948's socket is not field-replaceable.
• Maintain a backup of every EPROM image you burn. A Flash EPROM rated for 100,000 write cycles is field-proven but the socket itself wears with frequent swaps.
• Always have a RAM-only fallback program loaded and verified before the EPROM job. The source case demonstrates the value of this: the program was verified working in RAM while the EPROM was being debugged, and the plant stayed running.
• Document the FX set version, the firmware version, and the EPROM MLFB in the project's maintenance log. This eliminates 90% of the diagnostic time on the next service visit.

13. Summary — Six-Step Recovery

1. Confirm the EPROM MLFB is in the approved list (Section 1).
2. Verify the program runs from RAM without EPROM.
3. Compare FX list on EPROM against the offline project.
4. Re-burn the EPROM using File > EPROM > Write from a clean offline project, do not edit the image manually.
5. Insert EPROM, power on, perform the two-step MRES sequence (Section 7).
6. Run the verification checklist (Section 8), including the loss-of-power test.

FAQ