Resolving Siemens S5 CPU 100U Checksum Error on FB Upload

Problem Overview

The SIMATIC S5-100U programmable logic controller returns a Checksum Error (German: Prüfsummenfehler) when the STEP 5 programmer attempts to upload function blocks (FBs) from CPU memory. The symptom typically manifests as a partial upload that stops at one specific block — frequently FB8 on the CPU 100U — and the rest of the program becomes inaccessible until the offending block is either isolated, repaired, or identified as firmware-internal. This is not a generic nuisance fault: a checksum error in STEP 5 is a hardware- or data-integrity indication that a block in the RAM image, memory submodule, or internal firmware area no longer matches its calculated signature.

Because the S5 platform stores the checksum for every block in the block header and re-validates it on every read operation, a single mismatch will terminate the upload and prevent further blocks from being transferred. The error is independent of the programmer cable quality, the PG type, and the STEP 5 version in the majority of field cases — but those are still the first variables to eliminate.

Root Cause Analysis

A Checksum Error on upload is the result of one of four independent failure paths, all of which must be evaluated in sequence to avoid replacing hardware that does not need to be replaced.

1. Block Corruption in the User Image

The most common cause is data corruption inside the CPU's RAM image. The S5-100U retains the user program in battery-backed RAM, and any of the following can flip bits inside an FB body:

• Buffer battery discharged or removed during operation (a primary field failure on 20+ year old S5 hardware)
• RAM module reseated while CPU was powered and outputs were live
• Memory submodule write was interrupted (power loss during PG → PLC download)
• EMI spike on the supply rail (ungrounded 24 V DC return, contactor coil suppression missing)
• EPROM/EEPROM submodule erased incompletely or written with bad socket contact

2. Communication Channel Error (TTY/PG Interface)

The S5-100U CPU front connector exposes a serial interface used by the PG (Programmiergerät). On early 100U CPUs this is a TTY 20 mA current loop interface; later variants and the AS511 protocol converter present a true RS-232 or RS-485 port. If the active cable, the TTY adapter, or the converter introduces a byte error, STEP 5 will surface it as a checksum error because the recomputed checksum at the PG will not match the value in the block header that was transmitted with errors. The PG cannot distinguish a corrupted-on-the-wire byte from a corrupted-in-RAM byte — both arrive looking like a mismatch.

3. Firmware-Built-In Standard Block

The CPU 100U firmware contains a library of standard function blocks that the user program can call but that are physically present in firmware EPROM rather than user memory. STEP 5 lists these FBs in the directory, but they cannot be uploaded because they have no user-memory image. The numbering depends on firmware revision; the typical set includes system FBs in the lower range. When STEP 5 attempts to read such a block, the CPU returns the in-memory representation, which may include reserved bytes that the offline checksum algorithm does not match. This is by design.

4. Block Length Mismatch / Out-of-Range Reference

If a single FB is dramatically larger than its peers — typically above 4 KB of MC5 code on the CPU 100U — the older TTY interface at 9600 baud can drop the last block segment under noisy conditions. The PG will report a checksum error because the trailing bytes were not received. Lowering the baud rate to 2400 or 1200 frequently clears this class of error without any data actually being wrong.

Diagnostic Procedure

Before touching the program, verify the integrity of the channel and the CPU itself. The sequence below is the order in which to spend your time on a 100U on a plant floor with no spare parts.

1. Confirm CPU state and battery: Read the BATT / battery-low indicator on the CPU front panel. On a CPU 100U the BAT LED will be lit when the lithium backup cell is below threshold. If the battery has failed, the user program is at risk. Replace the battery with the supply on (capacitor-backed exchange on the 100U is supported for a short window) or transfer the program to EPROM first.
2. Check PLC operation: Confirm that the controlled process is still running normally through the same FB8 that fails to upload. If FB8 is in scan and the machine is operating, the block is being executed and is therefore internally valid in CPU RAM. This rules out in-RAM corruption and points strongly at the communication path or at the block being a firmware-internal FB.
3. Try uploading the suspect block in isolation: In STEP 5, use the block-specific upload (FB > Upload) rather than the All Blocks function. If the block still fails to upload on its own, the failure is block-local. If the failure only appears inside All Blocks, suspect a session-level handshake or buffer exhaustion.
4. Reduce the baud rate: From the PG menu Settings > Interface (or in older STEP 5 via the COM 100U driver), set the baud rate to 2400 and disable any hardware flow control. The CPU 100U supports 9600, 4800, 2400, 1200, and 600 baud over AS511.
5. Swap the active cable / TTY adapter: The standard Siemens 6ES5 734-1... cable is a 20 mA current loop device. Check polarity (the 6ES5 734-1AK00 and similar revisions have a fixed orientation). If using a third-party USB-to-TTY converter (e.g., an INAT or a generic Siemensec-USB bridge), confirm that it is configured in current-loop mode, not RS-232 mode, when connected to a true TTY port.
6. Check the block's nominal length: Open the block directory (Catalog > Blocks in STEP 5) and compare the catalog length of FB8 to the surrounding FBs. A block 4-10x the size of its neighbors is a strong indicator of a baud-rate-induced truncation.
7. Verify online view: Use Online > Block Status or Test > Block Status in STEP 5 to read the live contents of FB8. If online status shows the body without complaint but upload fails, the problem is almost certainly a checksum recomputation difference between the live runtime image and the stored static image — typical of an FB that was last edited by a different STEP 5 version or by a memory card write that did not update the header CRC.

Solution Paths

Once the root cause category is identified, apply the matching remedy. The remedies below are listed in increasing order of invasiveness.

Solution A — Restore the Communication Channel

If the failure is reproduced on multiple blocks and the PLC is otherwise operating correctly:

1. Set PG baud to 2400, no parity, 8 data bits, 1 stop bit.
2. Replace the 6ES5 734-1 active cable with a known-good spare. The 20 mA loop is polarity-sensitive; if the loop is open the PG reports NAK, but if the loop is shorted or partially loaded the error mode degrades into checksum faults.
3. Disable any USB-serial converter's power management; on Windows, uncheck Allow the computer to turn off this device to save power on the USB root hub.
4. Re-attempt All Blocks upload. If the upload proceeds past the previously failing block, the channel was the fault.

Solution B — Reconstruct FB8 from a Backup

If a backup exists on EPROM, EEPROM, floppy, or a S5-DOS archive, perform a controlled restore:

1. Stop the CPU (PG functions > Stop).
2. Insert the backup memory submodule.
3. Transfer the backup blocks to RAM (PLC > Transfer Memory > RAM).
4. Cold restart the CPU.
5. Re-attempt the upload.

If only a single FB is needed and the rest of the program is intact, the targeted restore is: Edit > Block > Transfer > PLC > FB8 from the backup archive. STEP 5 will write only FB8 to the CPU without disturbing the rest of the program.

Solution C — Delete and Rebuild the Block

If no backup exists, the suspect block must be deleted from CPU memory and rebuilt from documentation or by manual reverse engineering. The deletion path is:

1. Open the block directory (Catalog > Blocks).
2. Mark FB8.
3. Use PLC > Delete Block to clear the corrupted FB from CPU memory.
4. Confirm that the All Blocks upload now completes without a checksum error. The remaining blocks in the program can be uploaded; FB8 will appear as absent.
5. Recreate FB8 by hand from the original control narrative, I/O list, and the FB-call signature seen in the calling PB or OB.

Solution D — Replace the Battery-Backed RAM

If corruption is recurring and the battery is more than 5 years old, replace the lithium backup cell (part number depends on the CPU variant; common is the 6ES5 971-0AA00 or equivalent 1/2 AA lithium 3.6 V cell). Use only the Siemens-recommended cell or a direct cross-reference (e.g., Tadiran TL-5902). The replacement must be done with the CPU powered; a power interruption while RAM is unseated will clear the program.

STEP 5 Parameter Reference

The following parameters govern the upload session on the CPU 100U. The values are entered in the STEP 5 Settings dialog or the COM 100U driver configuration.

Firmware-Built-In Block List (CPU 100U)

The CPU 100U firmware image contains standard FBs that occupy slots in the user-visible block address space but are not user-programmable. The exact list varies by firmware version; the following set is the most commonly encountered in the field for the standard CPU 100U (6ES5 100-8MA02 and similar). Any attempt to upload these will produce a checksum error or a Block not present response:

Verification Steps

After applying any remedy, verify with the following checks:

1. Repeat the full upload: PLC > Upload All Blocks. The transfer must complete with no checksum error, and the block count at the end of the transfer must equal the block count in the on-line directory.
2. Compare the offline and online views: For each uploaded FB, open the block and compare statement count and address references to the source listing if available.
3. Run a cold restart: Power-cycle the CPU with the backup battery confirmed healthy. A clean cold restart without OB not loaded or Block invalid stop messages confirms that the integrity of the block set is intact.
4. Watch the error stack: In the ISTACK (Interrupt Stack) and the USTACK (User Stack) — accessible via PLC > Information > Stack in STEP 5 — confirm that no block names appear as ??? or INVALID. These notations indicate that the runtime attempted to call a block with a bad header, which is the runtime analog of the upload-time checksum error.
5. Monitor battery and operating mode: Confirm the BASP (command output disable) and the RUN / STOP indicators. The CPU must return to RUN automatically after the cold restart, and BAT must be off.

Preventive Measures

• Replace the CPU backup battery on a 3-year cycle, regardless of indicator state.
• Maintain an EPROM/EEPROM master of every program; update the master after every approved change.
• Store STEP 5 project archives on a modern filesystem with a versioned backup, with the .S5D and printed listing paired.
• Use the 6ES5 734-1... active cable for the 20 mA loop; third-party passive cables introduce bit errors that present as checksum faults.
• Connect the CPU to a clean, grounded 24 V DC supply; missing PE on the supply chassis is a recurring cause of transient corruption.
• Train every engineer on the difference between firmware-resident and user-resident blocks; attempted reads of firmware blocks are not a fault, they are the design.

Troubleshooting Matrix

Standards and Documentation References

For verification of the S5-100U behavior described above, the primary references are the Siemens SIMATIC S5-100U system manual (6ES5 998-0UB... series), the CPU 100U hardware manual, and the STEP 5 programming manual. The S5-100U product line is also covered in the Siemens catalog ST 50.1 (now archived in the Siemens Industry Online Support legacy section). Where the exact manual edition is not stated in the source, the engineer should match the catalog number from the CPU faceplate to the corresponding manual edition before quoting any spec or memory size as a guarantee.