S5-135U CPU928B STOP LED Blinking: Memory, I-STACK, and Recovery

1. Problem Definition

A SIMATIC S5-135U chassis with a CPU928B has been removed from service for an extended period (months) and is now being recommissioned. The fault chain observed by field engineers is consistent across several reported cases:

1. CPU928B is switched to RUN.
2. The RUN LED does not light; the STOP LED begins to blink in a steady pattern (1 Hz, then 0.5 Hz depending on the failure class).
3. When the original program is reloaded, STEP5 / IBH S5-S7 reports "insufficient memory" even though the program previously fit the controller.
4. A "compress memory" operation is performed multiple times to free space; the program appears to load, but the CPU will still not transition to RUN.
5. In some stations, the Profibus BF (Bus Fault) LED is lit and one Profibus slave is not exchanging I/O.

Each of these symptoms has an independent root cause. Treating them as a single failure leads to lost commissioning time and, in some cases, corruption of the project archive.

2. CPU928B Hardware Identification

The CPU928B (Siemens order number 6ES5 928-3UB11 family) is the top-of-range processor for the SIMATIC S5-135U and S5-155U systems. It supports:

• 32-bit internal architecture with bit, byte, word, and double-word operations.
• 32 K 16-bit words of user memory as the base configuration (the figure cited in the source). Memory can be expanded by inserting 6ES5 355-3UAxx / 6ES5 355-3UBxx memory submodules (RAM or EPROM) in the front memory subslot.
• Integrated Profibus-DP master capability (CP5430/CP5431 compatible front port on later modules).
• Full STEP5 instruction set plus the supplementary 928A/928B instruction extension (data-handling blocks, integrated PID).

3. Memory Size Mismatch (37.5 K Code into 32 K RAM)

The source reports a 37.5 K program that previously fit a 32 K memory. The most common explanation is not that the program has grown — it is that the archive contains runtime-generated DBs that the CPU rebuilds automatically on every restart.

3.1 Which DBs are regenerated at startup?

The CPU928B executes the following organization blocks during restart, and each of them can write to data blocks:

If a backup of the PLC is taken with a serial protocol (e.g. AG 115U dump, IBH S5 online copy, or HMI archive pull), it captures the DBs at the moment of read, including any DB that OB20, OB21 or OB22 has just populated with calculated values. When that file is written back to a freshly erased CPU, the regenerated DBs from the new OB execution are overwritten by the static archive copy and the program state diverges from what the original logic was designed to handle.

3.2 Procedure to strip regenerated DBs

1. Connect the programming device and read the I-STACK (see §4) before any modification. The block list and the cause-of-stop entries are referenced later.
2. In STEP5, open the program file. For each DB flagged as "auto-generated" in the original project documentation, set the transfer attribute to not transferred or remove the DB from the download list.
3. Cross-check the DB numbers used by the FB calls against the numbers initialized in OB20/OB21. Any DB that is created or initialized in a startup OB must not be in the download list.
4. Reduce the on-line program to: OB1, OB20, OB21, OB22, OB30-OB38, OB100 (if present), all PBs, FBs, FX, FY, SBs, DX0, DX2, EPROM-resident DBs only.
5. Recalculate the size. Each stripped DB typically frees 256-2048 words, which is more than enough to close the 5.5 K gap observed in the source.

3.3 Is "Compress Memory" a valid workaround?

The Compress memory (German: Speicher komprimieren) function packs all occupied words at the low address end of the RAM. It is a legitimate housekeeping operation and may be run several times, but it does not change the physical capacity of the RAM. If the program text plus all retained DBs exceed 32 K words, compression cannot create new space — the only cure is to remove auto-generated DBs from the transfer list, as above, or to fit a larger memory submodule.

4. I-STACK (Interrupt Stack) Diagnosis

When the CPU928B enters STOP it does not erase its diagnostic context — it pushes the content of all internal registers, the block stack (B-STACK) and the interrupt stack (I-STACK) into a fixed RAM area. Reading this area is the single most important diagnostic step and is referenced directly in the CPU928B Programming Guide.

Procedure:

1. In STEP5, menu PLC > Display I-STACK (German: AG > ISTACK anzeigen). The AG requires an online connection to the CPU. With IBH S5/S7 the equivalent is Online > Diagnostic > I-STACK.
2. Read and record the following fields:

4.1 Common stop causes for the 32 K / STOP-blink case

The full decoding table is in chapter Interrupt and Error Diagnosis of the CPU928B Programming Guide (pa928ben.pdf). The same chapter defines the memory map used in the next section.

5. Startup OB Configuration Cross-Check

A recommissioned CPU928B will refuse to enter RUN if the configured restart mode in DX0 disagrees with the available OBs. A field-ready check list:

1. Open DX0 in STEP5. Confirm that the restart mode bits are set to either cold restart (OB20 selected) or warm restart with memory reset.
2. Verify that OB20 (and OB21, OB22 if warm restart is enabled) is present in the project file. A missing OB causes the substitution error 0x1F0F listed above.
3. Confirm that the data blocks referenced inside OB20 have their declaration present in the project (read-only is sufficient; the runtime instance is rebuilt at startup).
4. For each FB that calls another FB, verify that the called FB's FB header declaration matches the instance-DB layout. A mismatch produces a DB-internal error after a few scans, often first observed as a periodic STOP-restart loop.

6. Profibus BF LED and Station Loss

A second, independent symptom is the Profibus BF (Bus Fault) LED being lit on the CPU928B and one slave not exchanging I/O. The CPU928B hosts the DP master function; the BF LED has these states:

Troubleshooting steps for a single missing slave on a recommissioned machine:

1. Verify the 24 V supply on the repeater / OLM segment that the missing slave sits behind. Months of downtime can drain decoupling capacitors and the first power-up can sag the rail.
2. Swap the slave's Profibus connector with a known-good one. The integrated terminating resistor can fail open.
3. Check the GSD file revision. The CPU928B's DP master stores the slave GSD revision in DX2. A slave that has been re-flashed with newer firmware but a stale GSD in the master project is the most common cause of a fast-blinking BF after long downtime.
4. Use the FDL trace or COM 928B diagnostic to read the diagnostic buffer of the failing slave. A Diag.Data_Diag Station_Status = 0x07 confirms an external diagnostic that the master is reporting as "slave not ready".
5. Verify the I/O assignment in DX2 matches the physical slot order. After long downtime it is common for the rack numbering sticker to have been lost or the chassis to have been re-stacked in a different order than the original documentation.

7. Software Tooling: STEP5 vs IBH S5/S7

Both packages can clear the user memory, perform a full download, run the compress function, and display the I-STACK. The fundamental limitation is identical: they cannot store more than the physical RAM in the CPU928B, regardless of how many times the compress function is invoked.

8. Step-by-Step Recovery Procedure

1. Verify the hardware. Confirm the CPU928B order number, the memory submodule type (RAM vs EPROM) and the fitted capacity. Replace the lithium back-up battery if its voltage is below 3.0 V; on a CPU that has been unpowered for months, a flat battery will force a full memory reset on every power-up, which in turn means a different OB cold-start path.
2. Read the I-STACK before any project modification. Record the stop cause and the B-STACK as text or screenshot.
3. Clear the user memory using PLC > Memory > Clear (STEP5) or Online > Target system > Clear user memory (IBH).
4. Edit the transfer list. Exclude every DB that is recreated by OB20, OB21, OB22 or by a cyclic OB. Refer to the project's printed block list to confirm.
5. Re-download the program to the CPU. Watch the memory usage report at the end of the transfer; the size should now be below the 32 K physical limit.
6. Compress memory once after the successful download to consolidate the blocks. Avoid running the compress function repeatedly without a corresponding download — it can delay the start of OB1 by several seconds on a CPU928B with fragmented RAM.
7. Switch to RUN. If the CPU still blinks STOP, re-read the I-STACK; the new stop code is more specific and points to a single remaining fault (typically a missing OB, a Profibus timeout, or an I/O chassis mismatch).
8. Resolve the Profibus BF if it remains lit (see §6). Confirm that the bus returns to a steady OFF state before the next restart of OB1.
9. Verify the program by force / observe on the live signals: cycle time, status of the diagnostic DB, value of the system clock DB. Save the now-verified project as the new master backup.

9. Verification Checklist

10. Edge Cases and Field Cautions

• Battery-fresh CPU: A CPU928B that has just received a new back-up battery performs a full memory reset on the first power-up. The first restart is OB20 (cold restart); warm-restart OBs are skipped. Programs that rely on OB22 for default values will appear to be missing data on that very first cycle.
• Half-populated rack: A removed or added I/O card on a recommissioned chassis can cause a cyclic OB1 → STOP. The I-STACK will report a parameter-assignment error. Remove the unused slots from the DX2 image as well, not just the hardware.
• EPROM vs RAM: If a RAM submodule is in the front memory slot and the EPROM is missing, the program only lives as long as the battery is healthy. After a long downtime the program can be lost silently. The "compress memory" loop then operates on whatever random pattern the RAM currently holds — which can mislead the field engineer into thinking the controller has stored data when in fact it does not.
• Multiple compress operations: Compressing a fragmented memory can take several seconds on a CPU928B with a 32 K base. If the function is triggered programmatically from OB1, it can push the scan time over the watchdog limit and create a self-induced restart. The function should only be triggered manually from the programming device.
• Faulty I/O card on an analog input: An analog input that has drifted can produce a value that overflows a downstream DB calculation, causing an arithmetic fault in OB1. The I-STACK reports the FB number and the DB number of the fault; the field fix is the I/O card, not the program.

11. Summary of the field report

The advice that comes from the experienced Siemens engineers in the field discussion aligns with this article's procedure:

• "To understand why the CPU is not going to RUN mode, you can evaluate the I-STACK of the CPU and refer to the Manual of CPU 928B." The I-STACK is the only authoritative source of information once the CPU has entered STOP.
• "Do you use RAM or EPROM in the slot, or is the slot empty?" The slot population defines whether the loaded program is volatile or retentive and whether the compress function has anything to act on.
• "Some DBs must be generated in RAM by OB20 and not copied into the PLC." This is the same point as the first bullet, expressed as a positive rule rather than a negative filter.
• "Check the I/O cards. One of them is faulty." A drifting or shorted I/O card can produce a non-obvious fault deep inside a runtime DB calculation and surface as a STOP-blink with a misleading I-STACK code. The hardware is part of the diagnosis.