OB 85 vs OB 122: Resolving S7-300 I/O Access Error CPU STOP

Problem Overview: S7-300 CPU STOP on I/O Access Error

A SIMATIC S7-300 (or S7-400) CPU transitions to STOP immediately when an I/O access error occurs during program execution, even if OB 85 is present in the project. The classic symptom is a CPU in STOP mode, an SF (system fault) LED lit, and a diagnostic buffer entry around event ID 16#4563. The engineer's expectation is that OB 85 — long taught as "the error OB" — should mask the fault and keep the CPU in RUN. That expectation is wrong: OB 85 and OB 122 serve different trigger conditions, and only one of them is fired by a direct I/O access error.

This article rebuilds the correct mental model around the two organization blocks, walks through the diagnostic buffer interpretation for event ID 16#4563, and provides a STEP 7 / TIA Portal procedure that prevents the CPU from going to STOP on distributed I/O faults. Real references from Siemens documentation are linked inline; do not rely on training material that conflates OB 85 and OB 122.

Root Cause: OB 85 and OB 122 Are Not Interchangeable

The training material that circulated widely taught that "OB 85 prevents CPU STOP on I/O access error." That statement is partially correct only if you read it carefully. The CPU operating system fires OB 85 for one class of faults and OB 122 for another. A diagnostic buffer that lists event 16#4563 after a STOP indicates an I/O access error — the precise event class handled by OB 122, not OB 85.

The CPU differentiates the two fault classes internally. The operating system schedules OB 85 asynchronously (when the background OB1 cycle tries to refresh the process image and the slave is gone). OB 122 is scheduled synchronously — it is invoked immediately when the offending load/transfer instruction executes, before the next network is processed.

OB 85 Detailed Function and Trigger Conditions

Per the Siemens functional description of S7-300/400 CPUs, the CPU operating system calls OB 85 whenever one of the following events occurs:

• An I/O access error during update of the process image by the system.
• An error when the operating system attempts to update a process image that is not configured.
• A fault when an OB that is required but not loaded is called (for example, OB 121 missing in a fault path).
• Errors when an OB is started that does not exist on the CPU (e.g., missing OB 10 for a time-of-day interrupt).

OB 85 does not trigger for every slave failure. It triggers specifically when the operating system itself is performing the I/O update — i.e., the cyclic process image refresh. If the failure is detected in user code via a direct L/T access, the CPU does not consult OB 85; it consults OB 122.

For S7-300, OB 85 has local temp bytes that identify the event. The OB85_FLT_ID byte (in the start information / temp area of OB 85) tells you which subclass of fault triggered the OB. Common values include:

Reference: Siemens STEP 7 Professional V14.0 — OB 85 documentation and OB 85 call on a distributed I/O access error (DAE) — TIA Portal docs.

OB 122 Detailed Function and Trigger Conditions

OB 122 is the synchronous fault OB the operating system calls whenever an error occurs while the user program is reading or writing data directly on a module. This includes:

• Load instructions (L PEW, L PED, L PIB) against a slot that has failed or is missing.
• Transfer instructions (T PAW, T PAD, T PQB) to a failed or missing module.
• Symbolic accesses via %I / %Q to a PROFIBUS DP slave that has dropped off the bus.
• Accesses to analog value status bytes when the analog module has returned a diagnostic interrupt.

OB 122 contains the following relevant start information (temporary local data):

Reference: Siemens TIA Portal documentation — I/O access error organization block (OB 122) for S7-300/S7-400.

Diagnostic Buffer: Interpreting Event ID 16#4563

Event ID 16#4563 in the S7-300/S7-400 diagnostic buffer is the "I/O access error" entry. It is generated when the CPU detects an I/O access error and writes the relevant module, address, and OB information to the diagnostic buffer. In practice you will see entries such as the following after a CPU STOP on a PROFIBUS DP slave failure:

Event 1   16#4563  I/O access error when reading
Event 2   16#4303  Mode transition from RUN to STOP
Event 3   16#3501  OB 85 not loaded, process image update error
Event 4   16#3942  Module fault / station failure on DP master system 1

The event class for OB 122 faults is 16#4563; the event class for OB 85 faults on the process image is typically in the 16#35xx group. Distinguishing the two is the first diagnostic step. If you only see 16#4563 entries and your project contains OB 85 but no OB 122, that is your smoking gun: the CPU needed OB 122, did not find it, and went to STOP.

Decision Flow: Which OB Does Your Fault Trigger?

Step-by-Step Resolution

The resolution is to insert OB 122 into the project (and verify the OB 85 DAE setting if PROFIBUS DP is in use). The OB itself needs no logic — an empty OB is sufficient to prevent the CPU from going to STOP on the fault class it covers. You can later add diagnostic or setpoint substitution code inside it.

Prerequisites

• STEP 7 V5.5 / V5.6 (classic) or TIA Portal V14 / V15 / V16 / V17 / V18 / V19 / V20 installed.
• The S7-300 / S7-400 project with online access to the CPU (MPI / PROFIBUS / Ethernet).
• PLC password if the project is write-protected online.
• The S7 program must be in a STOP-or-deferred state if you intend to do a full download; for incremental changes a "download to target device" of just the new OB is sufficient while the CPU is in STOP.

Procedure in STEP 7 V5.x (Classic)

1. Open the S7 project in SIMATIC Manager.
2. Right-click the Blocks container in your S7 program. Select Insert New Object > Organization Block.
3. In the dialog, choose OB122 from the list and confirm. A stub block opens.
4. Save and compile the project. OB122 is now present in the offline program.
5. Connect online (PLC > Connect to Target System). Select the CPU and download the block. Use Download (not "Download to Target Device" with stop/start if you want to keep the CPU in STOP for safety).
6. Switch the CPU to RUN. Verify that the SF LED clears and that the diagnostic buffer no longer shows 16#4563 followed by a STOP event.

Procedure in TIA Portal (S7-300/400 target)

1. Open the project in TIA Portal. In the project tree, navigate to Program blocks.
2. Double-click Add new block. Under Organization blocks, select OB122 — I/O access error.
3. Accept the default empty OB and save the project.
4. Go online. Right-click the new OB122 block in the project tree and select Download to device > Software (only changes).
5. Confirm the download. TIA Portal reports the new OB on the target.
6. Run the CPU. Check the diagnostic buffer for the original event 16#4563 and confirm it no longer produces a STOP.

Optional STL snippet inside OB122 (informational logging)

// OB 122 — I/O access error handler (STL)
// Latches fault info into DB99 for offline analysis.
      L     #OB122_SW_FLT      // B#16#42 read, B#16#43 write
      T     DB99.DBB   0
      L     #OB122_MEM_AREA    // 1 = PI, 2 = PQ
      T     DB99.DBB   1
      L     #OB122_MEM_ADDR    // byte offset in PII/PIQ
      T     DB99.DBW   2
      L     #OB122_POINT_ADDR  // logical base address of module
      T     DB99.DBW   4
      L     #OB122_LEN         // 1, 2, or 4
      T     DB99.DBB   6
      L     #OB122_BLK_TYPE    // block type of failing block
      T     DB99.DBB   7
      L     #OB122_BLK_NUM     // block number
      T     DB99.DBW   8
      SET                       // DO NOT RAISE — keep CPU in RUN
      SAVE
      BEU

This snippet is illustrative. The exact local variable names in TIA Portal may be SW_FLT, MEM_AREA, etc., depending on the generated interface. The principle is the same.

Distributed I/O (DAE) Configuration: OB 85 Call Behavior

If your project uses PROFIBUS DP (the user's case is a PROFIBUS-connected drive), there is an additional CPU-level setting that controls how aggressively OB 85 is invoked. According to the Siemens functional description, you should configure OB 85 calls only for incoming and outgoing errors, otherwise the CPU will fire OB 85 on every scan cycle in which the slave is still missing, which can quickly overload the OB 85 priority class and degrade the cycle time.

Where to find the setting

• STEP 7 V5.x: In HW Config, open the CPU properties → Cycle/Clock Memory tab → OB 85 Call for I/O Access Errors dropdown. Choose "Only for incoming and outgoing errors".
• TIA Portal: In the device view, open the CPU properties → Cycle time / OB 85 call on distributed I/O access error. Select the same option.

Reference: OB 85 call on a distributed I/O access error (DAE) — S7-300/S7-400.

Verification Procedures

After inserting OB 122 (and configuring OB 85 DAE behavior if applicable), verify the fix on the live system:

1. Diagnostic buffer: Clear the buffer (PLC > Clear/Reset Diagnostic Buffer). Power-cycle the DP slave or pull its PROFIBUS connector. Confirm that an OB 122 entry appears in the buffer but no STOP transition is recorded.
2. CPU mode: The CPU stays in RUN with the SF LED lit. This is correct — OB 122 handles the fault, the CPU does not stop.
3. Process behavior: Your application logic should treat the substituted input as "stale." If the drive was reading a process value (e.g., actual velocity) from the failed slave, the OB 122 should set a substitute value or freeze the last good value; do not allow the program to act on garbage.
4. Fault clearing: Restore the slave. Verify that an "incoming/outgoing fault" pair is recorded and that no follow-on faults accumulate in the buffer.
5. Watchdog check: If OB 122 is called frequently (e.g., on a hot loop reading a faulty input), monitor OB1 cycle time — large amounts of OB 122 traffic can inflate the cycle time and approach the watchdog.

Troubleshooting Matrix

Safety and Engineering Considerations

Masking I/O faults with an empty OB 122 is appropriate for non-safety faults on non-safety-critical I/O. For safety-related I/O (F-CPU, fail-safe DP slaves, PROFIsafe), the fault handling rules are different and you must follow the safety program documentation from the F-library (Distributed Safety, F-Configuration Pack). A bare empty OB 122 on a safety program is almost always a violation of the safety validation.

For motion applications (the user's PROFIBUS drive case), best practice is to:

• Insert OB 122 with a substitute-value strategy (e.g., zero speed command, last good actual value) so the drive receives a defined state.
• Trip the drive via a separate safety path (STO, hard-wired E-stop) — do not rely on PLC-side fault masking for safety.
• Configure OB 85 DAE to "only incoming and outgoing" so the CPU cycle time is not consumed by repeat OB 85 calls.
• Wire the slave status word to a diagnostic DB so the engineering team can correlate OB 122 events with drive alarms.

Quick Reference Summary

• OB 85 ≠ I/O access error OB. OB 85 handles faults during system process image update.
• OB 122 = the actual I/O access error OB for direct read/write access.
• Diagnostic event 16#4563 = I/O access error class — needs OB 122.
• Diagnostic event 16#35xx = process image update error — needs OB 85.
• An empty OB is enough to keep the CPU in RUN; logic inside the OB is optional.
• For PROFIBUS DP / PROFINET IO, also configure the OB 85 DAE call behavior to "incoming and outgoing errors only."
• Always cross-check the diagnostic buffer after the fix — no 16#4563-induced STOP transitions should remain.