Resolving S7-300 CPU 315-2DP Internal System Error STOP Fault

Problem Description

When a SIMATIC S7-300 CPU 315-2DP (order number 6ES7 315-2AF03-0AB0) reports a Defective: internal system error entry in the diagnostic buffer and the controller drops to STOP, the symptom is an unrecoverable internal fault. The status flag DEFECTIVE (rather than ERROR or WARNING) tells you the CPU has detected a condition it cannot clear by itself. Operating system dispatch is suspended, all application OBs stop executing, and the only way out is to remove the root cause and power-cycle the rack.

Field observations on this part number cluster around four reproducible signatures:

• SF LED (red) steady on, RUN LED off, STOP LED on. The M+/M- LEDs (where fitted) reflect retained-bit behavior but the rack is dark to the application.
• The diagnostic buffer contains one to several consecutive entries with Event ID 16#4A04 and the plain-language text Defective: internal system error. No preceding OB80/OB82/OB86 time-stamped events appear.
• Swapping the CPU with an identical spare reproduces the STOP within minutes to hours. The spare's diagnostic buffer then shows the same 16#4A04 trace, which is the pivot signal: the CPU is the messenger, not the source.
• Removing or disconnecting a non-CPU module (CP 343, SM, IM 360/361, OP 27, or an attached Ethernet cable to a CP 343) clears the condition immediately. Re-attaching the suspect item brings the CPU back to STOP on the same shift.

Affected Hardware and Firmware

Match the part numbers exactly before you start pulling modules. The CPU 315-2DP family spans several MLFB revisions, and the diagnostic event IDs only make sense in the context of the correct catalog number.

Because the MLFB was phased out, the spare-pool realities are tight: identical replacements are used units, and authorized stock comes from distributors with limited inventory. The CP 343 family (6GK7 343-1...0XE0) is in a similar lifecycle state. Document the exact firmware of every module you touch, because mixed-firmware racks introduce soft errors that mimic the same Defective entry.

Reference: Siemens product page 6ES7315-2AF03-0AB0; S7-300 Automation System manual.

Diagnostic Buffer Event Decoding

The S7-300 diagnostic buffer is a ring buffer stored in non-volatile memory on the CPU. Each entry carries an Event ID (16-bit hex), a date/time stamp with millisecond resolution, and four 32-bit data fields. The Defective: internal system error text is the plain-language rendering of Event ID 16#4A04 on the CPU 315-2DP family.

The 16#4A04 entry is intentionally loud. The CPU does not call OB84 (CPU hardware fault) or OB86 (rack failure) for this condition. The reason is that an internal system error means the operating system itself lost its own sanity check - a watchdog, parity error, illegal microcode path, or a peripheral module is dragging the backplane. Raising an OB on top of a corrupt dispatch engine would re-enter the failure, so the CPU falls through to a hard STOP and lights SF.

How to pull the buffer in STEP 7 V5.5:

1. Open the SIMATIC Manager and connect online to the CPU over MPI or Profibus (address 2 is the default).
2. Right-click the CPU in the project tree, select PLC > Diagnostic/Setting > Diagnostic Buffer.
3. Read the entries from top to bottom. The most recent event is on top.
4. For each entry note: Event ID, OB reference, Dat1 through Dat4, and the date/time stamp.
5. Copy the buffer to a text file via Save As... for trend analysis. The same fault over three shifts usually shows a recurring Dat1 value that identifies the failing module.

In TIA Portal V14 SP1 or later, the equivalent path is Online & Diagnostics > Diagnostics > Diagnostic buffer. TIA Portal renders the same Event ID; the plain text and OB reference match STEP 7 V5.5. If you have a project on TIA Portal but the rack is S7-300 classic, install the legacy CPU in the device configuration with the correct MLFB to enable online diagnostics.

Root Cause Analysis - Where the Fault Actually Lives

When two CPUs fail the same way, six root-cause categories cover roughly 95% of field cases on the CPU 315-2DP family. Triage them in this order.

Step-by-Step Isolation Procedure

Perform the sequence in order. Each step terminates when the CPU stays in RUN for a full shift, and the next step becomes a regression test rather than an active intervention.

1. Capture the as-found state. Save the diagnostic buffer to a text file, photograph the LEDs, and record the slot number, MLFB, and firmware of every module in the rack. Tag the rack with the date/time.
2. Power down the rack (PS 307 mains breaker). Wait 30 seconds for the capacitor bank to discharge. Power up. If the CPU does not even reach RUN (i.e., it blinks briefly and drops), the fault is in the backplane or the first peripheral module. Continue with step 3.
3. Reduce the rack to the minimum: CPU, PS 307, and one slot of nothing else. Apply power. If RUN is achieved with the rack minimized, the fault is downstream - proceed to step 4. If RUN is still not achieved with only the CPU + PS 307, the fault is in the CPU, the PS 307, or the backplane bus connector.
4. Re-add modules one slot at a time in slot order from right to left. After each insertion, observe the CPU for ten minutes. When STOP reappears, the last module inserted is the prime suspect. Tag it.
5. Isolate the suspect module by swapping it with a known-good spare of the same MLFB and firmware. If the CPU returns to RUN with the spare, the original module is defective. If the CPU STOPs with the spare, the issue is in the slot, the backplane bus connector, or the wiring to that slot.
6. Inspect the Profibus / MPI connector on the suspect module and on the CPU. Unplug both. Check the +24 V pin (typically pin 2 / +5 V on pin 6 of the 9-pin D-sub per EN 50170) for short to ground or to shield. Replace the connector if the +24 V line is exposed to a damaged cable.
7. Test with the Ethernet cable to the CP 343 disconnected. This is the specific test that resolved the original case. If the CPU runs clean with the Ethernet cable removed, the CP 343 module or the attached network is the trigger. Replace the CP 343 module and the Ethernet cable; do not re-use a CP 343 that has already taken down a CPU.

CP 343 - The Common Culprit in Networked Racks

The CP 343 family of communications processors is the most common non-CPU module to drag an S7-300 rack into a Defective: internal system error STOP. The reason is structural: the CP 343 sits on the backplane bus, the same bus that the CPU uses to dispatch OB cycles. If the CP's bus interface fails, it does not just fail its own communication - it can hold the bus in a state that the CPU's bus arbiter cannot recover from.

LED interpretation on the CP 343 front panel:

When a CP 343 takes down the CPU, the SF LED on the CP is usually lit and the CPU's SF is lit. Both LEDs clear within a second of pulling the CP module out of the rack, confirming the cascade. Do not interpret "RUN on the CP" as "CP is healthy" - the CP can be in RUN but still dragging the backplane. The decisive test is rack isolation with the CP removed.

Reference: Siemens product page CP 343-1 (6GK7343-1EX11-0XE0).

HMI OP 27 on Profibus DP - Secondary Fault Path

The original case also includes an OP 27 HMI on Profibus DP. The OP 27 is a Profibus DP slave that talks to the CPU's integrated DP master (X2). It is not normally a primary cause of a Defective STOP, but a misconfigured Profibus network can push the master into a state where it issues a stream of bus errors that the CPU cannot dismiss.

Validate the Profibus path on the OP 27 side:

1. Confirm the OP 27 Profibus address (typically 1 or 2) does not collide with another slave.
2. Confirm the OP 27 GSD file is the correct one for the OP 27 firmware. Mismatched GSD revisions are a common source of DP master diagnostic interrupts.
3. Confirm the Profibus cable shield is bonded to PE at one end only. Double-bonded shields create a ground loop that injects noise into the RS-485 pair.
4. Confirm the bus terminator is on at the two physical ends of the segment only. An OP 27 in the middle of a segment with termination enabled is a frequent source of intermittent communication faults.
5. Measure the Profibus segment voltage on a healthy segment: A-B differential should be >1 V under load. Less than 0.5 V indicates a termination or cable fault.

Power Supply (PS 307) and 24 V Distribution

Even a healthy S7-300 can be tipped into a Defective STOP if the PS 307 cannot hold its 24 V output under transient load. The CPU 315-2DP family monitors the 24 V rail and treats brown-outs as a hard fault, not a recoverable OB81 event.

Verification steps:

1. Measure the 24 V output of the PS 307 with a true-RMS digital multimeter at the CPU power terminals. The reading must be between 22.8 V and 25.2 V under full load.
2. Capture the 24 V rail with an oscilloscope set to AC coupling. Any dip >200 ms below 21 V will trip the CPU's undervoltage monitor. Common sources are contactor pull-ins, solenoid valves, and inverter DC-bus capacitors charging on the same supply.
3. Verify the 24 V load current against the PS 307 rating. The CPU 315-2DP draws ~1.0 A from the backplane. A PS 307-1B at 80% load has no headroom for inrush transients.
4. Check the protective earth conductor at the PS 307. A floating PE on a TN-S system can let the 24 V common shift by tens of volts relative to the cabinet ground and cause a hard fault.

Resolution Procedure

Once the failing module or wiring is identified, the recovery path is mechanical and procedural. Do not skip the configuration reload even if the spare is identical to the failed unit.

1. Power down the rack. Mark slot positions and module order with a tag or photo.
2. Remove the suspect module. Bag it with a clear label: "Defective - taken down S7-300 CPU 315-2DP - rack SN - date."
3. Install the replacement module of the same MLFB and, ideally, the same firmware. If the firmware differs, update the HW Config in STEP 7 / TIA Portal and reload to the CPU.
4. If the replacement is a CP 343, reconnect the Ethernet cable. Confirm the switch port LED is green and the partner device has an IP address in the configured subnet.
5. If the replacement is a Profibus slave, verify the address switches on the slave match the HW Config.
6. Power up. Watch the CPU's RUN LED. The CPU should reach RUN within 5 seconds of the PS 307 reaching nominal output.
7. Reload the STEP 7 / TIA Portal project to the CPU. A clean reload is non-negotiable after a STOP - the diagnostic buffer is preserved across power cycles, but the application image on the MMC may be inconsistent with the as-found state.

Verification

Run the rack for at least 24 hours with the replacement in place and prove the fault is gone. Use a structured checklist.

If the buffer stays clean for 24 hours, close the work order and file the diagnostic buffer text as evidence. If a 16#4A04 entry reappears, return to step 1 of the isolation procedure - the second event typically points at a different root cause (often a backplane bus connector or a marginal power supply).

Preventive Measures and Migration Path

The 6ES7 315-2AF03-0AB0 is a discontinued product. Even with a working CP 343 replacement, plan an exit from the platform.

1. Spare-parts strategy. Maintain at least one verified CPU 315-2DP with matched firmware, one PS 307, and one CP 343 of each variant on the rack. Mark them with the calibration date and a burn-in log (minimum 48 hours of RUN time).
2. Install OB84, OB82, OB86, OB87, and OB121/OB122 in the S7 program. They do not catch the 16#4A04 hard STOP, but they catch the soft precursors (rack failure, diagnostic interrupt, communication error, programming error) that historically precede a hard fault by weeks. A module that does OB logging is much easier to triage.
3. Enable diagnostic buffer archiving. Use a WinCC or HMI script to read the diagnostic buffer every shift and archive it to a network share. The pre-fault buffer is the single best document for predicting a hard fault.
4. Replace the 24 V distribution with a redundant PS 307 pair if the cabinet budget allows. The 6ES7 307 redundancy module keeps the rack alive through a single PS failure.
5. Plan the migration to the CPU 315-2 PN/DP (6ES7 315-2AH14-0AB0) or to an ET 200SP CPU 1510SP-1 PN (6ES7 510-1DJ01-0AB0) with PROFINET. The S7-300 to ET 200SP migration guide from Siemens (entry ID 109759872) walks through the project migration in TIA Portal V16 or later.