Battery-Backed SRAM and Retentive Data on the B&R CP1584

Scope: X20CP1584, Automation Runtime (AR), IEC 61131-3 on B&R, retentive/permanent variable semantics, battery maintenance, and data recovery.

Audience: Automation engineers maintaining B&R X20 PLCs on machines from defunct OEMs with zero documentation.

Last updated: July 2026

Table of Contents

1. Overview
2. Memory Hierarchy Relevant to Retentive Data
3. What the Battery Actually Backs Up
4. Battery Hardware on the X20CP1584
5. VAR RETAIN vs VAR PERSISTENT: Critical Semantics
6. Cold Start vs Warm Start vs INIT: What Survives
7. Battery Status Monitoring
8. Battery Replacement Procedure (Without Data Loss)
9. Backing Up Retentive Data
10. Restoring Retentive Data
11. Recovery After Battery Death and Total Data Loss
12. Function Block RETAIN Memory Trap
13. Identifying All Retentive Variables in an Unknown Project
14. Best Practices for Long-Term Maintenance
15. Key Findings
16. Sources
17. Cross-References

1. Overview

The X20CP1584 uses a lithium backup battery to maintain the contents of 1 MB of SRAM when main power is removed. This SRAM holds retentive (remanent) variables, the real-time clock, and working data buffers. If the battery dies or is removed for too long, every value in SRAM is lost irreversibly.

B&R Automation Runtime provides two distinct mechanisms for data survival across restarts: VAR RETAIN (battery-backed SRAM) and VAR PERSISTENT (stored on CompactFlash). Understanding the difference is critical because each behaves differently during cold starts, program transfers, and battery failures.

See also: memory-map.md for the full CPU memory layout, cf-card-boot.md for CF card partition structure, ar-rtos.md for AR internals and boot states.

2. Memory Hierarchy Relevant to Retentive Data

+----------------------------------------------------------+
|  CompactFlash (removable)                                 |
|  +------------------------------------------------------+ |
|  |  User Flash / User ROM                                 | |  Application code, configuration
|  |  (Non-volatile)                                        | |
|  +------------------------------------------------------+ |
|  |  Cpu.per / persistent data area                        | |  VAR PERSISTENT values live here
|  |  (File-based, non-volatile)                            | |  Survives everything except CF loss
|  +------------------------------------------------------+ |
|  +------------------------------------------------------+ |
|  |  Automation Runtime / OS files                         | |
|  |  (Non-volatile)                                        | |
|  +------------------------------------------------------+ |
+----------------------------------------------------------+
+----------------------------------------------------------+
|  SRAM — 1 MB (User RAM)          [BATTERY-BACKED]        |
|  +------------------------------------------------------+ |
|  |  Retentive variables (VAR RETAIN)                      | |  Max 256 KB on CP1584
|  |  (Remanent data area)                                  | |
|  +------------------------------------------------------+ |
|  |  User RAM buffers, working data                       | |
|  +------------------------------------------------------+ |
|  |  Real-time clock data                                 | |
|  +------------------------------------------------------+ |
+----------------------------------------------------------+
+----------------------------------------------------------+
|  DDR2 SDRAM — 256 MB (System RAM)  [NOT battery-backed]  |
|  OS, task memory, heap, I/O image                        |
+----------------------------------------------------------+
+----------------------------------------------------------+
|  System Flash (internal)          [NOT battery-backed]   |
|  Boot loader, AR kernel, hardware drivers                 |
+----------------------------------------------------------+

Key distinction: Only the SRAM layer is battery-backed. Everything in DDR SDRAM is volatile and is discarded on every restart. See memory-map.md Section 13 for the full CP1584 memory layout with address ranges.

3. What the Battery Actually Backs Up

The lithium backup battery maintains the following areas during power loss:

The battery voltage is monitored cyclically by Automation Runtime. A load test is performed that does not significantly shorten battery life but provides early warning of weakened capacity. See Section 7.

What Is NOT Battery-Backed

• DDR2 SDRAM (256 MB) — all task memory, I/O images, non-retained variables
• CompactFlash contents — application code, persistent variable files, configuration
• System Flash — bootloader and AR firmware

4. Battery Hardware on the X20CP1584

4.1 Battery Specifications

4.2 Battery Location

The lithium battery is located in a separate compartment on the CPU module, protected by a sliding cover. It is positioned under the USB interface IF4 (the left USB port when looking at the front of the CPU).

The battery compartment is on the CPU module itself — not on the power supply module or any bus module.

4.3 Battery Status LED

The X20CP1584 has a dedicated battery status indicator:

If the DC OK LED is red, the battery is depleted or absent. The SRAM is at risk of data loss during any power interruption. Replace the battery immediately.

Important: The DC OK LED being red does NOT mean the CPU is failing. The CPU runs fine on main power. The red LED only warns that the battery cannot maintain SRAM during a power loss.

4.4 Capacitor Bridge

In addition to the lithium battery, the CPU board has a capacitor (condensator) that provides a short-term SRAM bridge during very brief power interruptions. This capacitor holds SRAM for a short duration (seconds, not minutes). It is NOT a substitute for a functional battery.

5. VAR RETAIN vs VAR PERSISTENT: Critical Semantics

B&R Automation Runtime uses distinct terminology from CODESYS and other IEC 61131-3 systems. Understanding these differences is essential when reverse-engineering an unknown project.

5.1 VAR RETAIN (Remanent Variables)

VAR RETAIN
    PartCounter   : UDINT;
    MachineHours   : TIME;
    LastFaultCode  : USINT;
END_VAR

RETAIN variables live entirely in SRAM. They survive as long as the CPU has power (or battery backup). Any cold restart, program transfer, or battery death resets them to their initial values (typically zero unless explicitly initialized).

5.2 VAR PERSISTENT (Permanent Variables)

(* In Cpu.per or global persistent variable list *)
VAR PERSISTENT
    CalOffset_Axis1   : LREAL;
    Recipe_SetPoint    : REAL;
    StationEnabled     : ARRAY[1..16] OF BOOL;
END_VAR

PERSISTENT variables are written to the CF card. They survive everything except CF card removal, formatting, or physical failure.

Caveat: There is a known issue where PERSISTENT variables can be reset to zero after certain program transfer operations in Automation Studio. Always back up PERSISTENT variable values before any software transfer.

5.3 Quick Comparison

6. Cold Start vs Warm Start vs INIT: What Survives

Automation Runtime defines distinct restart types. See ar-rtos.md for operating state details and cf-card-boot.md Section 7 for runtime operating states.

6.1 Warm Restart

A warm restart preserves the current state of the runtime system. This is what normally happens when the PLC is rebooted (power cycle with battery intact, software restart command).

• VAR RETAIN: Values preserved
• VAR PERSISTENT: Values preserved
• Non-retained variables: Re-initialized to defaults
• I/O image: Reset

Triggered by: normal power cycle, software restart via Automation Studio or operator panel.

6.2 Cold Restart

A cold restart reinitializes the runtime system from scratch. The application is loaded from CF and all runtime state is discarded.

• VAR RETAIN: Reset to initial values (0 unless explicitly set)
• VAR PERSISTENT: Values preserved (loaded from CF)
• All other variables: Initialized to defaults
• I/O image: Reset

Triggered by: operating mode switch to DIAG then back to RUN, certain runtime commands, Service Mode operations.

6.3 INIT Routines

The INIT routine of each task is executed once during startup. INIT is NOT executed on a warm restart — only on cold restart or after a program download.

• Use INIT routines to set up default states for RETAIN variables that should start at known values after a cold start
• Do NOT rely on INIT to restore values that must survive cold starts — use PERSISTENT for those

6.4 Operating Mode Switch Behavior

Warning: DIAG mode does NOT clear retentive data. When the switch is returned to RUN, a warm restart is performed, meaning RETAIN variables keep their values. DIAG mode is safe for inspecting the system without losing retentive data.

7. Battery Status Monitoring

7.1 Hardware Indicator: DC OK LED

The simplest battery check requires no software at all:

• DC OK = Green — Battery OK
• DC OK = Red — Battery empty or missing

Check this LED during every routine machine inspection.

7.2 Software: BatteryInfo Function

B&R provides a system library function called BatteryInfo that returns battery status information. This function is available in the B&R System library.

(* Pseudocode — exact syntax depends on AR version *)
BatteryInfo(
    wStatus => wBatteryStatus,    (* Battery OK / not OK *)
    ...
);

The BatteryInfo function reads the cyclically-monitored battery voltage and load-test results. The battery monitoring system performs periodic load testing that does not significantly reduce battery life.

7.3 I/O Mapping

Battery status is also available through the CPU’s I/O mapping. The “Battery OK” flag appears as a digital input in the CPU I/O mapping. This can be read in your program or monitored via the watch window in Automation Studio.

7.4 Recommended Monitoring Strategy

For undocumented machines, add a simple cyclic task that:

1. Calls BatteryInfo every cycle
2. Logs a warning when BatteryOK = FALSE
3. Triggers a HMI alarm or sets a status bit visible to operators
4. Optionally writes a timestamp to a PERSISTENT variable recording when the battery was first detected as low

8. Battery Replacement Procedure (Without Data Loss)

The X20CP1584 battery can be replaced with the PLC either powered on or powered off. However, local safety regulations in some jurisdictions prohibit battery replacement while the module is energized. Follow your facility’s lockout/tagout procedures.

8.1 Method A: Hot-Swap (PLC Powered On) — Preferred

This is the safest method for data preservation. The SRAM remains powered by main supply during the swap.

Steps:

1. Ensure the PLC is running normally (RUN mode, no faults)
2. Confirm DC OK LED is green (battery still has some charge — if red, proceed anyway as main power will maintain SRAM)
3. Discharge electrostatic charge — touch the DIN rail or a ground connection (NOT the power supply terminals)
4. Slide the battery cover down to remove it from the CPU
5. Remove the old battery from the holder using fingers or insulated tweezers. Do NOT use uninsulated metal pliers — risk of short-circuit
6. Insert the new battery with correct polarity: “+” side up, positioned under USB interface IF4 (left USB port). Press the left side of the holder to secure the battery
7. Replace the cover
8. Verify DC OK LED returns to green within a few seconds

8.2 Method B: Power-Off Swap

If you must power down the PLC to change the battery, the on-board capacitor provides a brief SRAM hold-up time, but you must work quickly.

Steps:

1. Ensure the machine is in a safe state and locked out
2. Prepare the new battery — have it unwrapped and ready
3. Power off the PLC
4. Immediately (within 1 minute) perform steps 3-7 from Method A
5. Power the PLC back on
6. Verify all retentive values are correct
7. Verify DC OK LED is green

Critical: The 1-minute limit is generous, but the actual hold-up time depends on the on-board capacitor condition and temperature. Work as fast as possible. If you exceed the time window, all RETAIN variables will be lost.

8.3 Post-Replacement Verification

After any battery replacement:

1. Check DC OK LED is green
2. Compare critical RETAIN variable values against your last backup
3. Check the real-time clock is correct (if it drifted, set it via Automation Studio or NTP)
4. Log the replacement date for your maintenance records
5. Set a calendar reminder for the next replacement (4 years)

8.4 Battery Disposal

Lithium batteries are hazardous waste. Dispose of used batteries according to local regulations. Do not incinerate or puncture.

9. Backing Up Retentive Data

There is no single “export all retentive data” button. You need a strategy that covers both VAR RETAIN and VAR PERSISTENT variables. Use multiple methods for redundancy.

9.1 Method 1: Runtime Utility Center (RUC) Variable Lists

RUC can read and write variables from a running PLC via the PVI interface.

Steps:

1. Connect to the PLC via Runtime Utility Center (Ethernet or serial)
2. Create a template variable list containing all RETAIN and PERSISTENT variable names
3. Use RUC to read all values from the PLC and save to a .varlist file
4. Store the backup file with a timestamp

The template can be built by copying variable names from Cpu.per (for PERSISTENT) and scanning .var files for VAR RETAIN declarations (see Section 13).

9.2 Method 2: CF Card Image Backup

A full CF card image preserves everything — application, configuration, PERSISTENT variables, and runtime files. This is the most comprehensive backup.

See cf-card-boot.md Section 14 for detailed CF card imaging procedures.

Quick procedure:

1. Power off the PLC
2. Remove the CF card
3. Create a binary image using dd or a disk imaging tool:

   dd if=/dev/sdX of=cp1584_backup_YYYY-MM-DD.img bs=4M status=progress
   

4. Store the image in multiple locations
5. Reinsert the CF card and power on

9.3 Method 3: Service Mode Export

If the application provides PV (Persistent Variable) backup functionality, use it. Alternatively, restart the PLC in Service Mode and export all PVs whose value differs from zero. This captures meaningful runtime data while avoiding default-initialized values.

9.4 Method 4: MpRecipeXml (If Available)

If the machine uses the B&R mapp framework, the MpRecipeXml component can save/load any set of variables as XML files on the PLC’s CF card.

MpRecipeXml(
    xSave := bTriggerSave,
    sFileName := 'RetentiveBackup',
    ...
);

9.5 Method 5: Python Script with PVI.py

For automated or scheduled backups, a Python script using the PVI.py library can:

1. Parse Cpu.per to get PERSISTENT variable names
2. Parse all .var files to find VAR RETAIN declarations
3. Connect to the PLC via PVI
4. Read all retentive variable values
5. Save to a CSV or structured file

The Pvi.py library is available at: https://github.com/hilch/Pvi.py

9.6 Method 6: Automation Studio Watch Window Export

As a manual fallback, use the Automation Studio Watch window to:

1. Add all known RETAIN/PERSISTENT variables to the watch list
2. Connect online
3. Export the values (right-click, Export)

This is slow but requires no special tools beyond Automation Studio.

10. Restoring Retentive Data

10.1 Restoring VAR PERSISTENT Values

Since PERSISTENT values live on the CF card, they typically survive most disruptions. If they need to be restored from backup:

1. Connect via Runtime Utility Center
2. Load your saved variable list
3. Write values back to the PLC
4. Verify all values

10.2 Restoring VAR RETAIN Values After Data Loss

RETAIN variables must be written back one at a time (or via a variable list) since their SRAM contents were lost:

1. Ensure the battery is good and the PLC is running
2. Connect via RUC or Automation Studio
3. Write each RETAIN variable back to its known-good value
4. If you have no backup, you must manually re-enter all values from production records, calibration sheets, or last-known-good documentation

10.3 Restoring from a Full CF Image

If you have a full CF card backup:

1. Power off the PLC
2. Remove the current CF card
3. Write the backup image to a spare CF card (same model/spec):

   dd if=cp1584_backup_YYYY-MM-DD.img of=/dev/sdX bs=4M status=progress
   

4. Insert the restored CF card
5. Power on the PLC
6. Verify application loads and all values are correct

Warning: This restores the entire CF including the application binary. If the CF card has been updated since the backup, you will lose those changes. Use this method only when recovering from total data loss.

11. Recovery After Battery Death and Total Data Loss

This is the worst-case scenario: the battery died while the machine was powered off and unattended for an extended period. All RETAIN variables are zeroed. The machine may behave erratically or fail to start production cycles.

11.1 Immediate Actions

1. Replace the battery using the procedure in Section 8
2. Power on the PLC and verify it boots
3. Check the DC OK LED — it should now be green
4. Check the real-time clock — if wrong, correct it

11.2 Assess the Damage

1. Identify all RETAIN variables (see Section 13)
2. Determine which RETAIN variables are critical for machine operation
3. Check PERSISTENT variables — these should be intact on the CF card

11.3 Restore Critical Values

Priority order for restoration:

11.4 Sources for Restoration Values

If you have no backup file:

• Calibration certificates — may have recorded calibration offsets
• Last batch records — may show recipe parameters and setpoints
• HMI screenshots — if anyone photographed the HMI before the failure
• Similar machines — if you have identical machines, read their RETAIN values as a starting point (NOT a perfect match, but better than zero)
• OEM documentation — if any manuals survived, they may list default values
• Source code inspection — the .var files may contain initial values that serve as reasonable defaults

11.5 Preventing This From Happening Again

After recovery, implement the monitoring and backup procedures described in Section 7 and Section 9. Set calendar reminders for battery replacement.

12. Function Block RETAIN Memory Trap

When you declare a function block instance and mark any variable inside it with RETAIN, B&R stores the entire function block instance in the remanent (SRAM) memory area — including variables NOT marked RETAIN.

FUNCTION_BLOCK fbMotor
VAR RETAIN
    TotalRuns     : UDINT;   (* This is RETAIN *)
END_VAR
VAR
    CurrentSpeed  : REAL;    (* This is NOT RETAIN — but still stored in remanent area *)
    IsRunning      : BOOL;    (* This is NOT RETAIN — but still stored in remanent area *)
END_VAR

In this example, all three variables occupy remanent memory even though only TotalRuns needs to be retained. The non-RETAIN variables will not actually retain their values on a cold restart, but they consume remanent memory space.

Impact: If you create many instances of this function block, you can exhaust the 256 KB remanent memory limit on the CP1584 quickly. Automation Studio reports the total remanent memory usage per task — check this if you see “not enough remanent memory” errors.

Workaround: Move RETAIN variables out of the function block into global variable declarations, and pass them to the FB via references or input/output parameters.

13. Identifying All Retentive Variables in an Unknown Project

When you inherit a machine with no documentation, you need to find every variable whose value matters after a restart.

13.1 Find All VAR RETAIN Declarations

Search all .var files in the project for the VAR RETAIN keyword:

## Linux/macOS
grep -rn "VAR RETAIN" /path/to/project/ --include="*.var"

## Output example:
## /Logical/AxisControl/Variables.var:17:VAR RETAIN
## /Logical/Recipe/Variables.var:9:VAR RETAIN
## /Logical/Conveyor/Variables.var:23:VAR RETAIN

For each match, read the file to find the actual variable names and types declared after the VAR RETAIN line and before the END_VAR.

13.2 Find All VAR PERSISTENT Declarations

Open Cpu.per in the project root. All PERSISTENT variables are declared here:

grep -A 50 "VAR PERSISTENT" /path/to/project/Cpu.per

13.3 Find All RETAIN Variables Inside Function Blocks

Function blocks may declare RETAIN variables internally. Search all program files:

grep -rn "VAR RETAIN" /path/to/project/ --include="*.var" --include="*.st" --include="*.txt"

13.4 Check Automation Studio Remanent Memory Usage

In Automation Studio, the task configuration shows the total remanent memory used. This helps you understand the scale of retentive data in the project even without identifying every variable.

13.5 Build a Master Variable List

Combine all found variables into a single list with:

• Variable name and full path
• Data type
• Declaration type (RETAIN or PERSISTENT)
• Current value (read from running PLC)
• Expected/default value (from source code)
• Criticality rating

This list becomes your backup checklist and recovery reference.

14. Best Practices for Long-Term Maintenance

14.1 Preventive Maintenance

14.2 Before Any Software Transfer

Before downloading new software to the PLC:

1. Back up all RETAIN and PERSISTENT variable values (Method 1 or 5)
2. Back up the CF card image (Method 2)
3. Document the current software version on the PLC
4. Download the new software
5. Verify all retentive values after the transfer
6. If values changed unexpectedly, restore from backup

14.3 Before Any Planned Power Outage

1. Back up all retentive variable values
2. Verify the battery is good (DC OK = green)
3. If battery is questionable, replace it before the outage
4. After power is restored, verify all values

14.4 Spare Parts Inventory

Keep on hand:

• At least 2 spare batteries (part number 4A0006.00-000)
• At least 1 spare CF card (same capacity and industrial grade as the installed card)
• A copy of your latest CF card image on a USB drive stored near the machine

15. Key Findings

1. The CP1584 battery (3 V / 950 mAh lithium, part 4A0006.00-000) backs up 1 MB of SRAM holding all VAR RETAIN variables, the RTC, and system RAM buffers. It does NOT back up the application code (on CF) or the DDR SDRAM.

2. VAR RETAIN and VAR PERSISTENT are fundamentally different. RETAIN lives in battery-backed SRAM and is lost on cold restarts, program transfers, and battery death. PERSISTENT lives on the CF card and survives everything except CF card loss.

3. The DC OK LED is your first warning. Red = battery empty/missing. Green = battery OK. Check it weekly.

4. Battery replacement every 4 years is mandatory. The recommended interval is not the maximum — the actual lifespan depends on temperature and load testing patterns.

5. You have approximately 1 minute to swap the battery with power off before the on-board capacitor can no longer maintain SRAM. Hot-swap with the PLC powered on is preferred and safer.

6. Function block RETAIN wastes memory. If any variable in a function block is RETAIN, the entire instance goes into remanent memory. The CP1584 has a 256 KB remanent limit.

7. There is no built-in “export all retentive data” function. You must use RUC variable lists, PVI scripts, MpRecipeXml, or CF card imaging to back up retentive data.

8. PERSISTENT variables can be silently reset to zero during program transfers. Always back up before any software download.

9. When you inherit an undocumented machine, scan all .var files for VAR RETAIN and read Cpu.per for PERSISTENT declarations to build your variable master list.

10. The worst-case scenario (battery dead + no backup) means manual re-entry of all calibration offsets, recipe parameters, axis references, and production counters from whatever records survive. Implement automated backup immediately after recovery.

16. Cross-References

17. Sources

• B&R Official Product Page: X20CP1584 technical data (br-automation.com)
• B&R Community Forum: “Do permanent variables work properly when the PLC battery is low?” (2025)
• B&R Community Forum: “Retain Tag and Remanent Memory Usage” (2024)
• B&R Community Forum: “Storing remanent memory values in a file” (2025)
• B&R Community Forum: “Easy and quick way to save/restore values of permanent variables?” (2024)
• B&R Community Forum: “Guideline: Minimizing Information Loss Risks During PLC Software Updates” (2026)
• B&R Community Forum: “Retain variable reset to zero” (multiple replies)
• B&R Community Forum: “In userdefined Library, Function Block to Reset Variables to FALSE on Cold or Warm Restart” (2024)
• X20CPx58x Hardware Manual (B&R, V1.56) — battery replacement procedure, data sheet
• X20CP148x/348x Hardware Manual (B&R, V1.00) — battery compartment details, DC OK LED table
• Pvi.py Python Library: github.com/hilch/Pvi.py
• Runtime Utility Center documentation (B&R)