S7-1500 1517F Display Stuck on Connecting: Firmware Fix

Problem Statement

On Siemens SIMATIC S7-1500 CPUs of the types CPU 1515(F), CPU 1516(F), CPU 1517(F), and CPU 1518(F), an intermittent fault has been observed in which the CPU LED indicators behave normally (the green RUN LED is steady, the yellow MAINT LED may be off, and the red ERROR LED is not lit), while the integrated display of the CPU remains frozen on the splash screen with the message "Connecting".

During the fault window the following operational symptoms are present:

• The CPU continues executing the user program (RUN is genuine, not just LED-driven).
• Online connection to the CPU from TIA Portal is not possible; the engineering station reports a timeout when going online.
• Put/Get communication with S7 partners on PROFINET/Industrial Ethernet is interrupted or returns timeouts.
• No diagnostic buffer entry is generated for the display hang itself; the CPU firmware is unaware that the display service has stalled.
• A power cycle (off/on) of the CPU restores normal display and communication.

Because no diagnostic buffer entry is written, the issue is invisible to standard S7-1500 online diagnostics. The fault lies inside the display controller firmware, not in the CPU runtime, which is why the CPU itself logs nothing.

Affected Hardware and Order Numbers

The behavior has been confirmed on the F-variant and non-F variants of the high-end S7-1500 family. The following MLFB (order) numbers are in scope of the Siemens firmware update entry that addresses this issue:

Symptom Matrix: LED, Display, and Communication

The following matrix distinguishes a true CPU stop from the display-controller hang. It is the primary field triage tool when a maintainer is called for a "CPU won't go online" ticket but the LEDs appear healthy.

The defining fingerprint is the combination RUN LED on + display stuck on Connecting + no diagnostic event + online/put-get blocked. Any other combination points to a different root cause (firmware mismatch, PROFINET failure, hardware defect on the display connector, etc.).

Root Cause

The display on the high-end S7-1500 CPUs is a separate subsystem with its own microcontroller and firmware image. The CPU communicates with the display over an internal serial interface using a small management protocol that carries menu state, IP parameters, project name, diagnostic texts, and operator input events.

The hang is caused by a defect in the display controller firmware in which the management protocol state machine can deadlock during reconnection attempts, especially after:

• Rapid topology changes on PROFINET that trigger IP/DHCP renegotiation while the display is drawing parameter pages.
• CPU time synchronization (NTP) updates that refresh display-time elements.
• Loss and recovery of the engineering connection on the PROFINET interface.
• Power-up with the operator buttons held, which places the display in service mode and then fails to exit cleanly.

When the display controller deadlocks, the management channel used for online functions and Put/Get pass-through is also blocked, even though the application scan on the CPU continues. The CPU runtime does not raise a diagnostic event because, from its perspective, the user program and the PROFINET stack are healthy. This is why the diagnostic buffer remains empty.

Immediate Field Recovery (Power Cycle)

When the fault is observed in production, the only safe immediate recovery is a CPU power cycle. Use the following sequence to avoid corruption of retained tags and to keep motion/axes in a defined state:

1. Notify the operator and place the controlled process in a safe state (idle, hold, or local mode per the application).
2. Confirm that disconnecting the CPU will not cause an unsafe process transition. If the process requires continuous control, do not power-cycle without an approved bypass.
3. Document the time of the event and the current operator menu / IP visible on the display (it will read Connecting).
4. Open the breaker or remove the 24 V supply from the system power module (PM).
5. Wait at least 5 seconds with all LEDs dark to allow the CPU's internal capacitors to discharge and the display controller to fully reset.
6. Re-apply 24 V. The CPU performs a warm restart (RUN), and the display should boot through Connecting to the normal menu within 30 to 60 seconds.
7. Verify online access from TIA Portal and a Put/Get ping from a known S7 client before restoring the process.

Permanent Resolution: Display Firmware Update

Siemens publishes a dedicated firmware update package for the display controllers of the 1515(F), 1516(F), 1517(F), and 1518(F) CPUs. The update is delivered as a discrete .upd / .bin image intended for the Siemens support entry:

Firmware Update for the Displays of CPUs 1515(F)/1516(F)/1517(F)/1518(F) - Siemens Industry Online Support

Read the release notes shipped with the package before flashing. The release notes specify:

• The exact CPU MLFBs covered by the update.
• The minimum required TIA Portal version for the update tool.
• Whether the update is online (via the CPU's PROFINET interface) or requires the SIMATIC Memory Card path.
• Whether the CPU firmware must be at a specific minimum version before the display update is accepted.

Step-by-Step Display Firmware Update via TIA Portal

The standard path is through the TIA Portal "Online & Diagnostics" view, using the CPU's PROFINET interface. Where the display is locked and online access is impossible, the SIMATIC Memory Card path is used as a fallback.

Path A - Online Update (Preferred)

1. Open the project containing the CPU in TIA Portal. Use at least the TIA Portal version specified in the Siemens entry.
2. Right-click the target CPU in the project tree and choose Online & Diagnostics.
3. Select the PROFINET interface that is reachable from the engineering station. Confirm that the interface address matches what is shown on the CPU display (after a power cycle).
4. Go to Diagnostics > Firmware Update (or the equivalent "Display Firmware" node on supported TIA versions).
5. Browse to the downloaded display firmware file (typically a .upd).
6. Select the display controller as the target (not the CPU itself). The TIA tool will warn if the file does not match the connected display hardware.
7. Click Execute Update. The CPU display will show a progress bar; the CPU continues to run during the update. Do not power-cycle the CPU during the update.
8. When the update reports Update successful, the display automatically reboots and the Connecting splash clears.
9. Cross-check the new display firmware version under Diagnostics > Information / Identification.

Path B - Update via SIMATIC Memory Card (Fallback)

Use this path only if the CPU is unreachable online or the engineering station is offline. It requires a SIMATIC Memory Card of at least 2 GB with the S7-1500 file system.

1. Power down the CPU and remove the SIMATIC Memory Card.
2. Place the display firmware package in the FWUPDATE directory on the card using a card reader. The Siemens release notes document the exact file naming convention.
3. Re-insert the card into the CPU and apply power.
4. The CPU firmware detects the pending display update and flashes the display controller automatically during startup. The display will show a progress bar.
5. When the CPU finishes startup, remove power once more, eject the card, and restore the original project card if a separate one is used.
6. Re-apply power and verify the display version in the CPU's identification data.

Verification

After the update, perform the following checks to confirm the fix is in place:

1. Display boot: With CPU in RUN, the display must reach the top-level menu within 60 seconds of power-up, not remain on Connecting.
2. TIA online: From the engineering station, perform a "Go online" to the CPU. Expect successful online handshake within the standard timeout.
3. Put/Get: From a known S7 client (for example, an HMI panel or a custom OPC UA/Modbus gateway that reads S7 data), perform a read on a configured Put/Get tag. Expect a valid value within 500 ms.
4. Stress test: Trigger a PROFINET topology change (re-plug a PROFINET device) and verify that the display does not deadlock and that online remains available.
5. Button test: Use the operator buttons to navigate the display menus. The display should respond within one second per button press.

Record the display firmware version, the TIA Portal version, and the project version in the device's maintenance log for future reference.

Diagnostic Buffer and Event Log Considerations

Because the display controller is a peer of the CPU runtime and not a sub-component of it, a deadlock in the display does not generate a CPU diagnostic buffer entry. Do not interpret a clean diagnostic buffer as evidence that the controller is healthy. The opposite is true for this specific issue: a clean buffer combined with a hung display is the diagnostic signature.

For applications that require a permanent record of the event, the recommended approach is to monitor the PROFINET/TCP connection state of the engineering PC and the Put/Get clients using an external SCADA or a small script that logs connection drops. This gives the maintenance team a timeline that the CPU itself does not produce.

Implications for Put/Get and Open User Communication

Put/Get, S7 communication, and open user communication (OUC) on the S7-1500 are processed by the CPU's PROFINET stack and are not executed on the display. The reason they appear interrupted during the display hang is that the CPU's online and HMI services share internal buffers with the display service during the deadlock window. Once the display controller is updated, this shared path is stable and Put/Get latency returns to the application's expected baseline.

If Put/Get drops are observed only during a display hang, do not change the application's Put/Get protection settings (for example, the access password or the "Permit access with Put/Get" toggle in the CPU properties). Doing so masks the symptom and weakens the security configuration. Apply the display firmware update instead.

Preventive Maintenance Recommendations

• Include the display firmware version in the asset list for every S7-1500 high-end CPU. Track it in the same CMMS record as the CPU firmware version.
• When a CPU is replaced under warranty or as a spare, verify that the pre-installed display firmware is at or above the version listed in the Siemens entry. New units in 2022 and later typically ship with the corrected image, but pre-owned stock may not.
• Schedule a rolling update of display firmware across the fleet during the next planned outage per machine. Coordinate with the controls vendor to validate the new image against any custom menu scripts (the SIMATIC S7-1500 display supports user-defined menus and diagnostic screens).
• Avoid pressing operator buttons during CPU power-up. Boot the CPU, wait for the menu, then operate. This reduces the chance of triggering the deadlock path.

Field Engineering Notes

The fault rate reported in the field is low (typically observed once every several months of continuous operation per affected site), which is exactly why it is hard to reproduce in a lab and why a permanent fix via firmware is the right answer. Power-cycling works every time but should be treated as a workaround, not a fix, for the reasons given above.

For a control cabinet that cannot tolerate a power cycle (for example, a process line with no local HMI and remote engineering only), add a small remote reset relay to the system power module's 24 V input that can be latched from the SCADA. This gives the operator a controlled way to recover from a display hang without dispatching a technician to the cabinet.

For sites with multiple identical machines, label the CPU MLFB and current display firmware version on a sticker on the inside of the cabinet door. This avoids guesswork at the next maintenance window and helps when ordering the correct firmware package.

Quick Diagnostic Decision Flow

The following inline SVG summarizes the on-site decision flow when a maintainer is called for a "CPU will not connect" issue on a 1515(F)/1516(F)/1517(F)/1518(F):

Related S7-1500 Display and HMI Topics

The following are related but distinct issues that share the symptom "display not responsive" and should not be confused with the firmware hang described here:

• CPU display shows a language-specific error text after a firmware update - usually a sign that the CPU firmware image is incomplete or corrupted; requires re-flashing of the CPU firmware, not the display.
• Display backlight is dim or off on 1518(F) - hardware defect; the display must be replaced. CPU continues to run normally.
• Display loops on the splash screen continuously after a power-up - a separate firmware corruption case, addressed by a CPU firmware update rather than the display update.
• Display shows the correct menu but operator buttons do not respond - button-pad failure or flex-cable issue; requires hardware repair.