CP341 SF Red LED: Reload Loadable Driver After Power Loss

CP341 SF Red LED After Power Loss: Reloading the Loadable Modbus Driver

A Siemens SIMATIC S7-300 CP 341 (order number 6ES7 341-1xH01-0AE0) configured for RS422/485 Modbus RTU communication can present a confusing fault after an uncontrolled cabinet power loss: the SF (Group Error) LED turns solid red, the Modbus master or slave stops exchanging data, the diagnostic buffer of the CPU shows no entry tied to the CP, and the HW Config diagnostic status of the CP also shows no fault. The exchange with the connected Modbus device is dead, yet the engineering tools insist that the module is healthy. The root cause is rarely a hardware failure of the CP itself — it is a corrupted or de-initialized loadable communication driver inside the CP's flash. The standard recovery action is to reload the loadable driver to the module through STEP 7 or TIA Portal, and to bring the KPP and SCC parameter sets back into alignment.

This reference walks through the exact diagnostic path, the meaning of the version strings S7WFPA1X V2.6 and S7WFPA2X V2.5 seen in the offline/online mismatch, and the precise button-click procedure to reflash the driver on a 6ES7 341-1xH01 module without disturbing the rest of the S7-300 station. Refer to the Siemens Industry Online Support entry index for the CP 341 manual ("Communication with CP 341") and the loadable driver package documentation when in doubt.

1. Problem Statement

Symptoms observed in the field on a CP 341 RS422/485 module running Modbus RTU:

• CP 341 SF LED steady red, BF LED off, RUN LED green.
• Modbus RTU communication to the field device (slave or master) stops; no requests/responses are visible on the bus.
• CPU diagnostic buffer contains no diagnostic event for the CP when viewed in STEP 7 (PLC → Module Information → Diagnostic Buffer).
• HW Config → CP 341 → Online → Module Information shows no fault status — status bytes OK, no diagnostic interrupt pending.
• STEP 7 Online → CP 341 → Loadable Driver… dialog reports a version conflict: "KPP offline on programming unit: S7WFPA1X VERSION 2.6" versus "SCC offline on programming unit: S7WFPA2X VERSION 2.5".
• The fault is reproducible after every uncontrolled power loss on the cabinet (no orderly STOP/RUN transition, no battery-backed CPU).

2. Affected CP341 Variants and Driver Architecture

The CP 341 family of SIMATIC S7-300 point-to-point modules uses a dedicated SCC (Serial Communication Chip) on the module. The basic module ships with a 3964(R)/ASCII firmware burned into the SCC. For any other protocol — Modbus RTU master, Modbus RTU slave, RK512, customer-specific protocols — Siemens ships a separate, license-bound loadable driver that must be transferred into the module's flash before the protocol will work. Once loaded, the driver persists across power cycles — provided the write to flash was completed before power was removed.

Per Siemens product notes, the H01 generation CP 341 modules (6ES7 341-1xH01-0AE0) are known to require a reload of the loadable communication driver after a power failure if the driver was not fully committed to flash prior to power removal. The H02 generation improved the persistence behavior but can still present the same fault if the write to flash is interrupted.

2.1 Loadable Driver Naming Convention

The driver file name uses Siemens' standard pattern S7WFPA<index><variant>:

• S7WFPA1X — loadable driver, family index 1, variant X (the Modbus master build or the universal Modbus driver in this family).
• S7WFPA2X — loadable driver, family index 2, variant X (a different protocol in the same family, commonly the Modbus slave build).
• The trailing letter (X, Y, A, B…) differentiates sub-variants (e.g., RS232 vs. RS485 build of the same protocol).
• The version number (e.g., 2.6 vs. 2.5) is the driver revision shipped with the engineering tool's installation media, the loadable-driver DVD, or the latest HSP update.

3. Root Cause Analysis

The chain of events that produces the SF-red-with-empty-buffer signature is:

1. The CP 341's loadable driver is stored in flash memory on the module.
2. When STEP 7 (or TIA Portal) "loads" or "updates" the driver, it first transfers the driver image to RAM on the CP, then issues a commit-to-flash command that writes the new image to flash. The commit takes several seconds and is indicated by a specific LED pattern or a status flag.
3. If the cabinet power (24 V to the S7-300 backplane, or 120/230 V upstream) is removed before the commit completes, the flash image is left in an inconsistent state.
4. On the next power-up, the CP's bootloader detects the inconsistent image and raises the SF (Group Error) LED. The fault is handled internally by the SCC bootloader and is not reported as a diagnostic interrupt to the CPU, which is why the CPU's diagnostic buffer stays empty.
5. HW Config also reports the CP as healthy because the CP responds to the standard diagnostic register poll — it is the driver image, not the SCC hardware, that is bad.

4. KPP vs. SCC: What the Two Version Strings Mean

STEP 7's loadable-driver dialog surfaces two separate version strings because there are two distinct software components involved:

When the two versions disagree, you have one of two situations:

1. PG-side mismatch: Two different driver DVDs / HSPs were installed in the same STEP 7 install, so STEP 7 itself cannot decide which version is the "current" one. Both versions are valid; the older one is usually the one that was already in the CP from a previous load.
2. Module-side mismatch: The CP's flash image was interrupted mid-write, so the SCC reports an older or invalid version, but the KPP is current. This is the situation that requires a reload.

You can tell the two apart by going Online: if the version reported by the CP itself is "unknown", "--", or older than both PG-side strings, the CP is the source of the mismatch (case 2). If the CP's online version is identical to one of the PG strings, the PG has two driver databases installed and the conflict is purely on the engineering station (case 1).

5. Step-by-Step Diagnostic Path

Before assuming a driver problem, rule out the usual suspects on the CP 341 RS422/485 variant:

1. Wiring and termination on the RS422/485 connector (X27): For RS485, the bus must be terminated at both ends. A typical termination is 390 Ω pull-up to +5 V on D(A) (terminal 3 / 4), 390 Ω pull-down to GND on D(B) (terminal 8 / 9), and 220 Ω between the two data lines at each end. Missing termination shows up as intermittent or completely dead comms, often with BF on the CP if the link partner is also a Siemens device — but a passive Modbus slave will simply leave the bus silent.
2. Shielding and ground reference: The shield of the RS422/485 cable must be bonded to ground at one end (typically the cabinet PE bar) and the CP 341's reference ground (terminal 8 of the X27 connector on the older pinout, or shield clamp on the connector shell) must be tied to cabinet PE.
3. 24 V to the CP's logic: The CP draws 24 V from the S7-300 backplane. A sagging or noisy backplane can mimic a firmware problem. Measure the 24 V at the CP with the cabinet at full load.
4. CPU diagnostic buffer: Open STEP 7 → PLC → Module Information → Diagnostic Buffer. Filter for entries that include the CP's logical address. If there are no entries, the problem is not on the Profibus / MPI / backplane side of the CP — it is internal to the CP.
5. CP 341 Online status: HW Config → right-click the CP → Module Information → Diagnostic. Look for diagnostic interrupts. If the buffer is empty, the CP is not reporting a diagnostic interrupt — confirming the SF is from the CP's own bootloader, not the CPU.
6. Modbus FB status word: The Modbus function blocks have a STATUS output. The relevant values for an SF-red with no bus traffic are typically in the 0x0E family (driver not loaded) or 0x1A family (timeout) — see the FB online help for the exact mapping.

6. Step-by-Step Reload Procedure (STEP 7 V5.x)

The reload requires a working online connection from the PG to the CPU (MPI, Profibus, or Industrial Ethernet via the CP 343). The loadable driver files are supplied with the Modbus driver DVD / HSP shipped by Siemens — they are not a free public download; the driver is licensed and ships with the loadable-driver media you received with the CP 341 or that you ordered separately (e.g., 6ES7 870-1AA01-0YA0 for Modbus master/slave).

6.1 Prerequisites

• STEP 7 V5.4 SP5 or later installed (V5.5+ recommended for current driver versions).
• Modbus loadable driver DVD or HSP installed on the PG (this populates the "Loadable Driver" dialog with the correct files).
• Online connection to the CPU (MPI cable, Profibus, or Ethernet to a CP 343).
• Project open in STEP 7, with the CP 341 in the configured rack.
• User rights: at minimum, "PLC → Download to Target" authorization; the loadable-driver transfer is treated as a firmware update and requires the CPU to be in STOP for the duration of the flash commit.
• Stable cabinet power — the loadable-driver transfer must not be interrupted. Place a UPS on the cabinet for the duration of the operation if the mains is suspect.

6.2 Procedure

1. In SIMATIC Manager, open the project and double-click Hardware to launch HW Config.
2. Select the CP 341 module in the rack (slot configured for MLFB 6ES7 341-1xH01-0AE0).
3. Double-click the CP to open its properties dialog. Note the configured protocol (e.g., "Modbus master, RS422/485") and the physical address assignments for the send/receive FBs. Write these down — they are part of the KPP and must match the existing program.
4. From the menu bar, choose PLC → Loadable Driver… (in some STEP 7 versions this is under Options or accessible via the right-click context menu on the CP). The "Loadable Driver" dialog opens.
5. Click "Driver in PG" to confirm the version on the engineering station (this is the S7WFPA1X v2.6 / S7WFPA2X v2.5 string you have already seen). The version listed here is the source for the upcoming transfer.
6. Click "Driver in Module" (or "Driver in AS") to read the version currently in the CP. If this version is "unknown", "--", or older than the PG version, the CP's flash image is corrupted — this is your situation.
7. Click "Load Driver" (button may be labeled "Transfer to Module" or similar). STEP 7 prompts you to put the CPU in STOP for the duration of the transfer — confirm. The transfer takes 30 to 120 seconds depending on the driver size; the CP's SF LED will remain red throughout.
8. Wait for the "Transfer completed successfully" dialog. The CP will reset itself; the SF LED should extinguish and the RUN LED should remain on.
9. Click "Driver in Module" again to verify the version now matches the PG version.
10. Switch the CPU back to RUN.
11. Watch the Modbus status word on the FB instance DB: STATUS should drop to 0x0000 within one or two poll cycles, and the first Modbus request should complete with STATUS = 0 on the FB's done output.

7. Step-by-Step Reload Procedure (TIA Portal)

If the project is in TIA Portal (V13 SP1 or later for the H01 generation; V15.1+ recommended for the H02 generation):

1. Open the project in TIA Portal.
2. In Project Tree → Devices → CP 341, open the device view.
3. Right-click the CP 341 and choose "Loadable Driver → Load to Device". TIA Portal will prompt to put the CPU in STOP.
4. Select the driver matching the protocol (Modbus master, Modbus slave, etc.) from the Driver in PG dropdown.
5. Click "Load". The transfer progress dialog reports bytes transferred; wait for "Transfer completed".
6. Verify the Driver in Module field now shows the same version as the PG.
7. Switch the CPU to RUN and verify comms.

TIA Portal stores the loadable drivers in <ProgramData>\Siemens\Automation\Portal V<version>\Drivers\CP34x; if the dialog is empty, you need to install the CP341 HSP via TIA Portal's Options → Support Packages.

8. Modbus Block Status Word Reference

When the SF LED is red and the bus is silent, the relevant STATUS values on the Modbus FBs are:

Note: the exact hex values for the 0x0E family vary between driver revisions. Always check the STATUS descriptions in the FB online help for the specific driver version you have loaded.

9. Field Commissioning Verification

After the reload, confirm recovery on four independent levels before returning the line to production:

1. CP front panel: SF LED off, RUN LED steady green, no BF or unexpected TxD/RxD blinking pattern. A short TxD/RxD flash on each poll cycle is normal.
2. HW Config online: CP 341 → Module Information → Diagnostic shows no diagnostic interrupts. The "Operating Mode" field reports the loaded protocol (e.g., "Modbus master").
3. FB STATUS: The Modbus FB's STATUS output is 0x0000 on every completed job. The DONE bit transitions match the poll cadence configured in the FB's input.
4. Bus traffic: A Modbus analyzer (or an oscilloscope on the RS485 A/B lines) shows regular request/response frames at the configured baud rate. Frame structure (8E1, 8N1, etc.) matches the slave device's configuration. CRC-16 (Modbus RTU) is valid on every frame.
5. Controlled power-cycle test: Drive the CPU to STOP via STEP 7, power the cabinet down, wait 10 seconds, power back up, observe SF LED. It must come up green. If the SF returns after a controlled power-cycle, the H01 generation is suspect and a migration to H02 should be planned.

10. Edge Cases and Recovery Without the Original Driver DVD

Field situations that complicate the standard recovery:

• Driver DVD lost, PG image does not contain the right version: The loadable driver must match the CP's hardware generation (H01 vs. H02). If the DVD is missing, order a replacement (e.g., 6ES7 870-1AA01-0YA0 for the Modbus master/slave driver package). Do not attempt to load a driver from a different CP family (e.g., CP 441) — the SCC firmware is incompatible.
• Two STEP 7 installations with different driver versions: Use a single, version-locked STEP 7 image (e.g., a virtualized PG) for any engineering work on a given machine. The mixed-PG condition produces the "KPP offline / SCC offline" mismatch seen in the source and is purely a configuration-management problem.
• Reload fails with a timeout or "Transfer error": The CP may need a full power-cycle (remove the 24 V from the backplane, wait 30 s, re-apply) before retrying. If the reload still fails, the flash itself may be damaged — replace the CP 341.
• Modbus master works, slave comms are dead: The S7WFPA1X and S7WFPA2X families target different roles. If only one direction is broken, the wrong driver image may have been loaded. Re-run the loadable-driver transfer selecting the correct role (master or slave) for the device you are emulating.
• CPU in RUN-P fails to go to STOP for the transfer: Check the mode selector on the CPU; if the key is in RUN-P, STOP transitions initiated by STEP 7 may be blocked. Switch to STOP, then to RUN, then issue the transfer.
• CP 341 is on a Profibus slave station (IM 153) rather than the central rack: The loadable-driver transfer still works through the IM, but the transfer time roughly doubles. Ensure the IM is in its normal operating state and no Profibus diagnostics are pending before starting.

11. Preventive Measures

To prevent recurrence after every power loss:

• Install a UPS on the cabinet mains, sized to keep the S7-300 backplane powered for at least 5 seconds after a mains drop. The loadable-driver flash commit on a CP 341 typically completes in under 3 seconds; a 5-second hold-up covers the worst case.
• Verify the driver transfer was complete before any planned shutdown: after a STEP 7 / TIA Portal "Loadable Driver" transfer, leave the cabinet powered for at least 60 seconds, then power-cycle manually and confirm the SF LED does not return. If it does, repeat the transfer and check for background writes from a watchdog or remote user.
• Document the driver version in the project: In the CP 341 properties dialog, the "Loadable Driver" pane should show the same version string as the HSP installed on every PG that services the machine. Lock down the PG image.
• Consider migrating to CP 341 H02 (6ES7 341-1xH02-0AE0): the H02 generation has improved flash-commit behavior. Verify the Modbus FB signatures are compatible before swapping modules.
• Avoid "load during runtime" workflows that change the driver image while the CPU is in RUN — if the operator must be able to push a driver change, force the CPU to STOP first.
• Add an automation-layer health check: Poll the Modbus FB's STATUS word in a cyclic OB and raise a maintenance alarm if a non-zero value persists for more than N poll cycles. This catches driver corruption before the operator notices the bus has gone silent.

12. Frequently Asked Questions