S5-100U CPU103 STOP Fault: Diagnose ISTACK I/O Not Ready and Restore Run Mode

The SIMATIC S5-100U CPU103 is a legacy Siemens programmable controller that remains in service across many European factories, water-treatment plants, and packaging lines. When a CPU103 drops to STOP mode overnight and cannot be returned to RUN without a full program delete and re-download, the field engineer is usually facing one of three root causes: a depleted backup battery, an I/O bus module that has partially failed, or a marginal power supply that collapses under load. This reference walks through the complete diagnostic sequence using the ISTACK (Interrupt Stack) and BSTACK (Block Stack), explains the meaning of the I/O not ready fault entry, and documents the procedure to reset the CPU without reloading the program.

1. Problem Statement and Field Symptoms

The reported fault pattern is consistent across several S5-100U CPU103 installations observed in the field:

• The CPU is in RUN at the end of the shift.
• During the night (no production activity), the CPU transitions to STOP.
• Attempts to switch from STOP to RUN via the mode selector or via the programmer fail; the CPU immediately returns to STOP.
• The ISTACK lists I/O not ready as the active interrupt cause.
• The BSTACK is reported as empty or incomplete, which means the OB (Organization Block) that called the failing I/O access could not be resolved at the time of the fault.
• A temporary remedy that clears the fault is: upload the program, delete all blocks, switch the CPU to RUN, then download the program. After this sequence the CPU stays in RUN for the remainder of the day.
• Disconnecting the operator panel (OP) appeared to change the fault pattern, which initially suggested a bus conflict.
• Replacing the lithium backup battery appeared to keep the CPU in RUN for several days.

The combination of these symptoms points to a non-volatile memory integrity issue interacting with the I/O bus initialization. The CPU cannot complete its I/O refresh sequence on a cold start because the program image or the I/O configuration descriptor has been corrupted, and the battery that should have protected it was either discharged or had lost contact.

2. S5-100U CPU103 Hardware Architecture

Understanding the S5-100U helps interpret the ISTACK correctly. The CPU103 sits on the leftmost slot of a 100U backplane. The backplane carries the S5 backplane bus (I/O bus) and the 24 V DC logic power. Modules to the right of the CPU are addressed in a fixed slot-based manner, with the digital I/O occupying 16-bit slots. The CPU103 contains the user program in RAM backed by a lithium battery and supports EPROM/EEPROM submodules for program backup.

The CPU103 powers up by executing OB 1 (cycle), OB 21 (manual restart), and OB 22 (automatic restart). The status of the I/O bus is checked during the warm restart phase. If the I/O bus handshake fails or a digital module does not respond, the CPU reports I/O not ready in the ISTACK and remains in STOP.

3. ISTACK and BSTACK Fundamentals

The S5 diagnostic stack is a fixed region in CPU RAM that the operating system updates whenever a fault occurs. The stack is read with the Siemens programmer (STEP 5) under the PLC > Information > Stack menu, or by typing the corresponding STEP 5 shortcut.

3.1 The Interrupt Stack (ISTACK)

The ISTACK describes the state of the CPU at the moment it entered STOP. The relevant fields for this fault are:

When the ISTACK reports I/O not ready, it means the CPU could not complete a PII (Process Image Input) or PIQ (Process Image Output) update because a digital or analog module did not acknowledge on the bus. The CPU refuses to enter RUN until the I/O bus reports healthy. This is a safety feature: starting with corrupt I/O data could lead to uncontrolled machine motion.

3.2 The Block Stack (BSTACK)

The BSTACK is the call trace of nested blocks. An empty or incomplete BSTACK at the time of an I/O fault typically means that the fault was detected during the system-level I/O scan, before the cyclic program had loaded the user call stack. This is the normal pattern for an I/O-bus-init-time fault and is not by itself an indicator of a programming error. It is, however, an indicator that the fault happened very early in the restart sequence.

4. Why the Delete-and-Reload Sequence Clears the Fault

The field-proven workaround upload > delete all > run > download works because it forces the CPU to rebuild all internal block headers and the I/O configuration descriptor from scratch. The runtime does not rely on any RAM-resident descriptor of the program structure; instead, it walks the freshly loaded block list and builds the cross-reference table (the BITSTACK and the call-level table) on the fly. If the original corruption was a stray pointer in the runtime tables caused by a battery under-voltage event, the rebuild removes the stray pointer and the CPU starts cleanly.

This explains why the fault was intermittent: the lithium battery, once its voltage dropped below the CPU103's RAM-retention threshold, allowed the block directory to drift, but only on a write event (such as the night-time OP communication or a tick of the time-of-day clock) did the corrupted data cause the I/O scan to fail.

5. Root-Cause Matrix for CPU103 STOP with I/O Not Ready

The following matrix maps observed symptoms to the most likely root causes, with the diagnostic step that confirms each one.

6. The Role of the PEU Flag

In S5-100U documentation, PEU typically refers to the Peripheral Error Unacknowledged condition captured by the I/O bus controller. When the I/O scan completes a write to a PII/PIQ byte and the addressed module does not return an acknowledge within the QVZ (Quittungsverzugszeit, the acknowledgment time window, default ≈ 65 ms on CPU103), the PEU flag is set and the interrupt stack is updated with the I/O-not-ready cause. The flag persists across the restart attempt and prevents the CPU from leaving STOP until either:

1. The offending module is removed, or
2. The bus is reset (CPU cold start with all blocks deleted), or
3. The PEU latch is cleared through a programmer-triggered warm restart in the correct mode.

This is why a simple STOP-to-RUN toggle does not recover the CPU. The PEU flag is sticky and is only released by a complete bus re-initialization.

7. Step-by-Step Diagnostic Procedure

Use this procedure to isolate the failure to a specific subsystem before ordering parts.

7.1 Prerequisites

• STEP 5 programmer (PG 720, PG 740, or modern PC with SIMATIC S5 driver and the original Siemens TTY cable)
• Digital multimeter with DC accuracy < 0.5 %
• Oscilloscope with 20 MHz bandwidth (preferred for the power supply check)
• Spare lithium battery (type 940-7BA or approved equivalent, 3.6 V, ≥ 1 Ah)
• Latest program archive on EPROM/EEPROM or on the PG hard disk

7.2 Capture the ISTACK and BSTACK

1. Connect the PG to the CPU103 with the mode selector in STOP.
2. In STEP 5, choose PLC > Information > Stack (or press F7 on a PG 7xx).
3. Select ISTACK and record all fields on the maintenance sheet, including the hex values of STOPS and USTACK.
4. Select BSTACK and record whether the stack is empty, incomplete, or contains a non-zero block number.
5. Take a photograph of the screen with a timestamp. This is your evidence trail before any state change.

7.3 Measure the Backup Battery

1. With the 24 V logic supply removed, measure the lithium battery voltage at the CPU terminal block.
2. A healthy battery reads 3.4 V to 3.6 V. Replace if the reading is < 3.2 V.
3. If the reading is < 3.0 V, do not attempt a restart yet. The RAM image is suspect. Power the 24 V back, force a complete cold start by deleting all blocks, switch to RUN, then reload from the EPROM/EEPROM.

7.4 Isolate the I/O Bus

1. With the CPU in STOP and program intact, switch the power off.
2. Label and remove the I/O modules from the rightmost slot, one at a time.
3. After each removal, restore power and attempt STOP-to-RUN.
4. If the CPU starts after a specific module is removed, that module is the source. Swap it with a known-good spare and re-test the full bus.
5. If the CPU still does not start with all digital I/O removed, leave only the CPU and the power supply on the backplane. The CPU should now start in STOP-to-RUN. If it does not, the fault is in the power supply, the backplane connector, or the CPU itself.

7.5 Verify the Power Supply

1. With the scope ground on the backplane earth, probe the 5 V rail at the CPU slot during a STOP-to-RUN transition.
2. The rail should be a flat 5.00 V ± 0.15 V. A sag below 4.75 V during the I/O scan window indicates a PS 930 (or PS 935) at end of life.
3. Probe the 24 V rail at the same instant. A drop of more than 0.5 V coincident with the I/O scan window indicates the supply cannot deliver the inrush current demanded by the digital output modules.

8. Resetting the CPU Without Reloading the Program

If the program archive is not present on EPROM and the engineer wants to keep the live RAM image, the following sequence is the field-tested way to clear the PEU latch without doing a delete-and-reload:

1. Switch the mode selector to STOP.
2. From the PG, perform PLC > Reset > Cold Restart. This is a CPU-side reset that re-initialises the system data area but preserves the user blocks in RAM.
3. If the PG offers Clear PLC, do not use it. Clear PLC deletes all blocks; the cold restart only re-initialises the system data and the I/O bus descriptors.
4. After the cold restart, switch the mode selector briefly to RUN and back to STOP, then attempt RUN again.
5. If the CPU still drops back to STOP with the same ISTACK content, the I/O bus fault is genuine and not a RAM-descriptor artefact. Proceed with the half-split isolation in section 7.4.

This procedure preserves the live program, which is useful when the customer's only archive is a printed listing and they cannot afford the production stop of a full reload.

9. The Delete-and-Reload Procedure (Documented Workaround)

The operator's sequence in the field report is fully valid and remains the recommended first action when the program archive is on EPROM and a downtime is acceptable. Document it here for completeness:

1. Connect the PG, switch the CPU to STOP.
2. Upload the program from RAM to the PG (PLC > Upload or F3). Save the file with a timestamp.
3. Delete all blocks: PLC > Delete > All Blocks.
4. Switch the mode selector to RUN. The CPU should now stay in RUN with an empty program.
5. Download the program back to the CPU: File > Download or F4
6. Verify the cycle time and the I/O scan with PLC > Information > Status.

This works because the new download forces a clean build of the runtime tables, including the I/O bus descriptor. The PEU latch is released during the new I/O bus initialisation because the empty program path does not access the failing I/O address.

10. Battery Replacement Procedure

The lithium battery on the CPU103 is a single 3.6 V cell. Replacing it while the 24 V logic supply is present is permissible and retains the RAM image. Replace the battery any time the voltage reads below 3.2 V under load.

1. Remove the OP/PG connector to avoid bus contention.
2. Note the polarity marking on the existing battery.
3. Remove the old cell and insert the new one within 30 seconds. The CPU's internal capacitance holds the RAM during this swap.
4. If the swap takes longer than 60 seconds, the RAM will lose its content. Plan a controlled cold start in that case.

After replacement, record the battery installation date on the door label of the cabinet. Siemens recommends a 5-year replacement interval as a preventive measure, even if the voltage is still nominal, because internal resistance rises late in the cell's life and may not be visible as a voltage drop until the cell is heavily loaded.

11. Power Supply Verification (PS 930 / PS 935)

The PS 930 is the 115/230 V AC input supply that delivers 5 V and 24 V to the backplane. A common failure mode of an aged PS 930 is the hold-up time dropping below the CPU's reset threshold when the I/O scan draws a burst of current. Symptoms include:

• CPU stays in RUN during the day (low I/O traffic) and drops to STOP at night (timer-driven writes).
• ISTACK reports I/O not ready even with all I/O modules removed.
• PS 930 fan (if equipped) is audibly louder than at commissioning.

To verify, capture the 5 V rail with a scope triggered on the rising edge of the I/O scan strobe. If the rail dips below 4.75 V for more than 10 ms, replace the PS 930. The PS 935 is the 24 V DC input variant and is checked in the same way on its 5 V and 24 V outputs.

12. I/O Module and Backplane Connector Checks

The S5-100U backplane uses gold-plated edge connectors. Oxidation on these connectors is a frequent cause of intermittent I/O faults. To inspect:

1. Remove each I/O module and visually inspect the gold fingers.
2. Clean with isopropyl alcohol and a lint-free swab. Do not use erasers or abrasive pads; they strip the gold plating.
3. Re-seat the module firmly. Confirm that the locking screws are tightened to the specified torque (typically 0.8 Nm).
4. Inspect the backplane fingers for wear. A backplane slot that has a darkened contact is past its service life and the entire backplane should be replaced.

13. Operator Panel (OP) Interface Considerations

Disconnecting the OP cleared the fault for a limited period in the field report. This is a meaningful data point: it indicates that the OP interface is either loading the bus excessively, or it is presenting a bad signal on the TTY current loop that confuses the CPU's bus arbitration. To verify:

• Test the OP cable for continuity on each conductor. The TTY current loop requires a pair of wires for the 20 mA loop; a partial break in the return path looks like a bus hang from the CPU's perspective.
• Confirm the OP address switch is set to a unique value not in use elsewhere on the bus.
• Verify that the OP's baud rate matches the CPU's PG/OP port configuration (default 9600 baud on CPU103).
• Check the termination. The S5-100U bus must be terminated at both ends. A missing terminator causes reflections that can be interpreted as a bus fault.

For modern OP replacements, the OP is replaced by an HMI that runs as a passive terminal and does not write to the CPU except on operator action. This greatly reduces the overnight risk.

14. Permanent Corrective Action

Once the root cause is confirmed, apply the permanent fix:

15. Verification and Commissioning Steps

After the fix, run the following verification sequence before returning the line to production:

1. Power cycle the CPU 103 three consecutive times, with at least 30 seconds between cycles, and confirm clean RESTART each time.
2. Leave the CPU in RUN for 24 hours, monitor the ISTACK for any USTACK warnings, and verify that the I/O scan completes within the nominal cycle budget.
3. Run an unattended weekend test: disconnect the OP for the full test to reproduce the original failure mode, and confirm the CPU remains in RUN.
4. Force a battery-disconnect test on a non-production CPU if a spare is available: pull the lithium cell, wait 5 minutes, restore the 24 V supply, and observe whether the CPU keeps the program. The test is destructive of the RAM image; only perform on a lab unit.

16. Preventive Maintenance Schedule

For an S5-100U CPU103 still in service, a quarterly PM schedule is recommended:

17. Relation to Modern S7 CPU STOP Behaviour

Engineers familiar with the S7-1500 platform will recognise the same pattern in a different form: a CPU drops to STOP because a module reports a fault, and the operator must clear the fault to return to RUN. The TIA Portal documentation for the S7-1500 describes the configurable reaction of a technology module to a CPU STOP, which is conceptually similar to the S5-100U's PEU latch in that the module's behaviour is bound to the CPU's operating state. The mechanism is different (the S7-1500 uses PROFINET diagnostics and module-level fault records rather than the 100U's bus-based PEU flag), but the diagnostic philosophy is the same: read the system-level fault information first, then isolate the failing component with a half-split, then verify with a controlled re-start.

For reference, see the official Siemens documentation on Reaction to CPU STOP for S7-1500 technology modules.

18. Field Notes and Common Pitfalls

• An empty BSTACK is not a programming error. It is the system-level I/O bus failing before the user stack was built.
• Replacing the battery alone is not always enough. The RAM image may already be corrupted, and a cold start with reload is required after the battery swap.
• The delete all blocks and switch to RUN trick works because the empty program path does not exercise the failing I/O address; it does not fix the underlying module.
• Disconnecting the OP can mask the fault. It is not a fix. The OP is a symptom contributor, not the root cause.
• Do not power-cycle the CPU more than five times in quick succession. The inrush current of the PS 930 shortens its life.

19. Escalation Path

If the half-split isolation in section 7.4 leaves only the CPU and the power supply on the backplane and the fault still reproduces, the CPU itself is the most likely cause. Siemens legacy support is reachable through the Siemens Industry Online Support portal at support.industry.siemens.com with the ISTACK capture as the first attachment. Provide the ISTACK hex values, the BSTACK state, the program listing, and the result of the half-split. The S5-100U manual and the CPU103 specific datasheet are the references Siemens support will request.

20. Summary

A CPU103 that drops to STOP overnight with an ISTACK that reports I/O not ready and an empty BSTACK is, in most field cases, the combination of a battery voltage drop and an I/O bus initialisation sequence that fails on cold start. The delete-and-reload workaround is a valid recovery path and clears the runtime tables, but the underlying cause is hardware: replace the battery, verify the I/O bus with the half-split technique, and oscilloscope the power supply rails under load. With the root cause corrected, the CPU returns to a stable RUN state and the night-time STOP fault does not return.