Fixing CM PtP Receive_P2P 16#81E7 Synchronization Error on S7-1500 ET 200SP

The CM PtP communication module (6ES7137-6AA00-0BA0 and successor variants in the ET 200SP family) is a common point-to-point interface for ASCII, 3964(R), RK512, and Modbus master/slave protocols on S7-1500 systems. When paired with RFID readers, scales, bar-code scanners, or any serial slave device, the module relies on a coordinated handshake between the firmware and two user-side function blocks: Send_P2P and Receive_P2P. A failure of that handshake surfaces as STATUS 16#81E7 (synchronization error between the module and Receive_P2P), often followed by 16#7002 (interim call, data transmission running) and a frozen receive state that survives only a physical reseat of the module.

This article documents the root cause, the most common implementation mistakes that trigger it, the diagnostic procedure, the recovery sequence, and the architectural changes that prevent recurrence. It is applicable to the S7-1500 CPU family (1516F-3 PN/DP, 1517F-3 PN/DP, 1518F-4 PN/DP and equivalents) and to the S7-1200 CPU 1217C when the same CM PtP module is used in a distributed configuration.

1. Problem Description

Symptom signature observed in the field:

• The Receive_P2P block reports ERROR = TRUE and STATUS = 16#81E7 ("Synchronization error module and Receive_P2P. Make sure that different instances of the Receive_P2P do not access the same module").
• The next call to the same block returns STATUS = 16#7002 (interim call: data transmission in progress) and never transitions to 16#0000.
• Send_P2P on the same CM PtP continues to complete jobs successfully.
• Incoming characters are silently dropped; the diagnostic buffer of the CM PtP station shows no new entries.
• The only recovery is to pull and reinsert the module, or to power-cycle the ET 200SP base unit.

The error is not deterministic: systems have been observed to run for days or weeks between occurrences, then fail during quiet hours when no engineering activity is taking place. The failure is also reported to be more frequent immediately after TIA Portal download operations (HW or SW), even when the same application logic is loaded that was running before.

2. Affected Hardware and Firmware

Cross-reference the firmware versions of the CM PtP module, the interface module (IM 155-6), and the S7-1500 CPU in the TIA Portal device configuration. Mismatched firmware levels are a known contributor to synchronization faults because the Receive_P2P block exchanges sequence counters with the CM firmware that is generated for that firmware generation.

3. Status Code Reference

Source: Receive_P2P: Receiving data (S7-1200, S7-1500) and Error messages (S7-1200, S7-1500) from the TIA Portal help system.

4. Root Cause Analysis

The Siemens SIMATIC S7-1500 / ET 200MP / ET 200SP CM PtP function manual defines the synchronization handshake between the Receive_P2P instance DB and the CM PtP firmware. Three independent root causes for the 16#81E7 fault have been confirmed in field installations:

4.1 Multiple Receive_P2P instances targeting the same CM PtP module

When two instance DBs (Receive_P2P_DB1, Receive_P2P_DB2) issued from different FCs or OBs point to the same hardware identifier of the CM PtP module, the firmware can only service one receive pipeline at a time. A second Receive_P2P call that overlaps the first opens two parallel state machines in the CM. The firmware flags the second as a synchronization violation, the first state machine is forced into 16#7002 (stuck intermediate), and all subsequent receive calls are blocked until the module is reinitialized by physical reseat.

Reproduction is straightforward: call Receive_P2P from FC10 (cyclic OB1) and from FC20 (OB35, 100 ms). Within 10 – 30 minutes the 16#81E7 event will be logged, and the receive buffer stops updating.

4.2 Concurrent Send_P2P and Receive_P2P on the same module slot

Although the CM PtP supports half-duplex operation and full-duplex operation depending on the selected protocol, mixing a long-running Send_P2P job with a parallel Receive_P2P job on the same module slot has been observed to corrupt the internal state machine on firmware V1.x and V2.0. The block is rated to allow simultaneous jobs, but the firmware holds a single command queue per port. When the queue pointer is desynchronized by an interrupted transfer (for example, a TIA Portal download that forces a STOP → RUN transition), the next receive job surfaces as 16#81E7.

4.3 STOP → RUN transition during a TIA Portal download

The most operationally disruptive trigger is a STOP → RUN transition triggered by a software download. The CM PtP module reinitializes its serial port after STOP → RUN, but the Receive_P2P instance DB retains the previous sequence counter. The first call after RUN with the stale counter is rejected as 16#81E7. Subsequent calls stay in 16#7002 because the firmware will not re-arm the receive pipeline with a counter it has already passed. A re-seat of the module (or a CPU restart) reinitializes both sides and clears the fault.

This is the scenario reported in the field where the error appears "after a few downloads" and the only recovery is to pull the module.

4.4 OB priority and interrupt preemption

When a higher-priority OB (for example OB82 diagnostic interrupt, OB121 programming error, or in a safety CPU the OB35 / OB121 safety organization blocks) preempts OB1 while a Receive_P2P call is in the 16#7001 first-call state, the firmware keeps the state machine open. If the higher-priority OB takes longer than the configured receive timeout, the firmware returns the job to the user with an internal timeout. On the next OB1 scan Receive_P2P is reissued but the firmware has already torn the job down, producing 16#81E7. This is particularly visible on safety CPUs (1516F-3, 1517F-3) where the F-runtime runs in parallel with the standard program.

5. Diagnostic Procedure

1. Capture STATUS history. Add a circular buffer (for example DB_RecvLog with 64 DWORD entries) and write STATUS with a rising-edge trigger on ERROR or on any transition. This provides the sequence of intermediate states leading to the 16#81E7 event.
2. Cross-reference Receive_P2P call sites. In TIA Portal, right-click the Receive_P2P instruction and select "Go to cross-references". Confirm that exactly one call site exists in the project, and that the call site is the same instance DB referenced by the LADDR (hardware identifier of the CM PtP).
3. Confirm hardware identifier. Open the device configuration, click the CM PtP, and note the system constants (for example CM_PtP_1_HS). Cross-check that every Receive_P2P call uses this exact identifier and not a separate constant generated for a sibling slot.
4. Inspect the diagnostic buffer. Open Online → Diagnostic buffer for the ET 200SP station. Look for "Synchronization error" entries with associated timestamp. The 1-second precision allows correlation with download events or OB82 entries.
5. Read the module information. Online → Online & Diagnostics → CM PtP → Port diagnostics. Note the "Receive queue depth" and "Error counter" values. A non-zero error counter that grows on every poll confirms the firmware-side desync.
6. Trigger a controlled test. Use a serial port sniffer (for example a USB-to-RS485 tap with Wireshark + the s7comm dissector) to verify that the reader is actually transmitting and that the bytes are not being dropped by the physical layer. This rules out a cable/grounding problem masquerading as a synchronization error.

6. Solutions

6.1 Eliminate duplicate Receive_P2P instances

Use a single Receive_P2P instance DB and call it from one location, typically OB1. If your application requires gated receive (for example, only enable while a state machine is in RUNNING), drive the EN input from the state machine rather than reissuing from a second block. The Receive_P2P (Enable receive messages) reference describes the recommended pattern: enable the block once, let the firmware buffer pending data, and read the result into a separate data block.

6.2 Sequence send and receive on the same module

For half-duplex protocols (RS-485 Modbus RTU, 3964R) drive Send_P2P and Receive_P2P from a state machine that issues a receive immediately after each successful send. Insert a Receive_Config call only at startup, never on every cycle, because Receive_Config deletes any data already buffered in the CM.

6.3 Reinitialize the receive pipeline after STOP → RUN

Add a one-shot in OB100 (startup) that calls Receive_Config to re-arm the port. In OB1, gate the Receive_P2P call on a bit that is set true only after OB100 has completed. The pattern in pseudocode:

// OB100 - Startup
"DB_Init".CfgDone := FALSE;
"Receive_Config_Instance"(LADDR := "CM_PtP_1_HS",
                           start_condition := RCVSTART_ANY_CHAR,
                           end_condition   := RCVEND_FIXED_LENGTH,
                           length          := 16);
"DB_Init".CfgDone := TRUE;

// OB1 - Main
IF "DB_Init".CfgDone THEN
    "Receive_P2P_Instance"(REQ    := FALSE,
                            LADDR  := "CM_PtP_1_HS",
                            DONE   => "DB_Recv".Done,
                            ERROR  => "DB_Recv".Error,
                            STATUS => "DB_Recv".Status,
                            RDATA  => "DB_Recv".Buffer);
END_IF;

6.4 Handle the 16#81E7 status and recover automatically

Implement a watchdog that detects a stuck 16#7002 for longer than the receive timeout (for example, 5 s for a Modbus RTU transaction at 9600 baud). On detection, call Receive_Config to clear the CM buffer, then re-enable Receive_P2P. The fence prevents the CM from being stuck in a half-state without requiring physical intervention:

// Watchdog - call from a cyclic OB (e.g. OB35, 100 ms)
"DB_Watch".StallTimer(IN := "DB_Recv".Status = 16#7002,
                       PT := T#5s);
IF "DB_Watch".StallTimer.Q THEN
    // Force reconfiguration of the port
    "Receive_Config_Instance"(LADDR := "CM_PtP_1_HS",
                               start_condition := RCVSTART_ANY_CHAR,
                               end_condition   := RCVEND_FIXED_LENGTH,
                               length          := 16);
    "DB_Recv".Status := 16#0000;
    "DB_Watch".StallTimer(IN := FALSE);
END_IF;

6.5 Update firmware

Confirm the CM PtP firmware against the latest released version on the Siemens support portal. The "Synchronization error" event has been addressed in successive firmware revisions for both 6ES7137-6AA00-0BA0 (the long-running standard CM PtP) and 6ES7137-6BD00-0BA0 (the full-featured variant). After the firmware update, perform a STOP → RUN → MRES cycle to clear the internal counter table.

7. Verification

1. Run the line under load for 72 hours with no operator intervention. The receive pipeline should never transition out of 16#0000 or 16#7002 for more than the expected transaction time.
2. Trigger a TIA Portal SW download that forces a STOP → RUN transition. Confirm that the receive pipeline recovers automatically within one cycle of OB100 + OB1.
3. Inject a deliberate second Receive_P2P call (for example, an FC80 enabled from a watch table) and verify that the diagnostic buffer records the synchronization error exactly once and that the recovery code resets the state.
4. Compare the receive packet count from the reader's own diagnostic counter with the count in the PLC receive DB. Drift of more than 2 % over 24 hours indicates dropped frames and warrants re-checking the cable and termination.

8. Best Practices for Long-Term Stability

• One instance DB per CM PtP per direction. There is no performance gain in spawning multiple Receive_P2P instances, and it is the single largest source of 16#81E7 events.
• Keep Receive_Config in OB100 only. Re-issuing it on every cycle deletes the pending receive buffer and can cause a race with the firmware.
• Match the receive timeout to the slowest expected transaction. For Modbus RTU at 9600 baud with 16-byte payloads, set the receive timeout to at least 50 ms to absorb jitter on the master side.
• Disable the performance optimization option (UNIVERSAL = 1) unless the application specifically requires it. Per the TIA Portal error messages reference, the performance option reduces the supported number of received characters, which can itself raise a different error code when a Modbus response with a long payload is received.
• Use a separate IM 155-6 interface module for the CM PtP station rather than chaining on a heavily loaded ET 200SP that hosts digital and analog I/O. PROFINET jitter under heavy cyclic load has been observed to correlate with desync events.
• Add a status monitoring DB that exposes STATUS, ERROR, and the diagnostic buffer count to the HMI, so operators see a frozen module long before they lose data.

9. Troubleshooting Matrix

10. Related Siemens Documentation

• SIMATIC S7-1500 / ET 200MP / ET 200SP CM PtP function manual (PDF)
• Receive_P2P: Receiving data (S7-1200, S7-1500)
• Receive_Config: Configure PtP recipient
• Error messages (S7-1200, S7-1500)
• Receive_P2P (Enable receive messages)

FAQ