Troubleshooting CP 342-5 PROFIBUS DP Between Two S7-300 CPUs

Problem Overview

A field-engineering scenario frequently encountered in brownfield automation is the back-to-back coupling of two SIMATIC S7-300 stations through PROFIBUS DP using one CP 342-5 communications processor per station, with each CPU 314 acting as either the DP master (Class 1) or a DP slave. After project engineering in STEP 7 (classic) or TIA Portal and the subsequent download of the hardware configuration and user program, the BUSF (bus fault) LED on the CP 342-5 illuminates solid red, indicating that the module cannot establish a clean DP cycle with its peer. This article consolidates the diagnostic, programming, and commissioning procedure required to resolve this class of fault and to harden the resulting DP link against repeat occurrences.

The symptom (red BUSF LED) is a top-level indicator. The underlying causes range from missing DP_SEND/DP_RECV calls in OB1, mismatched PROFIBUS addresses, baud-rate disagreements, terminated bus segments, peer stations being powered down during bus scan, and slot/IO-mapping inconsistencies in the DP slave description (GSD-derived or configured locally). Each cause leaves a different fingerprint in the CP diagnostic buffer; engineers must read the buffer rather than guess from the LED color alone.

Hardware Components and Ordering Data

Use only released components from the SIMATIC S7-300 catalog to ensure the documented diagnostics behavior matches the firmware in your project. The CP 342-5 variants support DP-V0 and DP-V1 services at bus speeds of 9.6 kbit/s to 12 Mbit/s and provide the special diagnostic interface required for the diagnostic buffer readout steps later in this article.

PROFIBUS DP Fundamentals for S7-300-to-S7-300 Coupling

PROFIBUS DP is a token-passing master-slave protocol standardized in IEC 61158 / IEC 61784. In a two-station S7-300 link, one CP 342-5 operates as a DP master class 1 (DPM1) and is the active bus owner. The second CP 342-5 operates as a DP slave, exchanging I/O data on a cyclic basis with the master's poll. Siemens documents the engineering model and the master/slave roles in the official SIMATIC documentation set; refer to the TIA Portal v20 reference on DP master system basics for S7-300/400/1500 for the canonical definitions of master system, slave, DP master class 1, and distributed I/O.

Key parameters that the engineering tool stores per master system:

• Highest PROFIBUS address (HSA): typically 126, the maximum address the master will probe during startup.
• Bus profile: DP, standard, or universal. For two-CP back-to-back coupling, DP is the correct selection.
• Baud rate: both stations must match. 1.5 Mbit/s is the safe default for the CP 342-5 unless segment length forces a lower value (per the IEC 61158 segment table: e.g. ≤ 200 m at 1.5 Mbit/s, ≤ 1,000 m at 187.5 kbit/s).
• DP address: 1 to 125, unique per node. The master is usually 1 or 2; the slave must differ.

CP 342-5 Operating Modes

The CP 342-5 supports three operating modes, all selected from the CP's Properties in HW Config (STEP 7) or from the device configuration in TIA Portal:

1. DP master – The CP owns a DP master system. Up to 32 slaves can be attached, and the master polls each slave cyclically at the configured cycle time.
2. DP slave – The CP exposes its I/O image to a foreign master. The maximum I/O length per DP slave is 244 bytes input + 244 bytes output (DP-V0 contract; the actual usable length depends on the slave's GSD revision and the master's configuration).
3. PG/OP routing & S7 communication – The CP can be a passive S7 route without being a master. In DP mode the CP cannot simultaneously provide PG routing; the project must define one mode at a time.

For a station-to-station link, the master station's CP 342-5 must be configured as DP master and the peer's CP 342-5 as DP slave. The reverse assignment is invalid for cyclic DP-V0 I/O exchange.

Configuring the DP Master Station

Insert the CP 342-5 in the master station's HW Config at the slot next to the CPU. In STEP 7 (classic) the canonical sequence is:

1. Open HW Config, drag the CP 342-5 into the rack, and set its PROFIBUS address (e.g. 2) and the master's PROFIBUS subnet.
2. Set the CP operating mode to DP master; this converts the CP's DP interface into a master system.
3. Right-click the CP, choose Insert DP Master System, and define the bus profile and baud rate (e.g. 1.5 Mbit/s, profile = DP).
4. Drag the slave station's PROFIBUS node from the catalog onto the master system. If the peer is a third-party device, import its GSD file first via Options > Install GSD File and restart HW Config.
5. Open the inserted slave object and align the I/O configuration (slot 0, slot 1, …) so that the master's view of inputs/outputs matches the slave's projected I/O image in the CP 342-5 DP-Slave configuration of the peer station.
6. Compile and download HW Config to the master CPU.

Configuring the DP Slave Station

For the peer station, the CP 342-5 must be configured as a DP slave and the I/O mapping exported to the master via the DP-Slave Properties > Configuration dialog. Critical settings:

• DP slave address: must be unique on the segment, must not collide with the master address, must be ≤ HSA.
• Vendor / GSD identifier: leave at the Siemens CP 342-5 default; do not select a third-party GSD unless the peer is non-Siemens.
• Diagnostic interrupts: enable so that the CP can report a slave-not-found or configuration-mismatch event back to the master.
• Sync / Freeze: disable unless the application requires coordinated output freezes.

Compile the slave station's HW Config and download the configuration to the peer CPU. The slave CP will not enter DATA-EXCHANGE until the master begins polling, and the master will not begin polling until its own bus scan completes and the slave is reachable on the wire.

Programming the DP_SEND and DP_RECV Function Blocks

The CP 342-5 does not automatically exchange its I/O with the S7-300 process image. The user program on each station must call the Siemens-supplied FC1 DP_SEND and FC2 DP_RECV blocks every cycle so that the CP's buffer is copied into the S7-300 I/O area (or to/from a data block when using the any-pointer variant). Skipping this call is the single most common cause of a healthy-looking bus that nevertheless shows the slave as not in data exchange.

The blocks are installed from the STEP 7 standard library at SIMATIC_NET_CP > CP 300 > Blocks. Place FC1 and FC2 into the master station's block container, and place another pair into the slave station's block container. The signature of FC1 DP_SEND is:

// FC1 DP_SEND (input side, written by the user program)
// Inputs:
//   CPLADDR  : WORD   // base address of the CP 342-5 (e.g. W#16#100)
//   SEND     : ANY    // source area (DB, MW, …) with data to send
//   DONE     : BOOL   // one-shot on successful handshake with CP
//   ERROR    : BOOL   // 1 = error this cycle
//   STATUS   : WORD   // status word from the CP, see error table below

FC2 DP_RECV has the same CPLADDR and a RECV ANY pointer; it transfers data received from the peer CP into the specified DB/M area and reports DONE / ERROR / STATUS identically.

A minimal OB1 call pattern on the master side:

// Master station OB1 (call every cycle)
CALL  "DP_SEND"
  CPLADDR  := W#16#0100          // CP 342-5 base address
  SEND     := P#DB10.DBX0.0 BYTE 32   // 32 bytes out to slave
  DONE     := M10.0
  ERROR    := M10.1
  STATUS   := MW12

CALL  "DP_RECV"
  CPLADDR  := W#16#0100
  RECV     := P#DB11.DBX0.0 BYTE 32   // 32 bytes in from slave
  DONE     := M11.0
  ERROR    := M11.1
  STATUS   := MW14

On the slave station, OB1 must call FC1 and FC2 with the same CPLADDR but with the mirror direction: what the master sends to the slave is what the slave receives via FC2, and vice versa. The DP-V0 contract of the CP 342-5 guarantees consistent handshake as long as both stations cycle OB1 faster than the configured DP cycle (default 10 ms).

BUSF LED States and Their Meaning

The BUSF (bus fault) LED on the front of the CP 342-5 is the most direct top-level indicator. State interpretation is documented in the CP 342-5 manual and is summarized in the table below for fast field reference.

Reading the CP 342-5 Diagnostic Buffer

The diagnostic buffer is the most reliable tool for moving from red LED to definitive cause. In STEP 7 (classic), open the project, right-click the CP 342-5 in the station, and choose PLC > Diagnostic/Setting > Diagnostic Buffer. In TIA Portal, use Online & Diagnostics > Diagnostic buffer on the CP. The buffer stores the last events with timestamp and event ID, and the entries correspond to the standard SIMATIC event catalogue.

For two-station DP coupling, the buffer entries that are the most common in this scenario are:

Each event is timestamped against the CP's local time base. Read the entries in chronological order, focus on the first entry that explains the cascade, and use it as the working hypothesis for the corrective action.

Step-by-Step Commissioning Procedure

Use this procedure when commissioning a fresh S7-300 to S7-300 link, or as a regression test after a configuration change.

1. Power up both stations. Verify that the CPU's SF/BATF and the CP's SF/STOP LEDs are off. The CP 342-5 must show a steady green RUN LED before the bus scan begins.
2. Inspect the bus segment. Confirm that the terminating resistor is ON at both physical ends of the segment and OFF on every node in between. With only two stations, both must terminate.
3. Verify address and baud rate on the CP module's rotary / DIP switches (if present) or in HW Config. The CP 342-5 stores the address in non-volatile memory after download; if the project is later changed, the CP must be reset (MRES) for the new address to take effect.
4. Download HW Config to the master CPU, then to the slave CPU. Each download must end with a restart of the affected CPU (cold restart) so the new bus parameters are picked up.
5. Download the user program (OB1, FC1, FC2, any DBs referenced in the ANY pointers) to both CPUs.
6. Set both CPUs to RUN. Watch the CP's BUSF LED. If it stays dark, the link is up; if it lights, drop to the diagnostic buffer before changing anything.
7. Run a loopback test: write a known pattern (e.g. MW100 = W#16#AAAA) in the master OB1 before the FC1 call, and read it back in the slave into a MW that is then displayed in a VAT table. Toggle the pattern bit-by-bit to verify the full 32 bytes.
8. Document the as-built configuration: PROFIBUS addresses, baud rate, slot mapping, ANY pointer lengths, CP firmware version, and CPU firmware version. This is the file that prevents the next outage.

Troubleshooting Matrix

Match the observed symptom to the most common root causes in the order they are most likely to appear in the field. The matrix is built around the red-BUSF-on-CP scenario, but is reused for any DP-V0 link that fails to enter data exchange.

FC1/FC2 STATUS Word Error Codes

When the CP returns ERROR = 1, the STATUS word reports one of a small set of standardized error codes. The most common values for a two-station S7-300 link are:

Verification Tests

After the BUSF LED is dark and the FC1/FC2 STATUS words return 0x7002 in a steady loop, run the following four verification steps before signing the commissioning report. Each is independent; passing all four gives high confidence that the link will survive a maintenance window.

1. Functional bit pattern test: write a walking 1 from MW100 on the master and read it back at MW100 on the slave in a VAT; confirm bit-for-bit match over 16 iterations.
2. Bus fault injection test: power down the peer station and confirm that the master CP raises BUSF solid red within one DP cycle (10 ms typical). Restore power and confirm that BUSF clears within the configured Reaction time (default 100 ms) and that data exchange resumes without a CPU restart.
3. Cycle time measurement: place an OB1_RT time read in OB1 and log the maximum OB1 runtime over 5 minutes with FC1/FC2 active. The maximum should be well below the DP cycle time; otherwise the bus scan will slow and the peer will see jitter.
4. Diagnostic buffer regression: clear the CP's diagnostic buffer on both stations, run the application for 30 minutes under representative load, and read the buffer. A clean session should report only the standard startup events (CPU restart, CP startup) and no 0x13Ax or 0x38Bx entries.

Field-Proven Notes and Caveats

• CP 342-5 does not auto-expose its I/O. Unlike the integrated DP interface of the CPU 314, the CP's data lives in a separate buffer and is moved to the S7 process image only by FC1/FC2. A project that omits these calls will show a "green" CPU and a red BUSF as soon as the master begins polling and finds no I/O handshake.
• Both stations must be powered up before the master's bus scan. The classic symptom of a peer that is offline at scan time is a permanent BUSF until the next CPU restart, even after the peer is powered up. The fix is to MRES the master CPU after the peer is on the wire.
• Termination is non-optional. With only two nodes, both PROFIBUS connectors must have their terminating resistor switches in the ON position. With three or more, only the two physical ends terminate. The CP 342-5 has no internal termination.
• FC1/FC2 call rate vs. DP cycle. A 1.5 Mbit/s DP cycle on the CP 342-5 is 10 ms by default. If OB1 runs faster than the cycle, FC1 will be called many times per cycle and return 0x7000 / 0x7001; that is normal. If OB1 runs slower than the DP cycle, the peer will see stale data and may drop the link; raise the OB1 priority or shorten the cycle.
• Shielding. PROFIBUS cable shield should be bonded to ground at both ends (Siemens recommendation for fixed installations). For EMC-sensitive sites, an RS-485 repeater (6ES7 972-0AA02-0XA0) provides galvanic isolation that absorbs common-mode transients that would otherwise trigger BUSF.
• Reset after address change. The CP 342-5 stores its PROFIBUS address in non-volatile memory. If you change the address in HW Config and download, the CP retains the old address until a CPU memory reset / MRES is performed. The diagnostic buffer will report 0x38B3 (parameter assignment error) until this is done.

FAQ