Restarting Siemens CP1242-7 GPRS Modem from S7-1200 CPU

Problem Statement: Can the CP 1242-7 Be Reset from the S7-1200 CPU?

The Siemens CP 1242-7 GPRS communications processor does not expose a discrete "reboot," "warm restart," or "cold restart" instruction in the STEP 7 Basic / TIA Portal instruction set. A field engineer who needs to clear a stalled SMS receive buffer, refresh the GPRS PDP context, recover a frozen GSM stack, or simply re-arm a CP that has stopped acknowledging incoming SMS messages cannot issue a CPU-side command that toggles the CP's internal power or reloads its firmware in a single deterministic step. A physical power cycle of the S7-1200 rack is the only fully deterministic CP restart, and it carries the well-known side effect of dropping the CPU into STOP and then back to RUN, which in turn interrupts every I/O and process on the station. The objective of this reference is to document the software-side levers that exist, the limitations of each, and the controlled workaround procedure that lets a CPU program influence CP state without forcing a full power cycle.

The starting assumption is an S7-1200 CPU (any 12xx family from CPU 1211C through CPU 1217C) running TIA Portal V15.1 or later, with a CP 1242-7 plugged in the left communications bus, a TCSB (Telecontrol Server Basic) or stand-alone SMS project, and a failure mode in which incoming SMS messages stop being delivered to TC_RECV or the buffer between CP and CPU grows without being drained.

CP 1242-7 Hardware, Catalog Numbers, and Firmware

The CP 1242-7 family is the GPRS communications processor for the S7-1200. The two catalog numbers you will encounter in the field are listed below; the firmware behaves identically for the purposes of software-controlled recovery, but the V2 variant is the variant Siemens has shipped since 2014 and is the one referenced in the most recent documentation.

Both variants plug into the left bus of an S7-1200 CPU (logical slot 101) and are configured under "Devices & Networks" in TIA Portal. The CP runs an internal RTOS that handles the GSM/GPRS stack, the SMS PDU parser, the telecontrol protocol driver, and the buffer memory used to stage messages between the GPRS bearer and the CPU's process image. Recovery operations that originate in the CPU are limited to writing parameter records through the standard S7-1200 data record mailbox; they do not map to RTOS-level control primitives.

Reference: CP 1242-7 operating instructions (BA_CP-1242-7_76_en-US) and the V2 manual CP 1242-7 GPRS V2 (BA_CP-1242-7-V2_76).

Why a Native Software Restart Does Not Exist

The S7-1200 system architecture reserves the CP slot as a peripheral device controlled by the CPU. The CPU owns configuration, parameter records, and the data record mailbox. There is no system function block (SFB), no system function (SFC), and no TIA Portal extended instruction in the S7-1200 instruction set that maps to a CP "warm restart" or "cold restart" in the way that, for example, the SFC 100 "SET_CPU_RST" or the distributed I/O LineDrop mechanisms are used on a PROFINET device. The CP behaves like a SIMATIC NET module: it accepts a parameter set at startup, runs continuously, and accepts write data records during operation for parameter changes only.

What the CP does support is parameter-record writes. The TeleControl library wraps those writes in instructions that the CPU can call from a cyclic OB or from a watchdog block. Those instructions are the only software surface available to influence CP state, and they are the focus of the rest of this article.

Software-Initiated Recovery Options That Do Exist

The TeleControl instruction library is installed as part of the "Telecontrol" option in TIA Portal and exposes five CPU-side instructions relevant to CP state recovery. The library version is tied to the TIA Portal version; a V15.1 installation installs TeleControl instruction library V15.1 (or the higher-numbered package that ships with the update).

Of these, TC_CONFIG and TC_CONF are the two that produce a measurable change in CP behavior. TC_SEND is useful as a wake-up probe; TC_RECV and TC_CON are diagnostic.

TC_CONFIG: Re-Pushing the Full Configuration

TC_CONFIG is the closest equivalent to a software reset. It is documented in the TeleControl library help and the CP 1242-7 manual as the instruction that writes the configured parameter set (the block built in "CP 1242-7 properties > Telecontrol" or "CP 1242-7 properties > SMS") back to the CP at runtime. The CP, on receipt of this write, re-initializes its connection state machine, tears down the active PDP context if one is open, and re-establishes the bearer with the APN defined in the engineering. From the CPU's perspective the call returns after the data record has been acknowledged; the CP-side work continues asynchronously for 30 s to 90 s depending on GSM registration and PDP latency.

Typical call signature in SCL:

// Trigger a TC_CONFIG re-push
TC_CONFIG_DB.DBX0.0  := TRUE;      // REQ edge
TC_CONFIG_DB.REQ     := TRUE;
TC_CONFIG_DB.LADDR    := 256;       // HW identifier of the CP slot
TC_CONFIG_DB.DONE    := ;
TC_CONFIG_DB.ERROR   := ;
TC_CONFIG_DB.STATUS  := ;
TC_CONFIG_DB.CONFIG  := W#16#0000; // 0 = full configuration block

Key status codes for TC_CONFIG.STATUS:

Call TC_CONFIG only when TC_CON shows the CP idle, and debounce the request edge to once per 60 seconds minimum. Re-pushing faster than the CP can apply the parameter set generates 80C3 and has no benefit.

TC_CONF: Re-Sending the SMS Configuration Block

TC_CONF is the more targeted lever. It rewrites the SMS settings block specifically: the authorized sender MSISDN list, the SMSC address, the GSM character set, and the gateway mapping. When the CP's SMS receive buffer becomes stuck after a GPRS outage, TC_CONF often clears the deadlock without the 60 s to 90 s PDP tear-down that TC_CONFIG imposes. From the field this looks like incoming SMS that were queued for hours (visible in the CP's internal diagnostic buffer) being delivered to TC_RECV within seconds of the TC_CONF acknowledgment.

Typical call signature in SCL:

// Trigger a TC_CONF re-push (SMS block)
TC_CONF_DB.REQ    := TRUE;
TC_CONF_DB.LADDR   := 256;        // HW identifier of the CP slot
TC_CONF_DB.SUB     := 1;          // 1 = SMS configuration sub-block
TC_CONF_DB.DONE    := ;
TC_CONF_DB.ERROR   := ;
TC_CONF_DB.STATUS  := ;

The SUB input selects the configuration sub-block: 1 for SMS, 2 for the email/SMTP gateway block (CP 1242-7 V2 only), 3 for the dynamic DNS update block. Use SUB := 1 for the symptom described in the field report.

Diagnosing the SMS Buffer Symptom

The buffer symptom manifests as: the CP's incoming SMS queue holds messages even after they have been processed by the CPU, subsequent SMS receive events are delayed by the queued messages, the CP's status display shows traffic on the GSM link but no new TC_RECV pulses, and the TCSB database on the central side shows long delivery latencies that go away after a power cycle at the station.

To confirm the diagnosis from the CPU side, monitor the following tags in a watch table:

If TC_RECV.STATUS = W#16#8001 the CP is reporting a resource error on the receive side, which is the classic fingerprint of the buffer-stall condition. TC_CONF followed by TC_CONFIG clears this in roughly 80 % of cases that are not related to an outright GSM registration failure.

TCSB and SET 32 Configuration Context

"SET 30," "SET 32," and similar identifiers refer to the configuration profile that TIA Portal generates under "CP 1242-7 > Telecontrol > Server connection." SET 32 specifically targets the TCSB (Telecontrol Server Basic) topology with SMS as the secondary bearer or as the primary bearer for alarm forwarding. The TCSB software package (article number 6GK1700-0AA00-0AA0 for the base license) is what consumes the SMS and frames the data for the central SCADA. The SET identifier is largely a UI label inside the engineering; it does not change the recovery procedure. What does matter is the partner list under "CP 1242-7 > SMS > Authorized senders" and the SMSC entry, which is the exact block TC_CONF rewrites.

For projects that use TCSB with WinCC Runtime Advanced as the central visualization, also verify that the TCSB polling interval is set to 60 s or longer. A sub-30 s polling interval combined with a weak GPRS link is the most common trigger for the buffer-stall symptom.

Recommended Workaround Procedure

The following procedure runs from a CPU block (for example, a one-shot that fires from a watchdog tag or from an HMI button) and is the deterministic software-side recovery path:

1. Read TC_CON.STATUS and TC_RECV.STATUS into a watch table. If either is non-zero, log the value with a timestamp.
2. Set the REQ edge on the TC_CONF instance with SUB := 1. Wait for DONE = TRUE or ERROR = TRUE.
3. Wait 10 s. If the symptom persists, set the REQ edge on the TC_CONFIG instance with CONFIG := W#16#0000. Wait for DONE = TRUE or ERROR = TRUE.
4. Wait 60 s. During this interval the CP tears down any active PDP context, re-registers on the GSM network, re-opens the PDP context, and re-applies the SMS partner list.
5. Re-check TC_CON.STATUS and TC_RECV.STATUS. If both are healthy, the recovery succeeded.
6. If the symptom persists after one full TC_CONF + TC_CONFIG cycle, the failure is GSM-side (antenna, SIM, APN, or coverage). Schedule a controlled S7-1200 power cycle by opening the disconnect on the rack's 24 V supply for at least 30 s.

Verification Checklist

After running the procedure, confirm the following before declaring the recovery complete:

• CP STATUS LED is solid green, not flashing.
• CP "Online & Diagnostics > Mobile wireless > Signal quality" reports a value in the green band (typically -85 dBm or better).
• TC_CON.STATUS is W#16#0000 or W#16#7000.
• TC_RECV.NDR pulses within one polling interval after a test SMS is sent to the station's MSISDN.
• TIA Portal "Online & Diagnostics > CP 1242-7 > Buffer" shows 0 pending messages.
• TIA Portal "Online & Diagnostics > CP 1242-7 > Time" updates within 30 s (NTP/operator time synchronization is a good CP liveness probe).

Troubleshooting Matrix

Engineering Notes and Field-Proven Caveats

A few constraints that the field report surfaces, and that field engineers have reported consistently across deployments:

• The TC_CONFIG parameter-record write is the only CPU-side write that reaches the CP's parameter layer. There is no instruction that maps to a CP firmware reload.
• Calling TC_CONFIG faster than once per 60 s saturates the CP's write mailbox and produces 80C3. Debounce accordingly.
• Cutting 24 V on the CP terminals only works when the CP is fed separately from the CPU, which is not the default wiring. In a default S7-1200 rack the CP and the CPU share the same L+/M terminals, so the "cut CP power" workaround puts the whole station into STOP.
• The "buffer stays full after interruption" symptom is a known behavior of early CP 1242-7 V1 firmware; upgrading to V2 firmware (HSP-compatible) reduces the frequency but does not eliminate it, which is why TC_CONF + TC_CONFIG remains a useful routine.
• For stations that use the "TS Gateway" route to TeleService (no central TCSB), the same recovery procedure applies; the TS Gateway polling interval is the variable to watch on the central side.

FAQ