Resolving Siemens S7-300 CPU 314C-2 DP Event 2522 2943 Faults

Problem Overview

A press-line controller based on a Siemens SIMATIC S7-300 CPU 314C-2 DP enters STOP and refuses to run any manual or automatic function. The CPU fault LED (SF) is lit, the STOP LED is on, and the diagnostic buffer fills with two repeating event patterns: 16#2522 "Area length error when reading, Global DB, word access" and 16#2943 "I/O access error, writing, P area, word access." The user is migrating from an Allen-Bradley environment and needs a deterministic, Siemens-native path to clear the fault without compromising machine safety.

The root cause is almost always one of three things:

1. A programming error where a code path accesses a global data block beyond its declared length (event 16#2522).
2. A PROFIBUS DP slave (or other I/O) that is configured in hardware but absent, powered down, or addressed incorrectly (event 16#2943).
3. Both conditions happening in the same scan because OB121 and/or OB122 are missing from the program, so the CPU escalates to STOP instead of absorbing the error.

This guide decodes the diagnostic buffer entries from the field, walks through the investigation, and gives the exact STEP 7 V5.x sequence required to recover the machine and prevent recurrence.

Affected Hardware and Firmware

Identify the exact module before changing firmware, blocks, or hardware configuration. The diagnostic buffer from the field lists the order number, hardware version, firmware version, and boot-loader version.

The CPU 314C-2 DP is documented in the Siemens manual S7-300 CPU 31xC and CPU 31x Operating Instructions and the S7-300 Automation System, Module Data reference. Always quote both the MLFB and the firmware version when opening a support case; firmware V3.3.11 has specific behavior with respect to OB121 priority class handling that differs from firmware V3.2.x.

Diagnostic Buffer Decode

The buffer is read in STEP 7 via PLC → Diagnostic/Setting → Diagnostic Buffer or via the SIMATIC Manager's Target system → Diagnose Hardware. Each entry is timestamped and carries an Event ID, the OB the CPU tried to call, a priority class, and a coded byte trail. The buffer from the field shows two distinct faults repeating five times within a one-second window.

Decode the byte trail by mapping each word to the OB121 / OB122 temporary area. The standard layout is documented in the STEP 7 Programming with STL/LAD/FBD reference manual.

For the 16#2943 entries, the same decoder gives 017A for "I/O access error, writing," 0020 as the area identifier for the peripheral (P) output area, and the access address shifted by 2 bytes depending on the word (PW36 -> PQW36, byte offset 36 = word 18, byte 38 = word 19, byte 40 = word 20). Confirm by cross-checking against the STEP 7 manual's OB122 temporary-variable layout.

Root Cause Analysis

Two distinct failure paths fire in parallel:

1. Event 16#2522 - Global DB read out of range. The access address 260 and 262 (decimal) point to DBW260 and DBW262 inside a global DB. The most common causes are (a) the DB has been recompiled and shrunk below the access offset, (b) a pointer that should be constrained is being loaded with an unbounded value from an HMI tag or indirect calculation, or (c) the program references a DB that no longer exists in the offline project but is still present online (a hallmark of incomplete block consistency after a partial download). The field cross-reference flags a missing DB49, DB10640, FB49, and FB640 - none of those numbers match 260 or 262, but they do indicate the project has structural damage that needs a full online/offline compare.
2. Event 16#2943 - I/O access error writing to P area. PQ (peripheral output) addresses 36, 38, and 40 fall outside the configured hardware. On the CPU 314C-2 DP the integrated I/O occupies PQ 0..31 (DI/DO) and PI/PQ 256..271 (AI/AO on PN/DP variants) - so PQ 36-40 sits in the DP slave I/O range. A slave that has been removed (the robot that was disconnected, per the field notes), a DP/DP coupler that is powered down, or a station number collision will all surface as a write fault because the CPU tries to clock out the data anyway during the DP cycle.

The combination of both faults is what escalates the CPU to STOP. Even one missing OB is enough to crash the system because, per the S7-300 system manual, the CPU treats an absent OB for a recognized error class as a fatal configuration error.

Event ID Quick Reference

Bookmark this table. It maps the Event IDs the field buffer contains to the standard Siemens classification and the correct remediation OB.

Step-by-Step Recovery Procedure

Follow the sequence in order. Do not skip the diagnostic read; jumping straight to OB121 loading will mask the real cause and the press will fault again on the next cycle.

1. Capture the as-built state

1. Connect to the CPU with STEP 7 V5.5 (or matching version) via MPI/PROFIBUS or Ethernet (CP 343-1 if present).
2. Select Target system → Save to Memory Card to back up the online program before touching anything.
3. Open PLC → Diagnostic/Setting → Diagnostic Buffer. Save the buffer as text.
4. From the buffer, list every Event ID, OB reference, and access address. The CPU also exposes the most recent stack (USTACK / BSTACK) - PLC → Diagnostic/Setting → Module Information → Stacks - which gives the exact block and line where the access failed.

2. Online / offline block compare

1. In SIMATIC Manager, select the S7 program and click Options → Compare Blocks (Online/Offline).
2. Document every block reported as different, missing, or extra online vs. offline. Pay close attention to OB, FB, DB and SFB/SFC instances.
3. If OB121 or OB122 is missing online, note that. This is the most common reason the CPU will not stay in RUN after the user pushes the mode switch.

3. Reconcile HW Config with the field

1. Open HW Config and look at the DP master system on the integrated DP port (X2) of the CPU 314C-2 DP.
2. For each configured slave (the G120 drive, the DP/DP coupler, and any ET200 stations), confirm:
   • PROFIBUS address matches the address set on the slave.
   • Slot configuration matches the actual module order numbers in the cabinet.
   • Terminating resistors are correct on both ends.
   • Shield is bonded at each cabinet entry.
3. For any slave that has been removed (the disconnected robot in this case), either delete it from HW Config and download, or mark the slot as reserved if the customer wants to keep the project architecture.

4. Resolve the missing / damaged blocks

1. Open the cross-reference (Options → Cross-Reference) and find every reference to DB49, DB10640, FB49, and FB640. If the references are dead and the blocks are not needed, remove the calls. If they are needed, restore the blocks from the most recent project archive.
2. Resolve the FB600 "DB?" cross-reference entries by tracing every indirect access. See the next section for the recommended pattern.

5. Load OB121 and OB122

1. Open the standard library: File → Open → Libraries → Standard Library.
2. From the Organization Blocks folder, drag OB121 (Programming Error) and OB122 (I/O Access Error) into the project Blocks folder.
3. Download both blocks to the CPU (Target system → Download or drag-and-drop with the Blocks folder selected).
4. The CPU will NOT clear the fault automatically. Switch the mode selector from STOP → MRES → STOP → RUN, or use PLC → Clear/Reset followed by Target system → Run.

6. Restart, observe, archive

1. Switch to RUN with the ram in a known safe position and the safety circuit verified.
2. Watch the diagnostic buffer for 30 minutes of normal operation. Confirm no new 16#2522 or 16#2943 entries appear.
3. Use the HMI or STEP 7 to force PQ 36-40 and confirm the writing fault is gone after the DP slave issue is resolved.
4. Archive the project (File → Archive) and store alongside the project backup.

Implementing OB121 and OB122 Properly

The default empty OB does nothing - it accepts the error and lets execution continue. For a press you almost always want at least a minimal log so the fault does not silently corrupt the recipe. A minimal but useful OB121 in LAD looks like:

// OB121 - Programming Error
// Input (auto-supplied by the CPU):
//   OB121_EV_CLASS  - event class (BYTE)
//   OB121_SW_FLT    - software fault code (BYTE)
//   OB121_PRIORITY  - priority class (BYTE)
//   OB121_OB_NUMBER - OB number (BYTE)
//   OB121_BLK_TYPE  - block type (BYTE)
//   OB121_FLT_REG   - fault register (DWORD)
//   OB121_DATA_ADDR  - data address (DWORD)
A     "M_Fault_DB".SysFlags.DBOutOfRange    // user-defined flag
=     "M_Fault_DB".SysFlags.OB121Active
L     OB121_EV_CLASS
T     "M_Fault_DB".OB121EventClass
L     OB121_SW_FLT
T     "M_Fault_DB".OB121FaultCode
L     OB121_FLT_REG
T     "M_Fault_DB".OB121FaultRegister
L     OB121_DATA_ADDR
T     "M_Fault_DB".OB121FaultAddress
BEU

The same pattern applies to OB122 using its specific temporary variables (OB122_SW_FLT, OB122_BLK_TYPE, OB122_MEM_AREA, OB122_MEM_ADDR). Refer to the STEP 7 Programming with STL/LAD/FBD reference manual for the exact layout per firmware version.

For machines that must meet ISO 13849-1 PL d or higher, the OBs must NOT just swallow the error. They should latch a fault flag, stop the cycle, and require a manual reset. Treat the OBs as the difference between a faulted CPU and a silently defective one.

Investigating Pointer-Based Access in FB600

The cross-reference shows FB600 is called four times with instance DBs 1002, 1000, 1006, and 1004. The "DB?" entries in the cross-reference mean the block uses ANY-pointer or pointer-style addressing (P#DB.DBX0.0 BYTE n) where the target DB number is computed at runtime. This is the most common pattern for 16#2522 faults on S7-300.

The pattern to inspect is typical of a copy/move library block:

// Inside FB600 - assume a 16#2522 on DBW262
// Source pointer loaded as P#DBxxx.DBX...
LAR1  P##SRC_POINTER       // input parameter of type POINTER
L     W [AR1,P#2.0]        // DB number from pointer
T     #tDB_No
OPN   DB [#tDB_No]         // open the dynamically referenced DB
L     DIB [AR1,P#4.0]      // byte offset from pointer
LAR1                        // AR1 now points inside the opened DB
L     DBW [AR1,P#0.0]      // *** can throw 16#2522 if offset > DB length

The fix is to clamp the offset before the read:

// Bounds check
L     #iByteOffset         // proposed byte offset
L     0
<I                        // below zero?
JC    ERR_OUTOFRANGE
L     #iByteOffset
L     DBNoOfBytes          // read DB length via SFC24 "TEST_DB"
>I                        // exceeds DB size?
JC    ERR_OUTOFRANGE
// proceed with the load

SFC24 ("TEST_DB") returns the actual length of a DB and lets the code distinguish a non-existent DB (return value W#16#80A1) from a too-short one. Inserting TEST_DB before the OPN DB call eliminates nearly every 16#2522 of this shape.

The Siemens S7-300/400 Pointer, Indirect Addressing and DB_ANY reference manual documents these techniques in detail: S7-300/400 Pointer and Indirect Addressing.

Resolving the P-Area (16#2943) Fault

For PQ 36-40:

1. Open HW Config and click the CPU 314C-2 DP. On the X2 (DP) port, view the slave list.
2. Identify which slave occupies PQ 36-40. The integrated DI/DO of the CPU itself uses P 0..7 / P 8..15 for byte images. The DP slave area begins immediately after.
3. If the slave that owns those words is gone (the missing robot in this case), either:
   • Delete it from HW Config and reload, OR
   • If the press retrofit must keep the slot reserved, insert OB122 with a write-suppression logic that masks the write to PQ 36-40 when the slave is in diagnostic state.
4. Use CPU → Module Information → PROFIBUS to view live DP diagnostics. A station showing red is the source of the access fault.

PROFIBUS DP station faults are also indicated by the SF DP LED on the CPU and an entry of class 16#3582 with OB86. If 16#3582 is also present in the buffer, the network level fault must be fixed first - the 16#2943 fault will then disappear automatically.

Verification Checklist

Run this checklist before handing the press back to production:

Diagnostic Flow

Preventing Recurrence

1. Always load OB121 and OB122 in new projects. Default them in the project template. This alone prevents the STOP escalation, though not the underlying fault.
2. Validate every pointer with TEST_DB (SFC24) before the OPN DB. Encapsulate this in a standard FB that all subsequent code must use.
3. Maintain a project archive discipline. Every download should be preceded by an archive of the offline project with a date-time stamp and the customer's signature. This avoids the partial-download state that produced the DB49 / DB10640 / FB49 / FB640 cross-reference debris in this case.
4. Run Target system → Save to Memory Card before any planned shutdown. The MMC holds the as-tested baseline. If the CPU loses its program, the backup is one insert away.
5. Document any DP slave removal at the project level. Mark the slot as reserved rather than deleting it; this preserves the architectural intent and makes it obvious to the next engineer why PQ 36-40 still appears in the code.

Field Note for Engineers Coming from Allen-Bradley

For comparison, a ControlLogix processor faulted by a bad tag reference behaves in a similar way - the controller drops to a faulted state and requires a "Clear Faults" action - and is documented at the Rockwell Automation knowledgebase. The conceptual model is identical (an exception in user code stops execution), but Siemens exposes the fault through OBs and a diagnostic buffer rather than a fault handler AOI. When working on both platforms, normalize on the OB / fault-handler relationship as the universal mental model: define what the controller should do when the user program does something the runtime cannot tolerate. For a deeper look at the underlying CPU exception concept - including what happens when an OB is itself missing - the general "double fault" model applies: Double fault (Wikipedia).

Frequently Asked Questions