Identifying the Calling Block in S7-300 OB 121 Errors

1. Problem Description

On Siemens S7-300 and S7-400 controllers programmed in STEP 7 V5.x, a programming error such as an invalid indirect pointer, an out-of-range DB number, or a typed access violation against a non-instantiated DB triggers the operating system to call OB 121 (Programming Error Organization Block). The CPU enters STOP if OB 121 is not loaded, or executes OB 121 and continues the cycle if the OB is present.

Unlike a peripheral-access fault (OB 122) or a time-of-day fault (OB 80-87), OB 121 only supplies a small set of temporary local variables. These variables identify the type and number of the block in which the error occurred - but only when the error is reproducible on a static call. In production programs that use indirect and dynamically-parameterized calls, the populated values are frequently useless: the runtime system clears the registers before control is transferred to the user code in OB 121, or the block identifier refers to the calling FB while the fault is actually inside a deeply-nested FC, SFC, or instance DB. The engineer sees OB 121 fire, looks at the diagnostic buffer, and cannot determine which user block produced the bad address.

The symptom on the field is well known:

• CPU stays in RUN but a SF LED lights, the diagnostic buffer shows Event ID 0x2521 / 0x2571 (programming error), and OB 121 is listed as the response.
• Cycle time stays within limits; no other OBs fire.
• Reproduction is impossible at the desk because the fault only happens during specific runtime sequences (recipe change, dynamic multi-instance selection, batch indexing).
• Online monitoring in STEP 7 shows valid data in OB121_BLK_TYPE / OB121_BLK_NUM that points to the wrong block.

The objective is to determine, at the moment OB 121 begins executing, which user block was the most recent active code path when the indirect-access error was raised.

2. OB 121 Architecture and Temporary Variables

According to the Siemens Industry Online Support entry 109742272 - Programming error OB (OB 121) for S7-300/S7-400, OB 121 is called by the CPU operating system when a programming error is detected during execution of the user program. The OB must be loaded on the CPU; otherwise the CPU transitions to STOP with diagnostic buffer entry "STOP because programming error OB (OB 121) not loaded".

OB 121 publishes the following temporary (L-stack) variables at the start of its priority class:

The S7-300 CPU series (CPU 312 through CPU 319) does not maintain the same level of source-code cross-reference as the S7-400 when the error arises from an indirect memory operation, a register-indexed pointer, or a pointer-to-DB parameter. The CPU only knows the absolute address that faulted, not the symbolic block and instance. On the S7-400 (CPU 41x and CPU 41xH), the situation improves with several firmware versions because the operating system records a more complete context, but engineers continue to report cases where the block identifier is blank or wrong when a multi-instance FB uses ANY/POINTER parameters.

3. Root Cause: Why the Standard Diagnostics Fail

Three conditions in combination defeat the standard OB 121 variable block identification on the S7-300:

1. Indirect addressing does not carry a block tag. Instructions like L DBW[MD 200], AUF DB[MW 100], or CALL FB [MD 50], DB [MD 54] use runtime-computed numbers. The CPU can only flag the address register or status word that the decoder used; it cannot roll the call stack back to the symbolic origin.
2. The L-stack is shallow on S7-300. The CPU's interrupt acceptance frame on S7-300 is limited. The OS captures the topmost block number, but on a static call chain the topmost block is the one whose call instruction itself failed. If the failing instruction is inside a sub-FC, the captured value is the FC, not the calling FB that produced the bad parameter - so the error appears in the wrong layer.
3. Multi-instance FBs share a parent DI. When a multi-instance FB calls an FC that opens DB[AR1,P#0.0] and the offset is wrong, the OS reports the FC (or DB) number but cannot resolve the parent FB's instance name. Engineers tracing the error are forced to read disassembly of the STL, which is rarely useful in a running plant.

The only way to recover the calling context on the S7-300 is to record the block identity at the source, i.e. inside the block itself, before the indirect operation executes.

4. Solution Approach 1: Block-Marker Trap (Last-Caller Register)

The reliable engineering pattern is a block-marker trap: at the entry of every FB, FC, and multi-instance block that performs indirect access, write a small marker code into a global memory word (or a structured DB) that OB 121 can read. The marker uniquely identifies the block (type + number) and optionally the segment / network number so the engineer can narrow the search further.

4.1 Marker Encoding Scheme

Use a 16-bit WORD (two bytes). Define the high byte as the block type code and the low byte as the block number modulo 250. For block numbers that exceed 250 (FBlist, FClist), or to add a segment index, extend to a DWORD or to a small DB with a fixed layout.

For block numbers larger than 250, split the marker into a WORD plus a separate bit/byte: bit-mask high bits in MW + low 8 bits in the same word. In practice most S7-300 programs use FBs and FCs below 250, so the WORD is sufficient.

4.2 The Marker Write

Insert the marker write in Network 1 / Segment 1 of every block that performs indirect access. Use STL or LAD. The write must be the first executable instruction, before the indirect call, before AUF, and before L DBW[xxx].

STL example - inside FB 303, segment 1:

NETWORK 1 / SEGMENT 1 - BLOCK MARKER
      L     B#16#02            // FB type code
      T     MB   200           // store in marker byte 200 (high byte)
      L     303                // FB number
      T     MB   201           // store in marker byte 201 (low byte)

NETWORK 2 - PARAMETER VALIDATION
      L     #iIndex            // indirect index input
      L     0
      <I                       // is it negative?
      SPB   ERR                // yes -> jump to error handling
      L     #iIndex
      L     100
      >I                       // greater than array size?
      SPB   ERR                // yes -> error
      JU    NRM
ERR:  L     0
      T     #iIndex            // safe to zero
      BEA                       // block end (OB 121 will NOT fire here)
NRM:  ...

LAD example - in the temporary local variables interface:

Network 1: Block marker
      MOVE   B#16#02           // FB code
            MB200
      MOVE   303               // FB number
            MB201

4.3 The Marker Read in OB 121

OB 121 is loaded and edited exactly like any other block. In STEP 7 V5.x, double-click OB 121 in the project tree, choose STL or LAD, and read the marker at the very top. Then jump to error handling that copies the marker to the diagnostic buffer, sends a telegram, or increments a counter.

STL inside OB 121, Network 1:

NETWORK 1 - READ BLOCK MARKER
      L     MW   200           // last-caller marker
      T     MW   300           // copy to diagnostic word
      L     MB   201           // low byte = block number
      T     MB   301
      L     MB   200           // high byte = block type code
      T     MB   302

NETWORK 2 - CLASSIFY THE TYPE
      L     MB   302
      L     B#16#02
      ==I
      JC    FB_DETECTED
      L     MB   302
      L     B#16#03
      ==I
      JC    FC_DETECTED
      JU    UNKNOWN

FB_DETECTED: S   M  310.0       // "FB fault" flag
             JU  DIAG_STORE
FC_DETECTED: S   M  310.1       // "FC fault" flag
             JU  DIAG_STORE
UNKNOWN:     S   M  310.7
DIAG_STORE:  CALL SFC 20         // BLKMOV into diagnostic DB
             srcblk := P#M 200.0 BYTE 8
             dstblk := P#DB300.DBX 0.0 BYTE 8
             RET_VAL:= MW 304

NETWORK 3 - CLEAR FAULT REGISTERS
      L     0
      T     OB121_FLT_REG     // user has read it; clear
      L     0
      T     OB121_BLK_NUM     // ditto

The above pattern stores the last-caller into DB 300 (a dedicated diagnostic DB), so the engineer can inspect it online in STEP 7 with a watch table without disturbing the cyclic scan.

5. Solution Approach 2: OB121_FLT_REG Analysis

For static-call errors that do happen to leave valid values in OB121_BLK_TYPE and OB121_BLK_NUM, use the standard temporary variables directly. The Siemens KB 109742272 lists the fault codes and the corresponding meaning. The useful ones for block identification are:

For these fault classes, a small ladder network in OB 121 that simply copies OB121_BLK_TYPE to MB 302 and OB121_BLK_NUM to MW 304 yields enough information without any block marker. This is the path the TIA Portal F1-Help suggests when you search for OB121_FLT_REG.

6. Solution Approach 3: Segment-Level Debuggable Marker

The original case (from the user) added a second marker dimension: the segment index within the block. This is done by writing the active segment number into a separate marker byte after each potentially failing indirect access, or - more compactly - into a local variable that OB 121 does not see, so the engineer can correlate the marker in MB 201 with the segment number when reviewing the code offline.

// In every block, declare a STAT variable
VAR STAT
   sSeg : INT ;   // current segment (1, 2, 3, ...)
END_VAR

// Network N (the one that does the indirect access)
      L     17                // segment number 17
      T     #sSeg             // store
      L     DBW[#iIndex]      // indirect access (the one that fails)
      T     MW   120          // result

When OB 121 fires, the engineer reads MB 200 (type) / MB 201 (block number) and then opens the block, jumps to the segment indicated in the variable. With this technique the search is reduced from "every indirect access in every block" to "one segment in one block".

7. Implementation Procedure in STEP 7 V5.x

1. Create a diagnostic DB. Insert a new DB (e.g. DB 300) and define a data structure with at least: lastBlockType : BYTE, lastBlockNum : INT, lastSegment : INT, faultCounter : DINT, lastFaultCode : BYTE, lastDateTime : DATE_AND_TIME. Mark DB 300 as non-retain (no check in the properties).
2. Edit OB 121. In the project's Blocks container, double-click OB 121. If OB 121 does not yet exist, right-click the Blocks folder and choose Insert New Object > Organization Block, select Programming error OB, and confirm.
3. Write the read-and-classify logic as in section 4.3 above. Save and download OB 121 to the CPU.
4. Annotate every suspect block. For each FB and FC that contains an indirect access, insert a block-marker write as in section 4.2. Save and download.
5. Build a watch table. In SIMATIC Manager, right-click the Blocks folder, choose Insert New Object > VAT. Add the diagnostic DB and the marker MW 200 / MW 201. Open the watch table online (Monitor/Modify).
6. Trigger the fault and observe. Reproduce the original runtime sequence. When the CPU executes OB 121 the watch table freezes on the last-caller marker. The block number in MB 201 is your starting point.
7. Fix and verify. Add the missing range check, the wrong-number handling, or the missing DB. Remove the marker writes after commissioning if they cause measurable cycle-time impact, or guard them with a debug bit.

8. Optional: Diagnostic Buffer and SFC 17 / SFC 18

OB 121 entries already populate the diagnostic buffer. To extract them programmatically, use SFC 17 "ALARM_S" and SFC 18 "ALARM_SQ" only if you are prepared to configure the message texts. The simpler path is SFC 6 "RD_SINFO" which reads the start and current event information of the OB that is currently active:

// Inside OB 121, network 5
      CALL SFC   6              // RD_SINFO
      ret_val  := MW 308
      top_inf  := P#DB300.DBX 50.0 BYTE 32
      start_inf:= P#DB300.DBX 82.0 BYTE 32

After the call, the diagnostic DB contains 32 bytes of start-event information (block type, block number, OB number, address of the fault) that survives the OB exit and is available in the watch table for the operator to copy into the maintenance log.

9. Verification Steps

1. From the offline source, count the number of blocks you have annotated. The count must match the number of active blocks (loaded on the CPU) that perform indirect access. Open the cross-reference (Ctrl+Shift+F4) in STEP 7 V5.x and verify.
2. Force a known fault. Open an FC that writes a marker, and call it with a deliberately bad pointer (e.g. L 0 then L DBW[MW 0] with no DB open). The watch table should show MB 200 = B#16#03 (FC code), MB 201 = the FC number, and DB300.lastBlockNum filled.
3. Check the diagnostic buffer: CPU > Diagnostic Buffer in STEP 7. The last entry should be Programming error OB 121 with the block you forced, not the OB itself.
4. Confirm that the cycle time before and after enabling the marker trap is within the project's reserve (the two moves per block are < 5 microseconds each on a CPU 315-2 PN/DP).
5. Force a multi-instance failure. Open a multi-instance FB, replace the inner instance DB number with a non-existent one, and call. The marker should reflect the parent FB, not the missing instance.

10. Comparison with S7-400 and TIA Portal

If the project is being migrated to TIA Portal, the same OB 121 structure applies - TIA Portal does not magically fill OB121_BLK_TYPE/BLK_NUM with the originating instance on the S7-300. The block-marker trap remains the only reliable way to identify the calling context.

11. Common Pitfalls

• Placing the marker write behind a conditional jump. The marker is only updated on the path that the jump selects. If the indirect access is in the unselected path, the marker still shows the last block from the other path. Place the marker write unconditionally as the first statement.
• Re-using the marker bytes for other purposes. Many projects use MW 200 for HMI handshake. Reserve a separate MW (e.g. MW 280-290) and document it in the project.
• Forgetting instance DBs. A multi-instance FB does not call its instance DB explicitly. The marker must be set in the FB, and the parent FB's number must be encoded, not the instance DB number.
• Removing the trap after the fault is found. The trap is cheap and the next indirect access regression will require it again. Either leave it on guarded by a debug bit, or wrap it in IF #DEBUG_MODE THEN with a END_IF in SCL.
• Mis-reading OB121_FLT_REG as the block number. The FLT_REG is a status word that contains bit-level error information; it is not the block number. The block number is in OB121_BLK_NUM, which is a different temporary variable.

12. Field-Proven Caveats

• On CPU 315-2 PN/DP with firmware V2.x, OB 121 is called but the L-stack is partially overwritten by the second instruction in the same network. Always read OB121_BLK_TYPE and OB121_BLK_NUM in network 1 of OB 121, before any CALL or L-stack-consuming instruction.
• On CPU 317-2 PN/DP, multi-instance FBs share the DI register; the parent FB number is recoverable from the AR2 register's DI offset only in a few firmware versions. The block-marker trap bypasses this fragility.
• For plants with safety-integrated CPUs (CPU 315F-2 PN/DP), OB 121 is also called for safety-program errors but with a separate priority. Use OB 123 (for fail-safe blocks) and a parallel trap. The two OBs are independent; treat them as separate debug entry points.
• For S7-400H (redundant) systems, the diagnostic buffer is mirrored between both CPUs. Use only the active CPU's OB 121 marker. The standby CPU's OB 121 is not executed; it remains in the buffer of the standby for post-failover analysis.

13. Glossary

14. Related Siemens Documentation

For further reading, the following official Siemens resources cover OB 121 and the diagnostic interface:

• Programming error OB (OB 121) for S7-300/S7-400 (SIOS entry 109742272)
• S7-300 CPU 31xC and CPU 31x operating instructions (SIOS entry 13008499)
• S7-400 CPU 41x operating instructions (SIOS entry 33266799)
• STEP 7 V5.x Online Help: keyword OB 121
• SIMATIC S7-300/400 Standard Software - System and Standard Functions (Siemens manual, 6ES7398-8FA10-8AB0)