S7-414FH Safety Program Download: Resolving F-Module SF Faults

S7-414FH Safety Program Download: Resolving F-Module SF Faults After Upload/Download Round-Trip

1. Problem Summary

On a Simatic S7-414FH system (CPU 417-4H or 414-4H in F-mode paired with S7 F Systems), an upload of the runtime program from the F-CPU to the engineering workstation (EWS) followed by a download of that same uploaded program back to the same CPU forces every ET 200M failsafe module (SM 326F DI/DO, SM 336F AI) into SF (Safety Fault / passivated) mode. The standard S7-400H program portion continues to run, but the F runtime group shuts down and all F channels report passivation with diagnostic LED SF on the module and the F-CPU. Crucially, downloading the original offline backup (the project archive on the EWS) returns the system to full operation immediately. The fault is therefore not in the I/O wiring, the PROFIBUS DP/PA topology, or the ET 200M IM 153-2 redundant interface, but in the F-block container that the upload/download cycle returns to the F-CPU. The conditions where the fault appears are: - F-CPU mode: S7-414FH (Failsafe + Fault-Tolerant) running S7 F Systems V6.1 - Programming environment: STEP 7 Professional V5.4 SP6 + S7 F Systems V6.1 + CFC V7.0 - Storage medium: EPROM (not RAM) for the F-blocks - Operation: Upload from CPU to PG, then download same online blocks back to the same CPU The conditions where the fault does NOT appear: - Downloading the original offline backup - Cold restart / warm restart with the original project - Online delta download of compiled F-blocks using the F-password

2. Affected System Configuration

Component	Identified Part / Version	Role in Fault
CPU	CPU 414-4H (6ES7 414-4HJ04-0AB0) in F-mode	F-CPU; stores F-signature and F-blocks
Firmware	CPU 414-4H V4.x or higher (F-capable)	Enforces F-signature compare at startup
STEP 7	SIMATIC STEP 7 Professional V5.4 SP6 + S7 F Systems V6.1 + CFC V7.0	Editor, F-compiler, F-library container
Load memory	MMC (Flash) or EPROM card on CPU	Persists F-blocks; affects F-signature generation path
F-I/O	ET 200M with SM 326F DI/DO, SM 336F AI, IM 153-2	Receives passivation on F-signature mismatch
F-runtime group	OB 35 (default) with F-FB / F-DB generated by S7 F Systems	Generates the F-signature for the running program
Standard program	Same CFC V7.0 charts, non-safety blocks	Continues to run; not the source of the SF

The standard S7-400H runtime is unaffected because it does not pass through the F-signature verification path. The fault is bounded to the F program container managed by the S7 F Systems library (F-shells, F-runtime groups, F-FBs, F-DBs with the "F" type prefix).

3. Root Cause: F-Block Signature and F-CPU Password Mismatch

The F-CPU maintains a calculated F-signature (a 32-bit CRC) over every safety-related block in the runtime program. This signature is computed at F-compile time, written into the offline block container, and re-verified on every restart. The F-CPU also holds an internal copy of the active F-signature in its retentive/system data area. When you upload a running F program from the F-CPU, the PG receives the runtime blocks as they exist in the F-CPU's work memory. These are not bit-for-bit identical to the offline blocks in the project. The differences are:

1. Runtime F-DBs (instance data blocks) have been expanded and re-initialized by the F-runtime group, so their initial values, comments, and network attributes differ from the compiled offline copy.
2. F-CPU password protection metadata is stripped or replaced during upload because the password cannot be transmitted to a non-authenticated PG.
3. F-signature fields in the block headers are normalized to runtime values (the offline F-signature lives in the system data, not the block header) and any auxiliary F-CRC bytes inserted by the F-compiler are removed.
4. F-CPU-specific security flags (F-protection mode, F-CPU password hash) are removed from the uploaded blocks.

When the same uploaded blocks are then downloaded back to the F-CPU, two things happen that cause passivation:

• F-signature mismatch: The F-CPU computes the F-signature of the downloaded blocks and compares it to the stored F-signature in its system data. The downloaded blocks do not match the offline project, so the F-CPU sees a new F-signature. The F-CPU then refuses to start the F-runtime group and passivates every F channel.
• F-CPU password not present: F-CPU mode in S7 F Systems V6.1 requires that the F-CPU password be set in the offline project before a download is permitted. The uploaded blocks do not carry this password, so the F-CPU enters "F-CPU password not assigned" state and refuses F-mode startup.

This is the documented behavior of S7 F Systems, not a bug. The S7 F Systems manual explicitly states that an online upload of the F-program is not a substitute for the offline F-project and cannot be downloaded back to the F-CPU without re-compilation under the F-password.

4. Diagnostic Buffer Evaluation

After the failed download, open the diagnostic buffer of the F-CPU (CPU > Diagnostic Buffer in STEP 7) and filter for safety-related events. The events that confirm the F-signature mismatch and password issue are:

Event ID (Hex)	Event Text	Meaning
0x75D1	F-signature comparison: F-signature of the loaded F-program differs from the stored F-signature	Confirms the F-CPU recognized the program as a different F-program than the one originally loaded
0x75D2	F-CPU password not assigned / F-CPU in unprotected state	Confirms the F-password was not transferred with the download
0x75D3	F-runtime group not started: F-signature error	Confirms the F-OB did not start, which is why all F-channels passivated
0x39xx / 0x38xx	Module failure / channel passivated on F-SM 326 / SM 336	Side-effect; not the root cause but appears for every F-channel

For the detailed diagnostic buffer event list, refer to the S7-400H / S7-400F/FH Automation System Diagnostics Manual on the Siemens Industry Online Support portal.

5. F-Block Signature Mismatch Mechanism

The F-signature in S7 F Systems is not a single block CRC. It is a global F-signature calculated across the entire F-program container in this order:

1. All F-FBs (function blocks with safety logic).
2. All F-FCs (safety functions called from F-FBs).
3. All F-DBs (instance and global F-data blocks).
4. The F-runtime group OB (typically F-OB 35 by default) and its F-shells.
5. The F-shared DB references and the F-IO DB mapping.

The signature is computed in the S7 F Systems optional package using the F-library version that is active at the time of F-compilation. Any of the following changes invalidate the signature:

• Re-editing a CFC chart that contains F-blocks and re-compiling.
• Switching to a different F-library version (F-lib V1.x to V2.x migration, for instance).
• Re-saving an F-DB in STEP 7 without F-compilation.
• Online upload of the blocks and subsequent download without F-compilation.

The upload path produces runtime blocks that have not been re-processed by the F-compiler. They look like valid F-blocks to STEP 7, but they lack the auxiliary verification objects the F-compiler inserts (F-shells, F-CRC padding, F-IO DB cross-references). When the F-CPU computes the signature on download, it does so on the full block body, and that body does not match the body the offline project was last F-compiled from. Result: 0x75D1 in the buffer, F-runtime group stops, all F channels passivate. For the full description of F-signature calculation, refer to the S7 F/FH Systems - Configuring and Programming manual, section "F-signature and F-program identification".

6. Step-by-Step Recovery Procedure

Use this sequence to bring the F-CPU back to a clean state. Do not attempt the failed download again until the offline project is confirmed F-consistent.

6.1 Capture the F-CPU diagnostic state

1. Connect the EWS to the F-CPU via Ethernet (PROFINET or Industrial Ethernet of the plant network) and establish an online connection to the F-CPU in STEP 7 V5.4 SP6.
2. Open CPU > Diagnostic Buffer and save the buffer to a text file for the maintenance log.
3. Open CPU > Module Information > F-Parameters (visible only in S7 F Systems V6.1) and note the currently stored F-signature.
4. Open PLC > F-CPU Password and record whether a password is set. If the field is empty, the F-CPU has no password assigned.

6.2 Place all F-channels in maintenance bypass

Before the F-program is reloaded, all F-channels must be operationally bypassed by the upstream safety relay or hardwired logic (e.g. emergency stop maintained, valve outputs isolated). This is mandatory because the F-runtime group will be off-line for several minutes.

6.3 Re-F-compile the offline project

1. Open the offline project on the EWS. Verify it is the original backup, not the uploaded copy.
2. Open the S7 F Systems configuration editor (Options > F-Systems Configuration).
3. Select F-Compile > Check Consistency. Resolve every error in the message window.
4. Select F-Compile > Compile All F-Blocks. The F-compiler regenerates all F-shells, the F-runtime group OB, the F-IO DB, and recomputes the F-signature.
5. Save the project. The S7 F Systems status bar should show "F-program consistent" and a green check.

6.4 Re-assign the F-CPU password

1. Open PLC > F-CPU Password.
2. Enter the original F-CPU password that was assigned when the system was first commissioned. If the password is unknown, the F-CPU must be reset to factory defaults (requires the original Siemens support password recovery procedure, which requires proof of ownership).
3. Confirm the password assignment. The F-CPU online view will now show "F-CPU password assigned".

6.5 Download the offline program to the F-CPU

1. In the offline project, select PLC > Download to Target System.
2. STEP 7 will prompt for the F-CPU password. Enter it.
3. Select the entire program (blocks and system data) for download.
4. Confirm the download. The F-CPU will perform a full restart and validate the F-signature against the freshly compiled blocks.

6.6 Verify the F-runtime group startup

1. After the F-CPU completes restart, the diagnostic buffer should show 0x75D4 F-runtime group started, F-signature OK (or equivalent "F-signature valid" event).
2. Open CPU > Module Information > F-Parameters and confirm the F-signature matches the one shown in the offline project under Options > F-Systems Configuration > F-Signature.
3. Open the CFC runtime view for the F-charts and confirm the F-runtime group is green and running.
4. Run a manual passivation/integration test on a single F-channel to confirm F-mode is fully operational.

7. Proper Upload/Download Workflow for F-Programs

The general rule for S7 F Systems is: an upload is never a substitute for a project archive. If a remote upload is part of the client's standard operating procedure (for change control, version tracking, or cyber-security reasons), the workflow must be wrapped as follows:

7.1 Upload-only step (for archive / documentation)

1. Connect to the F-CPU and upload blocks to the EWS.
2. Save the uploaded project under a clearly named directory (for example, ProjectArchive_YYYYMMDD_HHMMSS).
3. Do NOT use this uploaded project for download. Treat it as a read-only forensic copy.

7.2 Re-download requires the offline project

1. The authorized engineer opens the original offline project, not the upload.
2. If changes are required, edit the offline project, F-compile, then download.
3. After download, the F-CPU accepts the program because the F-signature was generated by the F-compiler under the F-password.

7.3 Why a round-trip is not equivalent

The F-compiler is the only authorized process that produces a valid F-program container for the F-CPU. An upload returns runtime blocks; a download expects offline F-compiled blocks. The two sets are not interchangeable. The S7 F Systems manual is explicit on this point and the F-CPU firmware refuses to start the F-runtime group if the F-signature does not match.

8. EPROM vs RAM Considerations

The system uses EPROM (MMC) for load memory. This adds two extra constraints that compound the signature issue.

8.1 EPROM (MMC) and F-blocks

On S7-400H, F-blocks can be stored on the Flash MMC, but the F-signature is stored in the F-CPU's system data area, not on the card. When the MMC is exchanged, the F-CPU retains the previously stored F-signature and compares it against the program on the new MMC at startup. A round-trip upload/download without F-compilation changes the program on the MMC in a way the F-CPU does not recognize as the original F-program.

8.2 EPROM erase and rewrite

If the EPROM is write-protected or in EPROM mode (read-only after initial programming), a download to the F-CPU from the EWS will fail at the write step. The F-CPU will report 0x75D0 F-program cannot be written to load memory or similar. Switch the MMC to RAM-compatible (writable) mode before attempting the download. After the download, you can re-burn the EPROM from the now-correct RAM image using the STEP 7 PLC > Copy RAM to ROM function with the F-CPU password active.

8.3 The interaction with the round-trip

In the failing scenario, the upload likely read runtime blocks from the F-CPU's work memory (RAM) and presented them to the EWS as if they were offline blocks. The download then wrote these runtime blocks back to the MMC, overwriting the original F-compiled image. On restart, the F-CPU found a program whose F-signature did not match the previously stored F-signature in system data, hence the 0x75D1 event. This is also why Copy RAM to ROM should never be used on a F-CPU that is in a transient or failed F-state; always bring the offline project back to a known good state and F-compile before re-burning the MMC.

9. CFC-Specific F-Compilation Behavior

CFC V7.0 compiles charts into FB/FC/DB block containers. When the chart contains F-blocks (F-CPU, F-channel driver, F-runtime group driver, F-shells), the CFC compiler delegates the F-related portion to the S7 F Systems F-compiler. The S7 F Systems F-compiler inserts additional code that the standard STEP 7 compiler does not see.

9.1 Two-stage compilation

1. CFC compiles the chart into standard FBs/FCs/DBs.
2. S7 F Systems F-compiles the same set plus inserts F-shells, F-CRC padding, and the F-signature generator.

An upload retrieves the result of step 1 plus the F-shells from step 2, but the F-CRC padding and the F-signature generator are not preserved in the same byte-for-byte form. The next download thus fails the F-signature check.

9.2 What is and is not preserved in the upload

Block component	Preserved in upload?	Re-generated by F-compile?
F-runtime group OB code	Yes (runtime form)	Yes (offline form has F-shells)
F-shells	Partially	Yes, on F-Compile
F-CRC padding	No	Yes
F-IO DB cross-references	Yes (runtime form)	Yes (offline form has additional safety fields)
F-signature value	Recomputed by F-CPU on download	Computed and stored in offline project on F-Compile
F-CPU password hash	Stripped	Re-derived when password is set in offline project

9.3 The recommended CFC + F workflow

1. Edit the CFC chart.
2. Compile the chart (CFC menu: Chart > Compile > Charts).
3. F-compile the F-program (Options > F-Systems Configuration > F-Compile All).
4. Check F-consistency (F-Compile > Check Consistency).
5. Download to the F-CPU with the F-password.

Any of the four upload/download round-trips that skip steps 3 and 4 will produce the 0x75D1 signature error on the next restart. For CFC-specific compilation and F-integration behavior, see the CFC for S7 Continuous Function Chart Manual and the S7 F Systems Optional Package documentation.

10. S7-414H vs S7-414FH: Why the FH System Behaves Differently

In the original report, the standard S7-400H program uses CFC and the round-trip upload/download works. The S7-414FH program uses CFC and the same round-trip fails. The difference is the F-mode in the FH firmware.

Aspect	S7-414H (standard H)	S7-414FH (F-capable H)
F-mode	Disabled	Enabled; firmware enforces F-signature check
F-runtime group	None	Mandatory, started by F-OB in F-runtime environment
F-CPU password	Not required	Required before any F-block download
Upload of standard program	Round-trip safe (CFC blocks are uploaded and downloaded without F-signature concerns)	Standard blocks round-trip safe; F-blocks do not round-trip safe
F-signature enforcement	None	Enforced at every restart, on every MMC change, on every download

In short, the S7-414FH adds an additional verification layer that the S7-414H does not have. Any operation that would change the F-program container without going through the F-compiler is rejected. This is the entire purpose of F-mode: deterministic detection of unauthorized program changes. For the architectural differences between S7-400H and S7-400FH, see the S7-400H Fault-Tolerant Systems Manual, section "Comparison of S7-400H and S7-400FH".

11. Verification and Commissioning Checks

After the recovery procedure, run a structured verification pass before returning the system to the client.

11.1 F-signature verification

1. Open Options > F-Systems Configuration > F-Signature in the offline project. Note the signature value.
2. Open the F-CPU online and view CPU > Module Information > F-Parameters. Confirm the online F-signature equals the offline F-signature.
3. If they differ, do not start production. Re-F-compile and re-download.

11.2 F-channel passivation/integration test

1. Force-passivate a single F-DI channel from the CFC chart (or via the standard F-test mode in the F-channel driver block).
2. Confirm the F-channel LED reports passivation (SF on the module, channel passivated in the module information).
3. Re-integrate the channel and confirm the F-runtime group accepts the channel back without diagnostic events.
4. Repeat for one F-DO and one F-AI channel.

11.3 F-OB and F-runtime group status

1. Open the CFC online view of the F-charts.
2. Confirm the F-runtime group is running (status green, F-OB 35 cycle time within expected range).
3. Confirm no F-block has a quality flag of "invalid" or "substituted".

11.4 F-CPU password persistence

1. Cycle power to the F-CPU.
2. Confirm the F-CPU retains the F-password assignment (the password is stored in retentive system data).
3. Confirm the F-runtime group restarts automatically and the F-signature verification passes.

11.5 Audit trail

1. Document the F-signature before and after the operation.
2. Document the F-CPU password change (if any) and the authorized engineer.
3. Document the diagnostic buffer events captured during the failed upload/download cycle, for the change-control record.

12. Frequently Asked Questions