Resolving S7-300 CPU Stop Event 16#457F Triggered by SFC 46 STP

Problem Overview

An S7-300 CPU 315-2DP, configured as part of a software-redundant (SWR) pair and communicating over MPI to its partner and Profibus to existing SCADA/HMI, is forced into STOP immediately after the engineering station downloads a modified hardware configuration containing a newly added CP 343-1 Ethernet module (catalog number 6GK7 343-1CX10-0XE0). The CPU SF (Group Error) LED and BF (Bus Fault) LED blink together, the mode selector remains in RUN-P, and SIMATIC Manager > PLC > Diagnostics/Setting > Diagnostics Buffer records a single terminating event. The buffer entry identifies the stop as a user-program-initiated STOP command, originated from the warm-restart OB (OB100), and reports an FC call (FC 100) at module address 2860. Because FC 100 is part of the protected Software Redundancy library, the engineer cannot open the block source to confirm what is being executed.

This is one of the most common first-day failures when retrofitting Ethernet onto a live S7-300 SWR pair, and the root cause is almost always the same: a previously set test breakpoint still active in the startup sequence. When the warm restart calls OB100, the breakpoint fires, STEP 7/S7-PLCSIM/S7-300S debug firmware executes an internal SFC 46 STP, and the CPU drops to STOP before the redundancy initialization can complete.

Affected Hardware and Software Stack

The CP 343-1 Lean (CX10) provides one RJ45 port pair (10/100 Mbit/s) and supports S7 communication, TCP, UDP, ISO-on-TCP, and PROFINET IO controller (limited). It is suitable for the SCADA migration; the failure is not a result of catalog number or firmware mismatch.

Decoding the Diagnostics Buffer

Read the buffer top-down (most recent event at the top). The terminating entry is the only one that matters for the root cause; entries above it are downstream effects (communications failure, partner CPU no longer reachable, etc.) caused by the local STOP.

The combination of Breakpoint in user program + FC 100 + OB100 + Event 16#457F is the canonical signature of a residual debug breakpoint. STEP 7 stores breakpoints as instruction-pattern patches in the loaded S7 program. When a breakpoint is set, the STEP 7 online editor replaces the original machine instruction with a STP (or BLD/STA pattern that the firmware interprets as a breakpoint trap). The trap halts execution and requests a transition to STOP so that the PG can take control. When the program is later downloaded without first clearing the breakpoints, the patch remains in the CPU load memory.

Why Adding the CP 343-1 Triggered the Stop

1. The project is offline-edited: HW Config is opened, the CP 343-1 CX10 is dragged into slot 4 (or the next free slot), and the new Ethernet network is configured (IP address, subnet, S7 connection).
2. Station > Save and Compile rebuilds the system data blocks (SDB) and the offline program. The recompilation may strip breakpoint metadata or, depending on the option set, may leave the SDBs but rearm breakpoints during the next download.
3. PLC > Download to Target writes the new SDBs and user program to both CPUs of the SWR pair. The CPU detects a configuration change that requires a warm restart and executes OB100.
4. OB100 in a standard SWR application calls FC 100 (the SWR initialization block). FC 100 is reached. The instruction patch armed by the breakpoint trap fires.
5. The debug firmware recognizes the trap and calls SFC 46 STP internally. The CPU transitions to STOP. The BF LED blinks because the now-stopped CPU has dropped its bus connections, including the just-configured Ethernet interface.
6. The SF LED blinks because the SF group error is asserted for any STOP-with-error condition that is not a clean power-off/STOP-from-selector path.

The previously-added Ethernet CP is a symptom of the timing, not a cause. The same failure would appear on any future restart - for instance after a partner CPU failover, after a battery change, or after a manual restart from STEP 7.

Step-by-Step Resolution

Follow this sequence in order. Steps 1-3 fix the immediate problem; steps 4-6 harden the system so the issue does not recur.

Step 1 - Clear all breakpoints in the offline project

1. In SIMATIC Manager, open the S7 program and the OB100 source (and OB101/OB102 if present).
2. From the menu, choose Debug > Breakpoints > Delete All. This removes the instruction patches from the offline blocks.
3. Repeat the action for the entire project: in the LAD/FBD/ST editor you can use the keyboard shortcut Ctrl+Shift+F5 to remove all breakpoints in the open block, and PLC > Clear All Breakpoints when online to remove any breakpoints that are also armed in the CPU's online copy.
4. Save and recompile (Program > Compile All).

Step 2 - Perform a clean program download

1. Connect to CPU 0 (the master of the SWR pair). The CPU is in STOP.
2. Use PLC > Download User Program to Memory Card or, if the project is on a PG with EPROM, write the MMC with the cleaned blocks first.
3. Perform PLC > Download to Target and select the option Download user program only with Replace object enabled, so that all blocks (OB, FB, FC, DB, SDB, SFB, SFC) are overwritten with the freshly compiled versions.
4. Wait for the download to complete. Do not switch the mode selector yet.

Step 3 - Bring CPU 0 to RUN and validate

1. Turn the mode selector from STOP to RUN. The CPU performs a warm restart.
2. OB100 executes. FC 100 runs to completion. No breakpoint trap fires. SWR initialization (FB 100/FB 101 sequence) completes and reports the partner CPU as the standby.
3. Verify in PLC > Diagnostics/Setting > Diagnostics Buffer that the new entry is Mode transition from STARTUP to RUN (Event ID 16#4542 or similar) without a 16#457F entry.
4. Verify that the SF and BF LEDs extinguish within a few seconds of RUN entry. BF may briefly blink during Ethernet link negotiation; this is normal.

Step 4 - Repeat for CPU 1 (the standby)

Software redundancy is hot-standby symmetric: both CPUs must have identical breakpoints configuration. Connect to CPU 1, perform the same clear/download/verify cycle. Some teams prefer to bring CPU 1 up first to avoid a partner-side STOP propagation, but either order works as long as both CPUs are eventually verified clean.

Step 5 - Verify the new Ethernet CP is online

1. From Start > Simatic > SIMATIC Manager > Options > Set PG/PC Interface, select the TCP/IP interface pointing at the CP 343-1.
2. Open PLC > Accessible Nodes. The CPU should appear with the configured IP.
3. Open a free S7 connection (e.g. Options > Configure Network > right-click the S7 connection > Connection Status). Status should report ESTABLISHED for the S7 connection to the SCADA partner.

Step 6 - Lock the engineering workflow against re-introduction

• Document in the project README that "FC 100 is a protected SWR block; never set breakpoints in the SWR library path (OB100/OB101/FB100/FB101/FC100)".
• Add a project-level sign-off step: any engineer downloading to the SWR CPUs must confirm Debug > Breakpoints > Delete All immediately before download.
• Disable the Debug menu in the runtime PG profile used for production download, or restrict it via Windows group policy if the project is governed by a change-management process.

Verification Matrix

Why FC 100 Is Protected and What It Does

The S7-300 Software Redundancy package ("S7-SWRED" / library ID SWRED) ships with a small set of blocks that the customer is not supposed to edit. FC 100 is one of those blocks. Its role in OB100 is to perform the redundancy initialization handshake: it reads the role (master or standby) from the SWR instance DB, validates the partner's role and synchronization state, and prepares the data containers used by FB 100 (cyclic SWR operation) and FB 101 (start-up and resynchronization).

Because the block is delivered as compiled-only ("protected"), you cannot open the STL to find the literal CALL SFC 46. The breakpoint fires before SFC 46 is reached, so even a hypothetical STL view would only show the trap patch and the line after it. This is why the diagnostics buffer reports Breakpoint in user program rather than SFC 46 called from user program - they are the same event, but the breakpoint message takes precedence in the buffer formatting.

Alternative Root Causes (If Breakpoints Are Not the Issue)

If step 1-3 above do not clear the 16#457F entry, work through this list. Each row includes the diagnostic signal and the corrective action.

For each of the above, the fix is in HW Config or firmware, not in the SWR library. Most of these produce a different event ID; 16#457F combined with the words Breakpoint in user program almost always points back to the breakpoint path.

Reading the S7 Diagnostics Event IDs Used Here

The full mapping of S7-300/400 event IDs is documented in the Siemens Online Help for STEP 7 (Help > Contents > Diagnostics > Event IDs). Use this table only as a quick triage; the live buffer is the source of truth.

Reading Module Address 2860 in Context

The decimal value 2860 (0x0B2C) is not a Profibus station number or an Ethernet IP - it is an internal STEP 7 reference into the load-memory block table. For OB100 + FC 100, 2860 is a stable identifier on CPU 315-2DP for the breakpoint location inside FC 100's first network. Treat the address as confirmation that the breakpoint is inside the protected SWR block, not as a hint about the network or the new CP.

Safe Commissioning Procedure for S7-300 SWR with a New CP

Use this procedure when the protected FC 100 is in the project and you must change hardware. It is written to be executed offline on a simulated or stopped system, then promoted to the live system.

1. Open the offline project in SIMATIC Manager. Verify the SWR library version is consistent between the offline and online projects (Options > Compare Blocks).
2. Choose Debug > Breakpoints > Delete All in the LAD/FBD/ST editor. Save the project.
3. Open HW Config, add the CP 343-1, configure the Ethernet interface and any S7 connections. Save and compile.
4. Connect online to the standby CPU first (the lower of the two MPI addresses; SWR master is typically MPI 2, standby is MPI 3 by convention).
5. Place the standby CPU in STOP. PLC > Download to Target with the option Download user program and HW configuration. After the download, the CPU remains in STOP.
6. Switch the standby to RUN. The CPU warm-restarts, runs through OB100/FC100, and goes to RUN. Verify the diagnostics buffer shows the healthy STARTUP-to-RUN transition.
7. Repeat steps 4-6 for the master CPU. The two CPUs will renegotiate their roles on the next redundancy scan; if FB 100 reports the master role has flipped, this is normal after a download and the plant will not see a process interruption if SWR is configured for bumpless role swap.
8. Verify the new Ethernet CP from Accessible Nodes and confirm SCADA traffic is restored.

Edge Case: Breakpoint Set on the Online Copy Only

If a breakpoint was set on the online copy of OB100 but never on the offline block (a common situation during remote debugging sessions), the offline project looks clean and a recompile-and-download will not necessarily clear the online breakpoint. In that case:

1. Connect online to the CPU.
2. Open OB100 online.
3. From the menu, choose Debug > Breakpoints > Delete All. The instruction patches are removed from the online copy without changing the offline project.
4. Switch the CPU to STOP and back to RUN to clear the in-flight trap. If the CPU is in STOP because of the trap, simply clear the breakpoints and switch to RUN; the warm restart will run cleanly.

Edge Case: Compiled With Different Compiler Settings

STEP 7 V5.5 SP4 and later can produce blocks that contain new breakpoint trap opcodes that older firmware does not recognize. The reverse is also possible. If the SWR project is shared between engineering stations on different STEP 7 versions, recompile on a single agreed version and stamp the build with a project header that records the compiler version. Mismatched compilers have been known to produce blocks that carry a stray breakpoint marker across downloads.

Long-Term Hardening Checklist

• Keep one PG as the "production download" station, locked to a single STEP 7 version, with breakpoints disabled by default and the Debug menu pinned to a custom profile.
• Maintain a versioned archive of the offline project including the SWR library. Tag the archive with the date of the last breakpoint check.
• When migrating SCADA, follow the standard offline-edit > simulate > dry-run on a stopped CPU > promote to live workflow. Do not live-edit HW Config on a running SWR pair.
• Add the diagnostics buffer 16#457F signature to the site's PLC alarm classification so that on-call engineers can recognize the breakpoint case within minutes.
• Review the project's F-block and protected-block list once a quarter; remove any know-how-protected blocks that are no longer in active use, to keep the breakpoint surface area small.

Reference: SFC 46 STP Behavior

SFC 46 (STP) is the user-callable block that forces the CPU to STOP. The breakpoint trap implemented by the STEP 7 debug firmware uses the same CPU mechanism - the firmware pre-empts the call by replacing the instruction at the breakpoint with a STP opcode and setting a flag indicating it is a debug trap. The result is functionally identical to a user CALL SFC 46 from the engineer's point of view, which is why the diagnostics buffer records Event 16#457F in both cases.

SFC 46 has no parameters; it is a procedural "go to STOP now" instruction. OB1, OB100, OB101, OB102, OB121, OB122, and any FB/FC may call SFC 46. A well-written application calls SFC 46 only from a controlled error path (e.g. a hardware-fatal OB that requests an orderly shutdown). Calling SFC 46 in OB100 is a debug artifact, not a designed shutdown.

Reference: S7-300 Software Redundancy Block Set

The actual block numbers and names vary slightly across SWR library revisions; the role of FC 100 as the OB100 initialization block is the same across versions. The exact block numbers should be confirmed against the project's SWRED library header.

FAQ