S7-400H CPU 416-5H Firmware Update via CP 443-1 PROFINET

This article documents the engineering procedure for executing OS firmware updates and downgrades on a SIMATIC S7-400H automation system centered on the CPU 416-5H (article 6ES7 416-5HS06-0AB0, firmware 6.0.3). The update path is an Ethernet/PROFINET connection from the engineering station through the CP 443-1 communications processor to the central rack and to distributed ET 200M stations. All work is performed offline, with the process in a safe state, the CPU in STOP, and no live switchover from a reserve CPU.

The questions that drive this procedure come up on most S7-400H retrofit projects: whether the engineering station can reach every module from a single CP 443-1 path, whether the CPU will prompt for a memory reset, what the STEP 7 project file actually contains, and how to handle an EEPROM memory card loaded with old programming. The S7-400H adds two more concerns: the linkup of the partner CPU after a firmware change, and the requirement that both CPUs be at the same firmware level before a redundant runtime is resumed.

System Architecture and Module Reachability

The update path described here is: engineering station → Industrial Ethernet → CP 443-1 (in the central rack) → S7-400 backplane → CPU 416-5H, and (for distributed I/O) engineering station → Industrial Ethernet → CP 443-1 → PROFINET/Industrial Ethernet → ET 200M IM 153-x.

Reachability from the CP 443-1 path is module-dependent. The CPU is reachable through the backplane; the ET 200M is reachable through the CP 443-1's PROFINET/Industrial Ethernet subnet. Any module that participates in a separate subnet (for example, an ET 200S on PROFIBUS via a CP 443-5, or an HMI panel on MPI) is not reachable from the Ethernet path and must be updated through its own gateway.

Prerequisites and Pre-Update Planning

Before the online system is touched, the following prerequisites must be in place. The order of the list is the order in which the items should be addressed during the planning phase.

Pre-Update Data Capture

1. Open the STEP 7 project, go to Online > Accessible Nodes, and confirm that both CPUs (for H-systems) or the single CPU are reachable.
2. From PLC > Diagnostic/Setting > Diagnostic Buffer, save the diagnostic buffer of every CPU to a text file. This is the baseline for post-update comparison.
3. From PLC > Module Information, capture the article number and firmware version of every module in the rack and in every distributed station. In particular, capture SZL 0x0000 (module identification) for every slot. The firmware version is shown in the "Module Identification" tab as the "Firmware" field.
4. From PLC > Module Information > Diagnostic Buffer, record the most recent SZL 0x0019 events (operating-mode transitions, faults, communications errors). These should be empty or "informational" before the update; any "incoming fault" should be resolved before the update.
5. Confirm the current CPU operating mode (RUN, RUN-Redundant, or STOP) and the partner CPU's status. For an H-system, record whether the system is in "synchronized" mode or "system-modified" mode.
6. From NetPro, save a screenshot of the configured S7 connections. This is the baseline for post-update verification of connection establishment.

STEP 7 Project Contents and Re-Download Semantics

The STEP 7 project file contains the complete configuration required to re-build the system from scratch. The contents are not all of the same kind, and understanding what is in the project is important for understanding what happens when the project is re-downloaded.

If the CPUs lose their configuration (e.g., a memory reset, a defective RAM, a replacement CPU), downloading the project to the CPU restores the entire configuration. The CPU does not have to be the "original" article; a replacement CPU of the same article number with a different firmware level can be brought to the same level through a firmware update and then loaded with the project.

Important: the S7 project file contains the program in compiled form, but the compiled code is firmware-version specific. After a firmware update, the project should be re-compiled in STEP 7 to match the new firmware. If the new firmware requires a re-compile, the runtime will reject the old compiled blocks and report "incompatible block" errors in the diagnostic buffer (event ID 0x13B1 / 0x39B1 in the SZL 0x0019). To force a re-compile: Program > Compile All (Resetting Symbol Table) in SIMATIC Manager, or in HW Config: Station > Check Consistency followed by Station > Save and Compile.

Memory Reset Behavior After Firmware Update

The S7-400 CPU does not automatically prompt the user for a memory reset when a firmware update completes successfully. The user program and configuration in work memory are preserved across the firmware update. This is a key behavioral difference from the S7-1500, where a firmware update triggers a STOP and a fresh download of the user program is recommended.

However, the diagnostic buffer is cleared and the run-time counters are reset as part of the restart that follows the firmware update. The SZL contents are re-built on the next startup. The following must be observed:

• The CPU performs an automatic restart (warm restart) after a successful firmware update. This includes re-initialization of the system data blocks (SDBs) and the runtime system.
• The user program in work memory is retained, but any blocks that are firmware-version dependent (e.g., new SFCs, SFBs, or system blocks that come with the firmware) need to be re-loaded by the project after the update. The firmware update only replaces the firmware, not the user project.
• If a "factory reset" was performed before the firmware update, the CPU is empty after the update and the project must be downloaded to it.
• The CPU operating-mode selector is not required to be in STOP for the firmware update to start; STEP 7 will bring the CPU to STOP automatically. The selector must not be locked in RUN or set to RUN-P (run-programmable).
• If the update fails (e.g., power interruption, network interruption, mismatched .upd file), the CPU remains in STOP with the old firmware. The diagnostic buffer will contain an event with "Firmware update aborted" and a hex error code; the .upd file must be re-loaded and the update re-attempted.

For an S7-1500 CPU the situation is different: the CPU goes to STOP immediately when the update starts, and a memory reset is performed automatically at the end of the update. This is documented in the TIA Portal help. S7-400 behavior should not be assumed from S7-1500 documentation.

Memory Card (EEPROM) Handling Procedure

The S7-400 CPU has a slot for a memory card that can hold the project. Two card types are common: the Flash EPROM card (FEPROM, persistent) and the RAM card (volatile, battery-backed). The card slot is the same physical slot for both; the CPU detects the type at startup.

If the card is left in the CPU during a memory reset and the card has an old program, the CPU will auto-load that program from the card on the next startup, undoing the intended clean state. The auto-load behavior is controlled by the mode selector position and by the card's content:

• If the card is empty, the CPU starts with the work-memory contents (typically empty after a memory reset).
• If the card has a project, the CPU auto-loads the project from the card on the next startup, regardless of the work-memory contents.
• If the card has a project that is newer than the work memory (different timestamp), the work memory is overwritten with the card's project.

The procedure to avoid an unintended auto-load during a firmware update:

1. Take the CPU to STOP.
2. Remove the memory card from the CPU. Label the card with its content and last-known project revision.
3. Perform the memory reset (MRES) sequence: turn the mode selector to MRES → position the selector back to STOP within a defined time window → the STOP LED blinks slowly to request the reset → return the selector to MRES → the STOP LED blinks rapidly to confirm. The exact timing of the selector transitions is documented in the CPU manual; a too-slow transition will cancel the reset.
4. With the card still removed, verify the CPU is empty (STOP LED steady on, all other LEDs off except POWER; the MRES LED has gone off after the reset).
5. At this point, decide whether to:
   1. Re-insert the card and re-program it (target = memory card),
   2. Insert an empty/formatted card and program it from the project, or
   3. Leave the card out and operate the CPU from work memory only.

To format an S7 memory card in STEP 7: right-click the CPU in the project tree (or in Accessible Nodes) → Memory Card → Format. This is required if the card came from another system, has an old program, or the file system is corrupt. The format operation is fast (a few seconds for a 2 MB card, longer for larger cards).

If the goal is to prevent the auto-load of an old program during a power-cycle while the new program is being commissioned, the card should be removed entirely until the work-memory state is verified. The CPU will then start with the work-memory contents (the freshly downloaded project) and will not be tempted to load a stale project from a card.

H-System Linkup and Reserve CPU Considerations

The S7-400H system is fault-tolerant: two CPU 416-5H modules run in lock-step, with one designated as master and the other as standby. The two CPUs are connected by fiber-optic sync cables (sync modules 6ES7 960-1AA04-0XA0 or 6ES7 960-1AB04-0XA0) and exchange process data, diagnostic data, and time stamps continuously. The redundant backplane is typically a UR2-H rack (6ES7 400-1JA01-0AA0) with two slots for the CPUs and a shared slot for the H-sync modules.

When one CPU is updated or reloaded, the following sequence occurs:

1. The updated CPU restarts (warm restart) and tries to link up with the partner.
2. The partner CPU can be in RUN, RUN-Redundant, or STOP, depending on the H-system state.
3. If both CPUs are on the same firmware version, the linkup sequence runs to completion and the system returns to RUN-Redundant (both CPUs in RUN, with one as master and one as standby).
4. If the partner CPU is on a different firmware version, the linkup fails and the partner CPU reports a "Firmware version mismatch" event in the diagnostic buffer. The system drops to single-mode (only one CPU is in RUN, the other is in STOP or "system-modified" mode).

This has two operational consequences for the firmware update procedure:

1. Both CPUs must be updated in the same maintenance window if a firmware change is intended. The procedure is: take both CPUs to STOP → update CPU 0 → update CPU 1 → reload the project to both (or just one and copy via the sync link) → switch back to RUN-Redundant. The linkup is initiated automatically when both CPUs are in STOP and then both transition to RUN.
2. A replacement CPU in the rack with a different (older) firmware will not link up automatically. The replacement CPU's firmware must be brought to the same level as the partner before the linkup is initiated, or the new CPU will be reported as a "non-redundant" partner and the system will refuse to enter RUN-Redundant.

If the procedure in the original question (reload a single CPU and let the partner link up) is followed, the operator must verify that the partner CPU's firmware is at the same level. If it is not, the linkup will be refused and the engineering workstation will see one CPU in STOP and the other in RUN, with no redundancy. The H-system will report "system-modified" mode in the diagnostic buffer of both CPUs.

The full procedure for an H-system firmware update is in the SIMATIC S7-400H Fault-Tolerant Systems manual, in the section on "Firmware update of the CPUs in a fault-tolerant system." The recommended practice is to contact Siemens Support for a consultation if the firmware change crosses a major release boundary (e.g., from V4.x to V6.x) or if the system is in a safety application (F-CPU).

H-System Operating Modes Relevant to Firmware Update

Step-by-Step Firmware Update Procedure

The procedure below assumes the process is in a safe state, the STEP 7 project is backed up, and the firmware .upd files are present on the engineering station.

Step 1: Document Current State

1. In SIMATIC Manager, open the project, go to Online > Accessible Nodes, and confirm that both CPUs (or the single CPU for non-H systems) are reachable.
2. From PLC > Diagnostic/Setting > Diagnostic Buffer, save the diagnostic buffer to a text file.
3. From PLC > Module Information, capture the article number and firmware version of every module in the rack and in every distributed station (SZL 0x0000, index 0).

Step 2: Resolve the Memory Card State

1. Take the CPU to STOP (mode selector to STOP, or via PLC > Operating Mode > STOP).
2. Remove any memory card from the CPU. If the card contains a known-good project, label it and set it aside. If the card contains an old or unknown project, format it on the PG/PC or set it aside as a "do not use" card.
3. If the CPU is to be reset to factory settings, perform the MRES sequence now. Verify the CPU is empty (STOP LED steady on, all other LEDs off except POWER).

Step 3: Open the Firmware Update Dialog

1. In SIMATIC Manager, with the CPU selected in the online view, go to PLC > Update Firmware. Alternatively, right-click the CPU in HW Config's online view.
2. The firmware update wizard opens. Browse to the .upd file matching the CPU article number.
3. Confirm the article number and the source/target firmware versions shown in the dialog.

Step 4: Run the Update

1. Click "Update." The CPU transitions to STOP and remains in STOP during the update.
2. Progress is shown in the dialog. Do not interrupt the power during the update; a power loss during a firmware update can render the CPU inoperable and require a service replacement.
3. When the update completes, the CPU performs a restart and the wizard reports "Update successful."

Step 5: Update the Partner CPU (H-System Only)

1. Repeat Steps 1–4 on the partner CPU. Both CPUs must reach the same firmware level.
2. After both CPUs restart, the linkup sequence runs. The system will report the linkup status in the diagnostic buffer of both CPUs.

Step 6: Update the Distributed I/O

1. For ET 200M stations, the firmware update is performed module by module: navigate to the IM 153-x in the online view of HW Config, right-click → Firmware Update.
2. Some IM 153-x variants require the firmware update to be performed through the PROFIBUS or PROFINET interface with the IM in STOP; refer to the ET 200M manual.
3. After the update, the IM restarts and re-joins the PROFINET/DP subnet. Verify that the I/O is reachable from the CPU.

Step 7: Update the CP 443-1

1. The CP 443-1 also has its own firmware, independent of the CPU. Update the CP through HW Config online or through the CP's web server (if enabled).
2. Restart the CP by power-cycling or via the web interface. The CP will return to RUN.

Step 8: Re-Load the Project and Re-Compile

1. In SIMATIC Manager, select the project, right-click the CPU → PLC > Download.
2. STEP 7 may report a "Compile difference" between the online and offline blocks if the firmware level changed. Accept the prompt to re-compile the project to the new firmware.
3. After the download, verify that the CPU enters RUN (or RUN-Redundant for H-systems).

Verification and Commissioning

After the firmware update and project reload, perform the following checks before returning the system to productive operation:

1. Diagnostic buffer clean: open the diagnostic buffer on both CPUs. There should be no "Firmware update" events with "incomplete" or "error" status. Time-stamp any warnings and clear only those that are documented as "informational" in the firmware release notes.
2. Module identification: confirm every module in the rack and every distributed station reports the target firmware version in SZL 0x0000.
3. RUN-Redundant status (H-system): the operator panel of both CPUs should show the redundant icon. The diagnostic buffer should contain a "Linkup successful" event with a current time stamp.
4. I/O check: in the online view of HW Config, verify that every I/O module is in "OK" status and the input values match the physical process (or the simulation source).
5. Safety systems (F-CPU only): re-perform the safety acceptance test per the F-CPU safety manual. The F-signature and the PROFIsafe addresses may need to be re-confirmed after a firmware change. The F-system's PROFIsafe V2 mode (versus V2.4) is firmware-version specific.
6. Time synchronization: confirm that the time on both CPUs is synchronized (CP 443-1 NTP mode or S7 time sync). A firmware update resets the time-of-day clock; the clock is re-set by the next time sync.
7. Connections: open NetPro and verify that all S7 connections (HMI, PG, partner CPU) are in "Established" status.
8. Process test: run a brief functional test of the critical I/O (valves, drives, safety circuits) before the system is handed back to operations.

Troubleshooting Matrix

Edge Cases and Field-Proven Caveats

• Firmware version compatibility matrix: not all firmware versions of the CPU 416-5H are compatible with all versions of the CP 443-1. Before starting an update, check the compatibility list in the CP 443-1 manual and the CPU 416-5H manual.
• Major vs minor firmware updates: a "major" update (e.g., V4 → V6) is a more invasive change than a "minor" update (e.g., V6.0.3 → V6.0.7) and may require a re-compile and a re-test of the user program. The release notes will state this explicitly.
• F-CPU safety firmware: if the CPU 416-5H is used in a safety application (F-variant, e.g., CPU 416F-5H), the safety firmware is part of the same .upd file. After the update, the F-signature and the PROFIsafe parameters must be re-verified.
• Power supply redundancy: the S7-400H rack has redundant PS 405/PS 407 power supplies. During the firmware update, both power supplies should be present and the input power should be from a stable source. A brief power dip during the update is the most common cause of a failed firmware update.
• CP 443-1 update during operation: updating the CP 443-1 firmware while the CPU is in RUN can cause a brief interruption of the Ethernet subnet. Plan the CP update for the same maintenance window as the CPU update.
• Time-of-day clock: the S7-400 CPU's time-of-day clock is maintained by a capacitor when the CPU is unpowered; a firmware update does not reset the clock, but a CPU power-cycle of more than the capacitor hold time (typically 6 weeks) will reset the clock.
• Sync module firmware: the H-sync modules (6ES7 960-1AA04-0XA0 or 6ES7 960-1AB04-0XA0) have their own firmware, which is updated with the CPU. The update is part of the CPU firmware .upd file but is applied to the sync module during the linkup sequence.
• PROFINET device name: after a firmware update of an IM 153-4 PN, the PROFINET device name may need to be re-assigned. The IM keeps the device name across firmware updates, but a factory reset of the IM will clear it.
• Backplane bus fault during update: if a non-redundant module in the central rack loses power during a firmware update, the CPU can report a backplane bus fault. The fault clears when the module is powered again; the firmware update is not affected.
• STEP 7 version compatibility: STEP 7 V5.5 SPx supports CPU 416-5H firmware 6.x. Older STEP 7 versions (V5.3, V5.4) cannot program firmware 6.x and must be upgraded before the update.

S7-400 vs S7-1500 Behavior and Documentation References

The S7-1500 platform has a different firmware update behavior that is sometimes conflated with the S7-400: an S7-1500 CPU goes to STOP when the firmware update starts, and a memory reset is performed automatically at the end of the update. The user program and configuration are retained in the TIA Portal project, but the CPU must be re-loaded with the project after the update. This is documented in the TIA Portal help under "Updating the firmware of a module" (see Basic information on the firmware update of a module). For an S7-400 procedure, do not assume S7-1500 behavior; refer to the S7-400H manual.

Authoritative references for this article:

• Siemens Industry Online Support — main portal for S7-400H, CPU 416-5H, CP 443-1, and ET 200M manuals and firmware downloads
• TIA Portal: Basic information on the firmware update of a module (S7-1500 reference for contrast)

FAQ