S7-300 CPU Clock Stops on Power Off: Software vs Hardware Clock

Problem: CPU Clock Freezes After Power-Off

A SIMATIC S7-300 CPU 312 (for example catalog number 6ES7 312-1AC13-0AB0) reports a time-of-day that halts and freezes at the last value when the 24 V supply is removed. When power returns and the CPU transitions through OB100 / restart, the time still equals the value it held at the moment of power-down, and the clock resumes from that point. The same defect is reported on the bare S7-313 (6ES7 313-1AD03-0AB0).

Critically, the fault is not present during a controlled Stop/Run transition. While the CPU is in STOP with power applied, the clock continues to run, and any drift accumulated during Stop is automatically corrected on the next Run. The clock is also correct after a warm restart in some firmware revisions - the freeze only happens when the 24 V supply collapses fully.

This symptom is not caused by:

• A defective SFC1 "READ_CLK" call.
• An HMI / OP tag wiring problem (the OP can be disconnected entirely and the freeze still occurs).
• A missing or corrupt project on the MMC (the issue is identical on a freshly cleared CPU that only contains OB1 calling an FC that wraps SFC1 into DB1 of type DATE_AND_TIME).
• A STOP/RUN transition - only a true power-down triggers it.

The root cause is hardware, not software: the affected CPUs implement the time-of-day as a software clock with no real-time-clock hardware block and no battery-backed retention, so the counter simply stops when VCC collapses.

Root Cause: Software Clock vs Hardware RTC in the S7-300 Family

Every SIMATIC S7-300 CPU reports its clock capability on the device datasheet. There are two distinct implementations:

• Software clock - a counter incremented by an interrupt-driven tick in the CPU firmware. No real-time hardware, no battery backup. The counter value is lost on any power removal and the next restart begins from zero / undefined until the user program re-initialises it.
• Hardware clock (RTC) - a dedicated real-time-clock chip on the CPU board, kept alive by the backup battery in the battery compartment, that continues counting through power-off. Survives for the published buffer time (typically weeks to months) on a fresh battery.

The deciding factor is the CPU model, not the firmware version. The S7-312 and S7-313 (non-C) implement a software clock with a maximum deviation of 15 s/day. The S7-313C, all S7-314/-314C variants, and the entire S7-315/-315-2/-317/-319 family implement a hardware clock (real-time clock) with a maximum deviation of 10 s/day, buffered, and synchronisable across the network.

This split is also documented in the SIMATIC S7-300 product information: the "Clock" line on the device datasheet explicitly states Software clock or Hardware clock (real-time clock), with the corresponding Buffered entry of No or Yes respectively.

Affected S7-300 CPUs and Exact Catalog Numbers

The following table summarises the time-of-day capability of the standard S7-300 CPUs. Always confirm against the device label and the latest Siemens Product Information, as some sub-variants change capability (for example the later 312C with the 5AC02 / 5AC03 firmware series).

Reference: Siemens Industry Online Support - SIMATIC S7-300 product documentation, CPU 31x data sheets.

S7-300 Time-of-Day System Functions (SFCs)

All time-of-day operations on the S7-300 are performed through the system function blocks (SFCs) listed below. They are documented in the SIMATIC S7-300/400 System and Standard Functions reference manual (SIOS entry ID 1214574 in the Siemens Industry Online Support).

The two SFCs you will use most for the diagnosis described in this article are SFC0 ("SET_CLK") and SFC1 ("READ_CLK"). On a CPU that has no buffered RTC, SFC0 must be called on every restart to set the time to a valid value; SFC1 on its own will simply return the last value the software counter held when the CPU booted.

Step-by-Step Diagnosis with SFC1 READ_CLK

Follow this sequence in STEP 7 V5.x to confirm that the CPU is the cause of the freeze rather than a wiring or HMI issue.

1. Create a small test program: OB1 calls FC100, which in turn calls SFC1 and stores the result in DB1 of type DATE_AND_TIME starting at DBB0. Clear all other blocks from the offline project.
2. Download the project to the CPU and place it in RUN. Note the current time shown in DB1.
3. Remove the 24 V supply at the CPU power connector. Wait at least 30 seconds.
4. Re-apply the 24 V supply. Allow the CPU to complete its restart (SF / BF LEDs clear, RUN LED on).
5. Read DB1 again from the online view. If the value is unchanged from step 2, the CPU lost its time base - this is the symptom the article addresses.
6. Now place the CPU in STOP, wait 10 s, and put it back in RUN. Read DB1 again. The time will have advanced by the 10 s pause - proving that the freeze is power-specific, not a programming fault.

If the test shows the same value before and after the power cycle, the CPU is exhibiting the documented behaviour of a software clock on a power removal. If the test shows a value close to the moment of power restoration, the CPU is on a hardware-clock model and you have a different problem (battery, firmware, or a corrupted project).

Solution 1: Migrate to a Hardware-Clock CPU

The most reliable fix is to replace the affected CPU with a model that has a hardware RTC. The minimum-impact upgrade is the S7-313C (compact CPU with integrated DI/DO and AI), which is pin- and project-compatible with the S7-313 in most I/O configurations and has a buffered hardware clock.

When migrating:

1. Open the S7 project in STEP 7 V5.x or TIA Portal (the S7-300 is supported in both).
2. Right-click the CPU in HW Config and select Replace Object. Pick the new part number, for example 6ES7 313-5BF03-0AB0 for the S7-313C.
3. STEP 7 will re-assign the MPI / Profibus addresses and re-allocate the diagnostic addresses for the integrated I/O. Save and compile.
4. Download the hardware configuration. The user program, blocks, and tags are reused without change - SFC0 / SFC1 work identically on the new CPU.
5. Insert a fresh 3.6 V lithium backup battery in the battery compartment (see Solution 3 below). Without the battery, the hardware clock will also lose time on power-off.

Solution 2: Synchronise Time on Power-Up via HMI or NTP

If a CPU replacement is not practical, the alternative is to push a valid time into the CPU on every restart. There are three common implementations.

2a. HMI as time master

Configure the OP / TP as the clock master and have it call SFC0 ("SET_CLK") on the CPU at start-up, then again at a periodic interval (for example once per hour) to compensate the 15 s/day software-clock drift. The OP must be configured with the Time synchronization area pointer in WinCC flexible / TIA Portal so that the panel pushes its own time to the PLC at boot.

2b. NTP via a Communications Processor

A CP 343-1 Lean (6GK7 343-1CX00-0XE0), CP 343-1 (6GK7 343-1EX10-0XE0), or CP 343-1 Advanced (6GK7 343-1GX20-0XE0) supports NTP time synchronisation. In the CP properties in HW Config enable Time-of-day synchronisation, configure the NTP server, and choose Send time to PLC. The CP broadcasts the time of day to the CPU at the configured interval. The CPU then runs SFC0 internally to update its own (software) clock.

2c. MPI / Profibus master

On a network with at least one hardware-clock CPU, set the other CPUs (or the OP) as slaves and use SFC48 "SFC_RTC" to push the master time to the slaves. Configuration is in HW Config under the CPU Diagnostics/Clock tab.

Example call to SFC0 from OB1 to push the panel's time into the CPU clock on every cycle (panel provides the time via a DB of type DATE_AND_TIME):

// STL
CALL SFC 0
   PDT   := DB100.DBX0.0 BYTE 8   // 8-byte DATE_AND_TIME from HMI
   RET_VAL := MW200

RET_VAL = 0000 hex on success, non-zero on error (see the S7-300/400 System and Standard Functions reference manual for the error code table).

Solution 3: Re-Enable Battery-Backed Buffering

On CPUs that have a hardware RTC, the time-of-day is lost on power-off only when the backup battery is missing, discharged, or installed with reversed polarity. The S7-300 uses a 3.6 V lithium battery, size AA (1/2 AA on some compact CPUs), Siemens part 6ES7 971-0BA00 for the battery holder. The expected service life is approximately two years at 25 deg C ambient.

Procedure to replace the battery without losing retentive data:

1. Confirm the CPU is in RUN. The battery can only be hot-swapped safely on a running CPU.
2. Open the battery compartment cover on the front of the CPU.
3. Remove the old battery and insert the new one in the same orientation, observing the polarity marks (+/-) on the holder.
4. Close the cover. The BATF LED must remain off.

If the BATF LED is on, the CPU has detected a battery fault and has not been buffering the RTC, the retentive flags, or the retentive DB area. Replace the battery and power-cycle the CPU; the next start will then carry a valid clock through the power-down.

STEP 7 Hardware Configuration for Time Master / Slave

Whether you use NTP, MPI, Profibus, or Industrial Ethernet as the sync source, the master / slave relationship and the sync interval are set in the CPU properties:

1. In HW Config, double-click the CPU to open the Properties dialog.
2. Open the Diagnostics / Clock tab.
3. For the Clock group, select the synchronisation mode: In the PLC (CPU runs as autonomous master), None (no synchronisation), or one of the network options.
4. Set the Synchronisation interval in seconds. Typical values: 10 s for a Profibus master, 600 s for an NTP-fed CP.
5. For software-clock CPUs (S7-312 / 312C / 313), the Time correction factor field is visible. This multiplier compensates the inherent 15 s/day drift by stretching or compressing the software tick. A value of +10 slows the clock; -10 speeds it up. The valid range and resolution are documented in the S7-300 system manual.

HMI / OP Clock Master Behaviour

When the OP / TP is configured as time master, the panel pushes its internal clock into the CPU at the configured interval (typically every 10 s to 1 h). The panel's own RTC is usually battery-backed, so it survives the power-off and is the source of truth on next boot. The CPU simply receives the panel's time and uses it as the time-of-day from which OB10 / OB11 / SFC28 / SFC30 base their schedules.

Configuration in WinCC flexible (or TIA Portal) under the panel's Time settings:

• Set the Time source to HMI if the panel should be master.
• Enable the Time synchronisation area pointer so that the panel writes its time into a configured DB on the CPU.
• Set the Access mode for the area pointer to Write on the panel side and Read on the PLC side.

For a CPU with a software clock, this arrangement is mandatory: the panel takes the role of the master, and on every cold start the panel pushes the time to the CPU via the area pointer, where a small startup OB (OB100) can call SFC0 to apply the time before user code begins executing.

Verification Checklist

After applying any of the solutions above, run the following tests in order:

1. Read DB1 online and confirm the time is current. READ_CLK should return a value within a few seconds of the PC clock.
2. Force the CPU into STOP. Confirm via the OP that the displayed time continues to update. The clock must not freeze in STOP with power applied.
3. Remove 24 V for at least 60 s. Restore 24 V. Within 30 s of restart, the displayed time must be current (within the network sync interval if a master is used).
4. If a battery was replaced, confirm that the BATF LED is off in all operating modes and that the retentive flags and DB values are preserved through a power cycle.
5. Over a 24 h period, log the displayed time at four equally spaced intervals. The deviation between the log and a reference time source should be inside the published envelope (15 s/day for a software clock after correction factor tuning, 10 s/day for a hardware clock on a fresh battery).

If the time still freezes after step 3 on a hardware-clock CPU, suspect: missing / discharged backup battery, MMC write-protect, or a firmware bug addressed in a later Service Pack. Cross-check the firmware version of the CPU (readable from the online CPU diagnostics buffer) against the Siemens release notes for the S7-300 family and update the firmware via SIMATIC Manager if a fix is documented.

FAQ