CPU314C-2DP System Fault: Resolving SF After CP343-1 Lean Config

Problem Description: SF After CP343-1 Lean Insertion

An S7-300 station built around the CPU 314C-2DP (typical MLFB 6ES7314-6CH04-0AB0 or 6ES7314-6CG03-0AB0 for earlier builds) reports a System Fault (SF LED solid red) the moment a CP 343-1 Lean module is added to the STEP 7 hardware configuration. With the CP slotted into the project, the diagnostic buffer fills with I/O access errors, OB121 and OB122 are called by the program scan, and the CPU refuses to enter RUN. Remove all user program blocks (OB, FC, SFC, FB, DB) and the SF extinguishes — this behaviour is the smoking gun. The SF is being raised by code running against an unreachable slave, not by a hardware defect on the CP itself.

The most common contributors to this exact symptom set are:

1. I/O modules behind the PROFIBUS DP slave being unpowered during bench testing.
2. A CP 343-1 Lean variant (order number, firmware level) that the CPU firmware cannot address.
3. A missing or wrong GSD file for the DP slave at address 2.
4. User code that issues L/T operations on process-image addresses that no module actually owns (slot addresses 256, 268, 270, 272 are the addresses to check first in HWConfig).

This article walks through each contributor in commissioning order and shows how to read the diagnostic buffer to localise the offending block within a few minutes. All references point to Siemens AG manuals, Siemens Industry Online Support, and the STEP 7 system documentation — no forum or community sources are used.

CPU 314C-2DP Hardware Overview and LED Meanings

The 6ES7314-6CH04-0AB0 is a compact CPU with an integrated PROFIBUS DP master/slave interface and 24 DI / 16 DO / 4 AI / 2 AO on-board. It is the typical target for CP 343-1 Lean retrofits because the Lean CP provides Industrial Ethernet where the CPU only offers MPI/DP at the front. Refer to the Siemens S7-300 Automation System and CPU 31xC Technological Functions manuals for the canonical specifications.

The four front-panel status LEDs you must read together are:

CP 343-1 Lean Variants and Compatibility with CPU 314C-2DP

The CP 343-1 Lean is documented in the CP 343-1 Lean Equipment Manual. The two order numbers most commonly encountered in the field are:

Both variants are electrically and functionally compatible with the CPU 314C-2DP backplane. There is no S7-300 hardware incompatibility that by itself triggers SF or BF — if the CP itself is healthy, you will see only S7-communication status entries (event IDs 0x4941, 0x4942, 0x4943, 0x4944) in the diagnostic buffer, never a hard SF. A persistent SF with CP 343-1 Lean inserted almost always points at something behind the DP master, not at the CP.

If you must rule the CP out as the cause, insert the CP alone, leave all OB1, OB82, OB121, OB122 empty, and re-download. With no user I/O access, no SF should appear.

OB121 and OB122: The Two Most Likely Causes

Both OBs are error-handling OBs provided by the S7-300 operating system. They are passive — they do not cause the fault, they are merely called by the operating system when the fault has happened. Their presence in the diagnostic buffer is the evidence trail.

For the SF described in this scenario, OB122 is almost always the headliner: the program tries to read from a slot owned by a DP slave that is unpowered or unreachable, the CPU cannot complete the access, OB122 fires, and OB121 is called if any of the local-variable processing inside OB122 itself raises a programming error.

The single most useful byte inside OB122 is OB122_BLK_NUM — it tells you the FC/FB/SFC/SFB whose scan raised the access error. OB122_PRG_ADDR tells you the absolute byte/bit address of the failing I/O. Together those two values localise the fault to a single statement.

Reading the S7-300 Diagnostic Buffer

The diagnostic buffer is the primary diagnostic surface for any SF/BF on S7-300. The procedure is identical whether you use STEP 7 V5.5 or TIA Portal:

1. In SIMATIC Manager or TIA Portal, mark the CPU and select Online > Online and Diagnostics.
2. Open Diagnostics Buffer in the navigation tree.
3. Click the most recent SF/BF entry. The detail pane shows the event ID, the associated OBs called, and the OB local variables from the moment of the fault.
4. Click Save As on the buffer page to export a diagnose.txt that you can attach to a Siemens Service Request or read offline.

By default the buffer holds the last 100 events (smaller builds) or up to 500 on bigger CPUs. If you only see the oldest 10, open HWConfig > CPU Properties > Memory and increase Number of entries in the diagnostic buffer. Acceptable maximums depend on the CPU; the 314C-2DP supports up to 500.

Step-by-Step Isolation Procedure

Run this sequence in order. Most cases resolve in under 15 minutes.

Step 1 — Confirm power on every DP slave

From HWConfig, mark each DP slave in the rack and confirm that the configured slot addresses match the physical layout. Then physically inspect each slave:

• 24 V supply present?
• PROFIBUS terminator on at both line ends only?
• Slave address switches match HWConfig (DP master at default 2 in this scenario)?
• Slave SF / BF LEDs clear?

Step 2 — Read the diagnostic buffer

Go online, open the diagnostic buffer, and look for "I/O access error when reading" or "I/O access error when writing". Note the slot address in the event text — it must match a slot configured in HWConfig.

Step 3 — Identify the offending block

Open the OBs called by the fault (OB121, OB122). In STEP 7 V5.5 with the program in LAD/FBD/ST, place a temporary breakpoint or insert a statement at the top of the called OB:

// In OB122:
L #OB122_BLK_NUM
T MW 200

Then go online and trigger the fault. MW 200 holds the FC / FB / SFC number of the block whose scan raised the access error. Cross-reference that block in the project to find the failing statement.

Step 3a — Read the failing I/O address

// In OB122:
L #OB122_PRG_ADDR
T MW 204

MW 204 then contains the absolute byte address of the input or output that faulted. Compare it to the slot address list from HWConfig (256, 268, 270, 272 are common defaults).

Step 4 — Replace unreachable I/O with P# access to a known module

If the slave must remain physically unpowered for the test, replace direct access (L IW 256, T QW 272) with a fault-tolerant read pattern:

// Safe pattern — call instead of the direct access:
CALL "READ_PIW_SAFE"
  PIW := 256
  RET_VAL := MW 100

The "READ_PIW_SAFE" wrapper executes the read inside a SFC that returns a status word instead of triggering OB122 if the module is unavailable. Centralised wrappers are far easier to maintain than per-tag retry logic.

Step 5 — Verify

Re-download, switch to RUN, and confirm SF is off and BF is off for 60 seconds under normal scan load.

Power-Up Sequence and Module Diagnostics

When a DP slave is unpowered, the DP master detects the dropout on the next poll cycle and posts a "station failure" event to the diagnostic buffer. That event calls OB86 (rack failure OB). If OB86 is missing or empty, the SF LED lights. To clear this case properly:

1. Insert OB86, OB82, OB121, OB122 into the project.
2. In OB86, leave the body empty (just BE) — the OB exists to acknowledge the failure so the CPU does not STOP.
3. In OB82, leave the body empty as well.
4. In OB121 and OB122, you can either pass (just BE) to swallow the access error, or use the local variables as shown above to log the fault and continue.

CP 343-1 Lean Configuration Pitfalls

Although the CP itself rarely causes an SF, several configuration mistakes do. Verify each:

Common Diagnostic Buffer Event IDs

The Siemens System Software for S7-300/400 System and Standard Functions reference manual lists every diagnostic event ID. The IDs that recur in this scenario are:

When you see 0x5371 followed by 0x530D in adjacent buffer entries, OB122 fired, then OB121 fired because the OB122 body itself contained a programming error. Fix OB122 first; the OB121 entries usually clear on their own.

Firmware and Library Compatibility

For a CPU 314C-2DP that needs to interoperate with a CP 343-1 Lean, the validated firmware combinations are:

Mixing a CPU at V3.3 with a CP at V1.x works for S7 communication, but PROFINET IO Device functions are missing and STEP 7 will warn about a version mismatch on download. Resolve the version warning before chasing SF symptoms, because a missing PROFINET slot configuration will look like an OB122 storm on the first scan.

Verification and Commissioning Checklist

Before declaring the SF resolved:

• Diagnostic buffer cleared and CPU in RUN, no SF, no BF for ≥ 60 s.
• OB86, OB82, OB121, OB122 present in the program with intentional bodies (not all empty).
• All DP slaves in cyclic data exchange — verify with PLC > Online > Monitor/Modify > PROFIBUS DP Diagnostics.
• CP 343-1 Lean diagnostic buffer shows connection establishment for every configured partner (event IDs 0x4941).
• Scan time below 80 % of the OB1 watchdog (typically 150 ms default).
• Diagnostic buffer export (diagnose.txt) saved with the commissioning record.

Edge Cases and Field-Proven Caveats

Symptom: SF only after PLC STOP → RUN transition. OB100 / OB101 / OB102 (warm restart / cold restart) startup OBs run once on the transition. Any direct I/O access in those OBs hits the same OB122 path before the DP poll loop has stabilised the slaves. Defer all I/O reads until the first OB1 cycle.

Symptom: SF clears when you delete one specific FC but not others. That FC contains the offending direct access. Open it, locate the L/T on the slot that does not reply, and replace with a status-aware read wrapper.

Symptom: SF appears only after adding a new SFC call (e.g. SFC 14 DPRD_DAT, SFC 15 DPWR_DAT) for a DP slave. SFC 14 / SFC 15 raise OB122 if the slave is unreachable but they return their own error code in RET_VAL (typically 80A1h for "slave not found"). Use the RET_VAL instead of relying on OB122 to tell you.

Symptom: BF solid red but SF off. Bus physics problem — terminator, shielding, baud rate, or address. Check the DP cable shield continuity and confirm the line is terminated at exactly two points (start and end).

Symptom: SF solid red but the diagnostic buffer is empty. Buffer may have wrapped or been cleared during the last STOP → RUN. Set buffer size to 500 in HWConfig and power-cycle the station. The buffer will re-populate on the next event.

FAQ