Resolving Siemens S7-300 CPU STOP from BCD Conversion Errors

Problem Overview: S7-300 Enters STOP from a BCD Conversion Fault

An S7-300 CPU can be forced into the STOP operating state by a programming error raised inside a code block. One of the most common triggers is an invalid input to a BCD (Binary-Coded Decimal) conversion instruction such as BTI (BCD-to-Integer, 16-bit) or BTD (BCD-to-Double-Integer, 32-bit). When the operand word or double word fed into the conversion contains a nibble outside the legal range 0..9 (i.e. A..F hexadecimal) the CPU raises a programming error and, unless an error OB is loaded and active, transitions to STOP.

This article documents the recovery path for the exact symptom reported in the field: an S7-300 CPU halts after an unhandled error inside FC32, where a BCD conversion is being executed. The value being processed originates from a counter (C0) that has been moved into a data block word (DB1.DBW0) and then handed to a function whose BCD conversion is failing. The result is a CPU in STOP, a logged event in the diagnostic buffer, and a process that has lost control until the operator intervenes.

Background: How BCD Conversion Is Implemented on the S7-300

BCD is a numeric encoding in which each decimal digit occupies exactly four bits (a nibble). The S7-300 / S7-400 family implements BCD conversion through four dedicated instructions in the STL/Statement List and LAD/Ladder editors:

The sign of a BCD number is encoded in the most-significant nibble: 0000 = positive, 1111 = negative. The remaining 15 bits (BTI/ITB) or 31 bits (BTD/DTB) hold three (or seven) packed decimal digits. A conversion fails whenever any data nibble has a value of 10102 through 11112 (i.e. A..F), which has no decimal interpretation.

When the conversion instruction detects an illegal nibble, the CPU writes a programming-error event into the diagnostic buffer and calls OB121 (programming error). If OB121 is not present in the CPU's block container, the default reaction is to switch the CPU to STOP.

Why FC32 Stops the CPU: Trace of the Failing Data Path

The fault described in the field is rooted in a data flow that crosses two boundaries: counter-to-DB and DB-to-FC. A typical implementation looks like this in STEP 7:

1. A counter C0 accumulates pulses from an input (often an up/down count from an incremental encoder or a stepper position register).
2. The current count value is transferred into a shared data word such as DB1.DBW0 using a ladder rung such as:
   L C0
T DB1.DBW0
3. A function FC32 reads DB1.DBW0 and feeds it into a BTI or BTD instruction, expecting the data to be BCD-encoded because downstream it drives a seven-segment display or a BCD-only output module.

Two distinct root causes must be ruled out at this point:

• Counter value not BCD. C0 holds a binary (INT) count, not a BCD value. If the FC was designed on the assumption that the value was already BCD-encoded, the conversion is meaningless and any non-decimal nibble in the binary representation will trip the error.
• Counter rolled out of BCD range. Even if the source is genuine BCD, a 16-bit BCD count is limited to +999 for BTI or -9999999..+9999999 for BTD. A count of 1000 in BCD requires a sign-bit pattern (upper nibble) that is no longer legal as a count field, and the conversion will fault.

Reading the Diagnostic Buffer for the Exact Cause

Before editing the program, capture the diagnostic buffer of the S7-300 CPU. In STEP 7 (SIMATIC Manager) or TIA Portal (when the project has been migrated), open the online view of the CPU and select PLC > Diagnostics/Setting > Diagnostic Buffer (TIA: Online & diagnostics > Diagnostics buffer).

The most recent events are listed at the top. A BCD conversion fault produces a programming error with the following characteristic fields:

Record the faulted block, the relative address inside the block, and the priority class. With the address, you can navigate the source listing of FC32 in the offline project (or, if only the online project is available, in the editor after an upload to PG) and locate the specific BTI/BTD/ITB/DTB instruction that raised the error.

Understanding the Error OB Hierarchy on S7-300

The S7-300 supports a fixed set of error and interrupt OBs. According to the official Siemens documentation for the system diagnostics of S7-300 / S7-400, the CPU calls a specific OB when it detects each class of error. If the corresponding OB is not present, the CPU enters STOP.

The behavior of OB 85 is particularly relevant: per the official Siemens reference, with all other error events of OB 85, the CPU changes to STOP. This means that fixing one error class by loading OB 85 is not sufficient; the operator must load the specific OB that matches the error (in this case, OB 121) to suppress the STOP reaction. Always load the most specific OB that covers the actual fault.

Loading OB 121 by itself does not repair the underlying logic; it only prevents the CPU from stopping. The block must be instrumented to set a fault flag, increment an error counter, and force a safe fallback value. See the Preventive Measures section below for an implementation pattern.

Step-by-Step Recovery Procedure

The recovery sequence below assumes that the CPU is currently in STOP and that the project archive is available on the programming device.

1. Place the machine in a safe state. Disable drives, isolate hazardous motion, and follow the site lock-out/tag-out procedure. The CPU may force outputs to a defined state on STOP, but field confirmation is required.
2. Read the diagnostic buffer. Open the online connection to the CPU and dump the diagnostic buffer to a text file. Identify the block, the relative address of the failing instruction, and the event ID.
3. Upload the project from the CPU. Use PLC > Upload Station to PG in STEP 7 (or the equivalent in TIA Portal) to bring the live blocks onto the PG. This guarantees that the offline copy you will modify is identical to the running program.
4. Inspect FC32. Locate the BTI/BTD/ITB/DTB instruction at the address reported in the buffer. Trace the input operand back to its source. Document whether the input is a counter value, an analog input scaled into a word, or a value moved from a DB.
5. Confirm the assumption mismatch. If the input to the BCD instruction is a binary integer (typical for C0), decide whether the application really needs a BCD conversion. If the destination is a numeric display or a BCD-only output module, you must convert the binary value to BCD first with ITB or DTB after applying range limits.
6. Apply range guarding. Clamp the source value to the legal BCD range before the conversion. For a 16-bit BCD count, the legal range is 0..999 (or -999..+999 for signed). Anything outside must be saturated, faulted, or routed to a different code path.
7. Replace the bad conversion. Edit the rung to perform the correct conversion. If the upstream source is a binary counter and the downstream is a numerical display, use L C0, apply range limits with L 999 and <I / >I checks, and only then call DTB on a double-word that was previously loaded with the count.
8. Add an OB 121 handler (recommended). Even with the logic corrected, load a minimal OB 121 that increments a fault counter and sets a retentive flag. This converts future similar errors from a process-stopping fault into a logged event that operators can review.
9. Compile and download. Compile FC32 and OB 121. In HW Config, ensure the CPU is in STOP before downloading. After the download, the CPU will remain in STOP until you switch it back to RUN-P.
10. Restart and verify. Switch the CPU to RUN-P. Watch the diagnostic buffer for any new entries and monitor DB1.DBW0 with a watch table while exercising the counter input.

Replacing the Faulty Rung: Worked Example

Below is a STL snippet that demonstrates a corrected version of a typical fault path. The original code (assumed) is:

// Original (faulty): assumes C0 is already BCD
L     C0
T     DB1.DBW0
CALL  FC32                  // BTI on DB1.DBW0 -> fault when C0 > 999

The corrected code guards the range, performs an explicit binary-to-BCD conversion only when the value is in range, and signals a fault otherwise:

// Corrected
L     C0
T     DB1.DBW0              // binary count kept in DB1.DBW0
L     999
>I                         // C0 > 999 ?r>=     M10.0                  // out-of-range flag
SPB   OUT1
L     DB1.DBW0
ITB                         // C0 in range, convert INT to BCD
T     DB2.DBW0              // BCD value for display / output module
SPA   CONT
OUT1: L     0
T     DB2.DBW0              // safe default
S     M10.0                 // latch out-of-range for HMI alarm
CONT: NOP 0

Key principles in this rewrite:

• Separate the binary value (DB1.DBW0) from the BCD-encoded value (DB2.DBW0). Mixing them in a single DBW is a frequent source of confusion during commissioning.
• Guard the range before the conversion. BTI and BTD will fault on values outside the BCD-legal range; ITB and DTB fault when the source integer is out of the representable BCD range.
• Always provide a safe default value. A value of 0 is rarely a process-safe default; for displays, blank the value (L 0, T DB2.DBW0 is acceptable because BCD 0 displays as 000); for control outputs, hold the last good value and set an alarm.

Alternative Cause: Mixed Word Widths

A second, frequently missed cause of BCD conversion errors is a width mismatch. A 16-bit BCD variable (BTI/ITB) holds three digits. A 32-bit BCD variable (BTD/DTB) holds seven digits. If a value is loaded with L DB1.DBW0 and then passed to a BTD, the upper word of the 32-bit accumulator is whatever was in ACCU 1 from the previous operation. If the previous operation left a non-zero high word with non-decimal nibbles, the conversion faults.

Always clear the high word explicitly when widening:

L     0
T     DB1.DBW2              // clear high word of the 32-bit slot
L     DB1.DBW0
T     DB1.DBW2              // actually load low word
L     DB1.DBW2
BTD                         // now safe to convert

Or, equivalently, use the symbol-absolute addressing form L DB1.DBD0 (double-word at byte offset 0) so the CPU implicitly zero-extends the upper word for unsigned interpretation. Be aware that L DBD does not sign-extend; for signed values use ITD first, then DTB.

Verification: Proving the Fix Before Returning to Production

After the corrected program is loaded, perform the following checks before handing the line back to operations.

Preventive Measures: Building BCD-Safe Code From the Start

The cheapest BCD error to fix is the one that never happens. Apply these rules across the project, not only in FC32:

• Use one DB for binary, another for BCD. Never mix BCD and binary encodings in the same data word, even at different offsets of a DB. Engineers reading the code six months later will not remember the convention.
• Validate ranges at the source. Any integer that may be converted to BCD must be range-checked immediately after it is written. Use <I, >I, <D, >D for the comparison family and branch to a saturation / fault handler.
• Load a minimal OB 121 in every project. A 12-line OB 121 that increments a fault counter and stores the block type and number from its local data is enough to convert a stop-the-line fault into a logged event that is visible on the HMI.
• Document the encoding in the symbol table. Append _BIN or _BCD to every symbol that holds a BCD-encoded value. This catches accidental cross-references during code review.
• Commission the worst case. During FAT/SAT, force the counter to its maximum and minimum values and verify the conversion path. This is the only way to confirm that the range guards work under the actual scan pattern, not just the test cases the developer thought of.

Related Faults That Look Like a BCD Error

Before closing the ticket, confirm that the diagnostic buffer points to a programming error and not to one of these lookalikes:

FAQ