B&R CPU Memory Map and Direct Memory Access — Comprehensive Technical Reference

Scope: X20/X67 systems, CP1584/CP1484 series, Automation Studio (AS4.x through AS6.x), Automation Runtime (AR), IEC 61131-3 on B&R, and direct/pointer-based IO access patterns.

Last updated: July 2026

Table of Contents

1. Overview of B&R Memory Architecture
2. IO Data Mapping in the PLC Address Space
3. Software Addressing vs Hardware Addressing
4. IEC 61131-3 Direct Addressing Prefixes on B&R
5. How IO Modules Are Mapped to Address Ranges Automatically
6. Memory Regions: IO Image, System Variables, User Program, Retentive Data
7. Direct Memory Access via ADR(), ACCESS, and brsmemcpy
8. AT / Overlay Mechanisms in IEC 61131-3 on B&R
9. Memory Addressing for Digital IO, Analog IO, and Special Function Modules
10. Accessing IO Data When Normal IO Access Is Unreliable
11. Direct Memory Access via Automation Studio — mapp and System Functions
12. Memory Mapping Differences: CP1584 vs X20/X67 Systems
13. Memory Layout of a Typical B&R CP1584 (SRAM, Flash, IO Space)
14. Diagnostic Use of Direct Memory Access
15. Sources and References

1. Overview of B&R Memory Architecture

B&R Automation controllers (Power Panel, X20 CPUs, X67 CPUs, APC industrial PCs) are built on PC-based architectures using Intel-compatible processors (Atom, Celeron, Core i-series). The memory model differs significantly from traditional PLCs in that it combines a flat PC memory space with an IEC 61131-3 compliant IO addressing layer on top.

1.1 Memory Hierarchy

+-------------------------------------------------------+
|              CompactFlash / Flash (Application)        |  — User application code, HMI, configuration
|              (Removable, non-volatile)                 |
+-------------------------------------------------------+
|              System Flash (Internal)                   |  — Automation Runtime firmware, boot loader
|              (Non-removable, non-volatile)             |
+-------------------------------------------------------+
|              SRAM — User RAM (1 MB typical)            |  — Retentive variables, fast data area
|              (Battery-backed)                          |
+-------------------------------------------------------+
|              DDR SDRAM — System RAM                    |  — OS, runtime, task memory, heap
|              (128–512 MB typical for X20CP15xx)        |
+-------------------------------------------------------+
|              IO Image / IO Data Space                  |  — Mapped IO from X2X Link / POWERLINK bus
|              (Dedicated background I/O processor)      |
+-------------------------------------------------------+

1.2 Key Architectural Principles

• Integrated I/O Processor: X20 CPUs have a dedicated I/O processor that handles I/O data points in the background, independent of the main CPU cycle. This means IO data is continuously refreshed regardless of task execution timing.
• Flat Memory Model: Underlying x86 architecture provides a flat 32-bit (or 64-bit on newer models) address space. The IEC 61131-3 addressing layer provides a structured abstraction over this flat space.
• Battery-Backed Retentive Memory: A lithium battery (CR2477N, 3V/950mAh) backs retentive variables, User RAM, System RAM, and the real-time clock. Battery life: minimum 2 years at 23°C, replacement recommended every 4 years.
• CompactFlash for Application Storage: The application (compiled code, configuration, HMI pages) is stored on a removable CompactFlash card in a dedicated slot.

Source: X20(c)CP158x and X20(c)CP358x Data Sheet

2. IO Data Mapping in the PLC Address Space

2.1 The IO Image Concept

B&R controllers maintain an IO Image — a memory area that mirrors the current state of all physical I/O points. The IO image is divided into:

• Input Image: Contains the latest values read from all input modules
• Output Image: Contains the values to be written to all output modules

The dedicated I/O processor continuously updates the input image from field hardware and transfers output image values to field hardware, independently from the PLC task cycle.

2.2 How IO Data Flows

Physical Input → X2X Link / POWERLINK Bus → IO Image (Input Side) → User Program
User Program → IO Image (Output Side) → X2X Link / POWERLINK Bus → Physical Output

During each task cycle, the user program reads from the input image and writes to the output image. The actual physical I/O is handled asynchronously by the I/O processor.

2.3 IO Mapping File: IoMap.iom

In Automation Studio, IO mapping is managed through the IoMap.iom file. This file maps hardware I/O channels to software variables using the AT directive and IEC addressing syntax:

VAR_CONFIG
    gBatterie AT %IB."PLC1".BatteryStatusCPU;
    MODUL1 AT %IX."X20CS1012_3003A1".ModuleOk;
    MODUL2 AT %IX."X20DI9371_3003DI01".ModuleOk;
    MODUL3 AT %IX."X20DI9371_3003DI02".ModuleOk;
    ::MODUL13 AT %IX."X20DO9322_3003DO01".ModuleOk;
    ::MODUL14 AT %IX."X20AI4622_3003AI01".ModuleOk;
END_VAR

The :: prefix is a visibility/scope qualifier for application module variables. Variables in application modules require the :: prefix with the application module name.

Source: B&R Community — Use of “::” in IoMap.iom

3. Software Addressing vs Hardware Addressing

3.1 Two Addressing Paradigms

B&R Automation Studio supports two distinct addressing paradigms:

Software Addressing (Symbolic / Variable-Based)

• Variables are declared in .var files with meaningful names
• The compiler assigns physical addresses automatically
• IO is linked to variables through the IoMap.iom configuration
• Preferred for readability, maintainability, and portability
• Example: LimitSwitch1 AT %IX.0.0 — the variable LimitSwitch1 is mapped to hardware address

Hardware Addressing (Direct / Absolute)

• Variables are declared with explicit IEC 61131-3 addresses directly in code
• The programmer specifies exact addresses (%IX0.0, %QW2.5, %MD100)
• Useful for low-level debugging, diagnostic access, and porting legacy code
• Less portable — address may change if hardware configuration changes

3.2 When to Use Which

3.3 B&R-Specific Extensions

B&R extends standard IEC 61131-3 addressing with:

• Module-qualified addressing: %IX."X20DI9371_3003DI01".Channel1 — directly addresses a specific channel of a specific hardware module by its B&R hardware name
• CPU data points: %IB."PLC1".BatteryStatusCPU — addresses CPU-internal diagnostic data
• General data points: System-wide data such as time and temperature, accessible from any module in the station

4. IEC 61131-3 Direct Addressing Prefixes on B&R

4.1 Prefix Notation

The IEC 61131-3 standard defines a prefix notation for direct variable addressing. B&R implements this as follows:

4.2 Address Structure

The general format is: %<prefix><byte_offset>.<bit_offset>

• Byte offset: Address in bytes from the start of the respective IO area
• Bit offset: Bit number within the byte (0-7), used only with X suffix (bit-level)

Examples:

// Digital input — first station, first module, channel 0
LimitSwitch AT %IX0.0 : BOOL;

// Analog input — word at byte offset 4 (covers channels 2-3 of a 16-bit module)
Temperature AT %IW4 : INT;

// Digital output — byte 0, bit 3
Valve1 AT %QX0.3 : BOOL;

// Memory word for internal calculations
Counter AT %MW100 : UINT;

// Input double word for a 32-bit encoder value
Encoder AT %ID8 : DINT;

4.3 Automatic Address Assignment

When B&R hardware modules are inserted into the physical configuration in Automation Studio, addresses are assigned automatically starting from:

• %IX0.0 / %IW0 for inputs
• %QX0.0 / %QW0 for outputs

The system allocates address space sequentially based on:

1. Station order in the X2X Link chain
2. Slot position within the station (left to right)
3. Module type and channel count (digital modules use bit addressing, analog modules use word addressing)

Users can override automatic addresses manually in the hardware configuration if needed.

Source: Industrial Monitor Direct — B&R Hardware Guide

5. How IO Modules Are Mapped to Address Ranges Automatically

5.1 X2X Link Address Allocation

B&R’s X2X Link is the local bus connecting I/O modules to the CPU (or bus controller). When you configure hardware in Automation Studio’s Physical View, the system:

1. Detects module types: Each module’s hardware catalog entry specifies how many bytes of I/O data it requires
2. Allocates address ranges sequentially: Starting from offset 0, each module consumes its required number of bytes
3. Creates the IoMap.iom entries: Software variable mapping is generated based on the hardware configuration

5.2 Address Allocation Example

Station: X20CS1012 (Bus Controller, slot 0)
├── X20DI9371 (12ch Digital Input)  → %IX0.0 through %IX1.3   (12 bits = 2 bytes)
├── X20DO9322 (8ch Digital Output)   → %QX0.0 through %QX0.7   (8 bits = 1 byte)
├── X20AT4222 (4ch Analog Input)    → %IW2.0 through %IW9.0   (4 × 16-bit = 8 bytes)
└── X20AI4622 (4ch Analog Input)    → %IW10.0 through %IW17.0  (4 × 16-bit = 8 bytes)

5.3 POWERLINK Remote Station Mapping

For remote stations connected via POWERLINK (V1/V2), the MN (Managing Node) allocates PDO (Process Data Object) mapping. The IO data from remote stations appears in the IO image at addresses determined by the POWERLINK configuration. The mapping is defined in the Automation Studio POWERLINK configuration and is reflected in the IoMap.iom.

5.4 Module-Qualified Addressing

B&R provides an alternative addressing mode that uses the hardware module name directly:

// Instead of %IX0.0, reference the specific module and channel by name:
ChannelValue AT %IX."X20DI9371_3003DI01".Channel1;
ModuleOk AT %IX."X20DI9371_3003DI01".ModuleOk;

This is hardware-address-relative but not position-dependent — if you move the module to a different slot, the address remains valid because it references the module identity, not the byte offset. This is a B&R extension to IEC 61131-3.

6. Memory Regions: IO Image, System Variables, User Program, Retentive Data

6.1 Memory Region Overview

6.2 Variable Storage Classes

B&R Automation Studio supports several variable storage classes:

6.2.1 Non-Retain (Default)

VAR
    MyCounter : UINT;      // Lost on warm/cold restart
    MyFlag : BOOL;          // Lost on warm/cold restart
END_VAR

Stored in User RAM (SRAM). Initialized on every program start.

6.2.2 Retain (VAR RETAIN)

VAR RETAIN
    AccumulatedTime : UDINT;   // Survives warm restart, battery-backed
    LastSetpoint : REAL;       // Survives warm restart, battery-backed
END_VAR

Stored in the remanent memory area (a dedicated portion of the 1 MB SRAM).

Critical behavior: If any variable in a function block is marked RETAIN, the entire instance of that function block is stored in the remanent memory area. Non-retained variables within that instance are also placed in remanent memory but are re-initialized according to their declaration. This can significantly increase remanent memory usage.

Example:
  FB instance has 96 bytes total, but only 8 bytes are RETAIN (2x UDINT)
  → Entire 96 bytes allocated in remanent memory area
  → Only the 8 RETAIN bytes preserve their value across restart

Source: B&R Community — Retain Tag and Remanent Memory Usage

6.2.3 Persistent (VAR PERSISTENT)

VAR PERSISTENT
    CalibrationData : REAL;
    SerialNumber : STRING[32];
END_VAR

Stored in non-volatile flash memory (file system on CompactFlash). Survives both warm and cold restarts, including complete power loss (no battery required). However, flash has limited write cycles, so frequent writes to PERSISTENT variables should be avoided.

6.2.4 Configurable Remanent Memory Size

On X20CP1584:

• Maximum remanent memory: 256 kB (configurable in Automation Studio)
• Available SRAM: 1 MB total, of which 1 MB - configured remanent size is available for non-remanent user data

On X20CP1586:

• Maximum remanent memory: 1 MB

The remanent memory size is configurable in Automation Studio under the CPU configuration properties.

6.3 What the Battery Backs Up

• Remanent variables (VAR RETAIN)
• User RAM
• System RAM
• Real-time clock

Source: X20(c)CP158x Data Sheet — Battery Section

7. Direct Memory Access via ADR(), ACCESS, and brsmemcpy

7.1 The ADR() Operator

The ADR() operator returns the memory address (pointer) of a variable. On B&R, this returns a 32-bit address (or 64-bit on 64-bit targets):

VAR
    MyVar : UINT;
    pMyVar : REFERENCE TO UINT;
    MyArray : ARRAY[0..99] OF USINT;
    ptrArray : UDINT;
END_VAR

// Get the address of a variable
ptrArray := ADR(MyArray);

// Use a typed reference
pMyVar REF= MyVar;   // or: pMyVar ACCESS ADR(MyVar);

7.2 The ACCESS Keyword (Dynamic Variables)

B&R uses the ACCESS keyword to create a dynamic variable — a typed reference to a memory location determined at runtime. This is B&R’s primary mechanism for overlaying a variable type onto an arbitrary memory address:

// Dereference a pointer to write
CurrentValue ACCESS ADR(PointerArray[x]);
CurrentValue := TRUE;

// If the array already contains references, omit ADR()
CurrentValue ACCESS PointerArray[x];
CurrentValue := TRUE;

Source: B&R Community — How to dereference a pointer

7.3 ACCESS with INDEX for Array Overlay

The ACCESS keyword can be combined with INDEX to create dynamically indexed access to arrays or structures at arbitrary memory offsets:

VAR
    DataBuffer : ARRAY[0..255] OF BYTE;
    pValue : REFERENCE TO UINT;
    Offset : USINT;
END_VAR

// Access a UINT at a variable offset within the buffer
pValue ACCESS ADR(DataBuffer[0]) INDEX Offset;
pValue := 1234;

7.4 brsmemcpy() — Safe Memory Block Transfer

The brsmemcpy() function from the AsBrStr library is the recommended way to copy blocks of memory (strings, arrays, structs) between arbitrary addresses:

// Copy a UINT into a byte array (little-endian on x86)
brsmemcpy(ADR(Data[0]), ADR(myUINT), SIZEOF(myUINT));

// Copy back
brsmemcpy(ADR(myUINT), ADR(Data[0]), SIZEOF(myUINT));

brsmemcpy() is preferred over brsstrcpy() for memory operations because it requires an explicit length parameter, preventing buffer overflows.

Important: When using brsmemcpy() with string destinations, do not pass the start address of the destination variable as the starting address if the destination is a string with a specific maximum length. Use ADR(DestVar) with SIZEOF(DestVar) to prevent memory corruption.

Source: B&R Community — Working with large strings; B&R Community — Variable Addresses

7.5 Pointer Arithmetic Examples

Converting between byte arrays and larger data types:

VAR
    Data : ARRAY[0..27] OF USINT;
    pUINT : REFERENCE TO UINT;
    myUINT : UINT;
END_VAR

// Method 1: Using ACCESS (pointer dereference)
pUINT ACCESS ADR(Data[0]);
pUINT := myUINT;         // Write UINT to bytes 0-1
myUINT := pUINT;         // Read UINT from bytes 0-1

// Method 2: Using brsmemcpy
brsmemcpy(ADR(Data[0]), ADR(myUINT), SIZEOF(myUINT));  // Write
brsmemcpy(ADR(myUINT), ADR(Data[0]), SIZEOF(myUINT));  // Read

// Method 3: Bit access within a word
myBOOL := myUINT.0;      // Access bit 0 of the UINT

On x86 (little-endian), a UINT value of 258 (0x0102) is stored as:

• Data[0] = 0x02 (low byte)
• Data[1] = 0x01 (high byte)

Source: B&R Community — Moving Bytes into Integers and back

7.6 Memory Access Violations

Common causes of memory access violations on B&R:

• Accessing a variable by its address after the memory has been moved (e.g., after task initialization)
• Array overflow or string buffer overflow
• Pointer pointing to invalid/freed memory
• ADR() used with wrong data type alignment

Mitigation:

• Deploy the IecCheck library during debugging to detect overflow errors (remove before production!)
• Use ACCESS in the CYCLIC task, not in INIT, to avoid access violations from moved memory
• Prefer brsmemcpy() over pointer manipulation for bulk transfers

Source: B&R Community — Value applied from references

8. AT / Overlay Mechanisms in IEC 61131-3 on B&R

8.1 The AT Directive

The AT directive is the standard IEC 61131-3 mechanism for mapping a variable to a specific memory address. B&R fully implements this:

// Map a BOOL to a specific input bit
LimitSwitch AT %IX0.0 : BOOL;

// Map a UINT to a specific input word
AnalogValue AT %IW4 : UINT;

// Map a variable to a specific memory word
Counter AT %MW100 : UDINT;

// Map a variable to a memory byte (overlay)
StatusByte AT %MB50 : BYTE;

// Overlay multiple variables on the same memory location
MultiAccess1 AT %MW200 : UINT;
MultiAccess2 AT %MW200 : ARRAY[0..1] OF USINT;  // Same address, different view

8.2 Union-Like Overlay via AT

B&R supports overlaying multiple variables on the same memory address, effectively creating union-like behavior:

VAR
    RawValue AT %MW10 : WORD;
    LowByte AT %MB10 : USINT;    // Same memory, low byte
    HighByte AT %MB11 : USINT;   // Same memory, high byte
    Bit0 AT %MX10.0 : BOOL;      // Same memory, bit 0
    Bit1 AT %MX10.1 : BOOL;      // Same memory, bit 1
END_VAR

8.3 AT with Hardware-Module-Qualified Addresses

VAR
    // Map to specific module channel
    DI_Ch1 AT %IX."X20DI9371_3003DI01".Channel1 : BOOL;
    DI_Ch2 AT %IX."X20DI9371_3003DI01".Channel2 : BOOL;

    // Map to module status
    ModuleStatus AT %IX."X20DI9371_3003DI01".ModuleOk : BOOL;

    // Map to CPU diagnostic data
    BatteryStatus AT %IB."PLC1".BatteryStatusCPU : BOOL;
END_VAR

8.4 AT in IoMap.iom vs AT in Variable Declarations

The IoMap.iom approach is the standard way to map IO in Automation Studio — it provides a GUI for point-and-click mapping and separates IO configuration from code logic.

9. Memory Addressing for Digital IO, Analog IO, and Special Function Modules

9.1 Digital IO (X20DI93xx / X20DO93xx)

Digital modules use bit-level addressing (%IX / %QX):

// 12-channel digital input module
DI_1 AT %IX0.0 : BOOL;
DI_2 AT %IX0.1 : BOOL;
...
DI_12 AT %IX1.3 : BOOL;

// 8-channel digital output module
DO_1 AT %QX0.0 : BOOL;
DO_2 AT %QX0.1 : BOOL;
...
DO_8 AT %QX0.7 : BOOL;

Module-specific diagnostic channels:

ModuleOk AT %IX."X20DI9371_3003DI01".ModuleOk : BOOL;   // Module status

9.2 Analog IO (X20AT42xx / X20AI46xx / X20AO46xx)

Analog modules use word-level addressing (%IW / %QW). Each analog channel typically occupies 2 bytes (16 bits) or 4 bytes (32 bits for high-resolution modules):

// 4-channel analog input module (16-bit per channel)
AI_Ch1 AT %IW0 : INT;    // Channel 1 (bytes 0-1)
AI_Ch2 AT %IW2 : INT;    // Channel 2 (bytes 2-3)
AI_Ch3 AT %IW4 : INT;    // Channel 3 (bytes 4-5)
AI_Ch4 AT %IW6 : INT;    // Channel 4 (bytes 6-7)

// 4-channel analog output module
AO_Ch1 AT %QW0 : INT;
AO_Ch2 AT %QW2 : INT;
AO_Ch3 AT %QW4 : INT;
AO_Ch4 AT %QW6 : INT;

For analog temperature modules (e.g., X20AT4232), the module handles ADC conversion internally and provides scaled values in the IO image.

9.3 Special Function Modules

Special modules (communication gateways, encoder interfaces, IO-Link masters, etc.) typically provide larger data structures in the IO image:

• X20IF10xx (Interface Modules): Provide data areas for protocol-specific communication. Data sizes depend on the protocol and configuration.
• X20CS1010 (Encoder Interface): Encoder values are mapped as double words (%ID) in the IO image.
• X20IF1043 (CAN Interface): CAN receive/transmit data mapped via IoMap to variables. Users assign variables to the IO mapping of the interface module.
• IO-Link Masters: IO-Link data is typically mapped as byte arrays in the IO image. Boolean process data within IO-Link devices can be mapped to %IX/%QX addresses.

Source: B&R Community — X20IF1043 IO Mapping

10. Accessing IO Data When Normal IO Access Is Unreliable

10.1 Scenarios Requiring Direct IO Access

Normal IO access through mapped variables may become unreliable in these situations:

• The IO image is corrupted or not properly initialized
• A module has lost communication but the bus is still running
• During diagnostic mode (DIAG switch position)
• When the IO mapping configuration is incorrect or outdated
• When investigating sporadic IO glitches that don’t manifest in the mapped variables

10.2 Diagnostic Mode Access

The X20 CPU has a DIAG operating mode switch position. In this mode:

• Program sections in User RAM and User Flash are not initialized
• The CPU boots in diagnostic mode
• After diagnostic mode, the CPU always performs a warm restart
• IO image data is accessible for diagnostic inspection

This allows maintenance personnel to read IO states without the user program affecting outputs.

10.3 Direct Memory Access via Watch/Trace

In Automation Studio, with the debugger halted on a breakpoint and the Watch window open:

• Pointers can be dereferenced to inspect memory content at arbitrary addresses
• In AS4, use the debugger watch with pointer dereferencing
• In AS6.3+, a function is available that reveals a variable name given its address

Source: B&R Community — Watching memory content with AS

10.4 Bypassing IO Mapping with Direct Addresses

When IO mapping is unreliable, you can read IO directly by using absolute addresses in your code:

VAR
    DirectInput : BOOL;
    DirectAnalog : INT;
END_VAR

// Direct read from IO image — bypassing IoMap mapping
DirectInput := %IX0.5;         // Read digital input directly
DirectAnalog := %IW10;          // Read analog input directly

// Direct write to IO image
%QX2.3 := TRUE;                 // Write digital output directly
%QW20 := 32768;                 // Write analog output directly

10.5 PVI (Process Visualization Interface) External Access

The B&R PVI system allows external applications (C#, Python, etc.) to read and write PLC variables — including IO data — via:

• PVI Services (COM/ActiveX)
• PVI .NET
• PVIservices REST API (newer systems)

This provides an external path to IO data that bypasses the PLC program entirely, useful for:

• Automated testing (e.g., reading/writing IO from external tools)
• SCADA/HMI systems
• Data logging

Source: B&R Community — Automated IO Access from External Tools

11. Direct Memory Access via Automation Studio — mapp and System Functions

11.1 System Libraries for Memory Access

B&R provides several system libraries for direct memory operations:

11.2 mapp Technology

B&R’s mapp (modular application) technology provides pre-engineered software components:

• mapp Control: PID controllers and signal processing
• mapp Motion: Motion control functions
• mamp View: Web-based HMI
• mapp AlarmX: Alarm management
• mapp Recipe: Recipe management
• mapp Database: Data logging to SQLite

mapp components internally manage their own memory regions and IO mappings. Access to mapp internal data is provided through standardized FB interfaces, not direct memory access.

11.3 System Functions for Diagnostic Data

BatteryInfo:

BatteryInfo(stBatteryInfo);
// stBatteryInfo contains battery status from CPU diagnostics

CPU IO Mapping Diagnostic Data: CPU status registers (battery, temperature, module errors) are accessible through:

• The CPU’s IO mapping (available in IoMap.iom)
• Software registers (accessible via %IB."PLC1".* addresses)

11.4 General Data Points

X20 CPUs provide general data points that are not CPU-specific:

• System time
• Heat sink temperature
• Other general system information

These are accessible from any module in the station and are described in the X20 system user’s manual under “Additional information — General data points”.

Source: X20(c)CP158x Data Sheet — General Data Points

12. Memory Mapping Differences: CP1584 vs X20/X67 Systems

12.1 System Comparison

12.2 X20 vs X67 Differences

• X20: Modular system with DIN-rail mounting, separate bus controller and I/O modules, supports both local (X2X Link) and remote (POWERLINK) I/O
• X67: IP67-rated, field-mountable I/O system. Similar addressing model to X20 but designed for harsh environments with M12 connectors

Both X20 and X67 share the same IO addressing model and Automation Studio configuration approach. The IO mapping is identical in terms of %IX, %QX, %IW, %QW notation.

12.3 Power Panel / APC Differences

B&R Power Panel targets (PP100, PP200, etc.) and APC industrial PCs run the same Automation Runtime but may have:

• Larger DDR RAM (up to several GB)
• Solid-state drives instead of CompactFlash
• Additional PCIe slots for specialized interface cards
• Different IO connection methods (e.g., direct onboard IO vs X2X bus)

The IO addressing model remains the same, but the physical connection to IO hardware differs.

12.4 CP358x vs CP158x

The CP358x series (e.g., X20CP3584, X20CP3586) differs from CP158x primarily in:

• 3 interface module slots (vs 1 on CP158x)
• CPU redundancy support (CP3586 supports controller redundancy)
• Same processor options, same SRAM, same IO addressing

Source: X20(c)CP158x and X20(c)CP358x Data Sheet

13. Memory Layout of a Typical B&R CP1584 (SRAM, Flash, IO Space)

13.1 Detailed Memory Map

=== X20CP1584 Memory Layout ===

0x00000000 ┌─────────────────────────────┐
           │      System Flash (Internal) │  Automation Runtime firmware
           │      (Size: varies)          │  Boot loader
           ├─────────────────────────────┤
           │      CompactFlash (Removable)│  Application code (.pc executable)
           │      (512 MB – 16 GB)        │  HMI pages
           │                              │  Configuration files
           │                              │  mapp data
           ├─────────────────────────────┤
0x???????? │                              │
           │      DDR2 SDRAM (256 MB)     │  Automation Runtime OS
           │                              │  Task memory (Cyclic, Event, etc.)
           │                              │  Heap/Stack for C programs
           │                              │  mapp component memory
           │                              │  System buffers
           ├─────────────────────────────┤
           │                              │
           │      SRAM — User Area       │  Total: 1 MB
           │      (Battery-backed)        │
           │  ┌───────────────────────┐  │
           │  │ Remanent Memory       │  │  Configurable, max 256 KB
           │  │ (VAR RETAIN data)     │  │  Battery-backed
           │  │                       │  │  Preserved across warm restart
           │  ├───────────────────────┤  │
           │  │ Non-Remanent User RAM │  │  1 MB - remanent size
           │  │ (VAR data)            │  │  Battery-backed, but cleared on
           │  │                       │  │  cold restart if battery fails
           │  └───────────────────────┘  │
           ├─────────────────────────────┤
           │      IO Image / IO Space     │  Managed by integrated I/O processor
           │  ┌───────────────────────┐  │  Continuously updated in background
           │  │ Input Image           │  │  %IX*, %IW*, %IB*, %ID*
           │  │ (Digital + Analog)    │  │
           │  ├───────────────────────┤  │
           │  │ Output Image          │  │  %QX*, %QW*, %QB*, %QD*
           │  │ (Digital + Analog)    │  │
           │  ├───────────────────────┤  │
           │  │ CPU Diagnostic Data    │  │  Battery status, temperature,
           │  │                       │  │  module status, etc.
           │  └───────────────────────┘  │
           └─────────────────────────────┘

13.2 User Flash Data Area

For CPUs with onboard flash (not CP1584 specifically but common on newer models):

• Typically 512 kB of flash for user data
• Used for persistent storage of calibration data, recipes, etc.
• Accessible via SysFile library functions

13.3 Task Memory Organization

Within the DDR SDRAM, Automation Runtime allocates memory for each configured task:

Task Cyclic1 ──────────── Stack + Code + Variables
Task Cyclic2 ──────────── Stack + Code + Variables
Task Event ────────────── Stack + Code + Variables
...
System overhead ────────── OS kernel, drivers, buffers

13.4 Overtemperature Protection

• CPU shutdown at 110°C processor temperature or 95°C board temperature
• Logbook entries: Error 9204 (temperature restart), Error 9210 (halt after reset)

14. Diagnostic Use of Direct Memory Access

14.1 Common Diagnostic Patterns

Reading Module Status via IO Image

VAR
    ModuleOk : BOOL;
END_VAR

ModuleOk := %IX."X20DI9371_3003DI01".ModuleOk;
// If FALSE, module is in error state

Reading CPU Diagnostic Registers

VAR
    BatteryStatus : BOOL;
    Temperature : INT;  // From general data points
END_VAR

BatteryStatus := %IB."PLC1".BatteryStatusCPU;
// TRUE = battery OK, FALSE = battery empty/dead

Memory Inspection via ADR() + ACCESS

VAR
    TargetAddress : UDINT;
    ViewAsUINT : UINT;
END_VAR

// Given a memory address (from ADR() or other source), inspect contents
ViewAsUINT ACCESS TargetAddress;
// Watch ViewAsUINT in the watch window to see the memory contents

Using IecCheck for Runtime Bounds Checking

Deploy the IecCheck library to detect:

• Array boundary violations
• String overflow
• Memory access violations
• Stack corruption

Important: Remove IecCheck before deploying to production — it adds significant overhead.

14.2 Trace and Watch Tools

• Watch Window: Monitor live variable values when online. Supports override of output variables that are not driven by code. In AS4, dereference pointers with the debugger halted.
• Trace Window: Continuously record variable values with configurable sample rate. Maximum trace size is configurable. After stopping, zoom into the timeline to inspect values at each CPU scan.
• Logbook: System events (errors, warnings, temperature, battery) are automatically logged and can be accessed via the Automation Studio Logbook viewer.

14.3 Memory Access Violation Troubleshooting

Common diagnostics for “memory access violation” errors:

1. Check ADR() targets: Ensure all ADR()-derived pointers point to valid, initialized memory
2. Check task timing: ACCESS in INIT task may access memory before tasks are fully initialized
3. Check array bounds: Use IecCheck to detect overflow
4. Check string operations: brsstrcpy() can corrupt adjacent memory if the destination is too small — prefer brsmemcpy() with explicit length
5. Check function block retain: If retain variables in an FB are corrupted, the entire FB instance may be affected due to the all-or-nothing remanent allocation

14.4 External Diagnostic Access

• PVIservices / PVI .NET: External applications can read PLC variables including IO data, useful for automated diagnostic scripts
• SNMP: Some B&R devices support SNMP for basic health monitoring
• OPC UA: Available on newer Automation Runtime versions for standardized data access

Cross-References

• x2x-protocol.md — X2X bus carries IO data that populates the IO image in memory
• io-card-hardware.md — IO module hardware; which modules map to which address ranges
• execution-model.md — How task classes interact with the IO image at configured cycle times
• network-architecture.md — POWERLINK remote station IO mapping
• retentive-data.md — Battery-backed SRAM and retentive variable memory management
• cp1584-hardware-ref.md — CP1584 memory specifications (256 MB DDR2, 1 MB SRAM, 256 KB retentive max)
• analog-calibration.md — Analog IO scaling and calibration using memory-mapped ADC/DAC values
• io-sniffing.md — Sniffing fieldbus traffic to correlate with IO image values
• safe-io-diagnostics.md — Safety IO memory mapping and SafeLOGIC address space
• online-changes.md — Memory integrity risks during online code changes (shifted addresses)
• cf-card-boot.md — How IO configuration is loaded from CF card into memory at boot
• config-file-formats.md — IO mapping configuration file formats on the CF card
• pvi-api.md — Using PVI to read/write IO memory addresses programmatically

15. Sources and References

Official B&R Documentation

1. X20(c)CP158x and X20(c)CP358x Data Sheet — PDF
2. X20 System User’s Manual — PDF (RS Online)
3. B&R Automation Studio Product Page — br-automation.com
4. B&R Online Help (Automation Help) — help.br-automation.com
5. B&R mapp Technology — br-automation.com/mapp

B&R Community Forum Posts

6. Variable Addresses after Compilation — community.br-automation.com/7920
7. Watching Memory Content with AS (4.xx) — community.br-automation.com/7685
8. How to Dereference a Pointer — community.br-automation.com/6740
9. Moving Bytes into Integers and Back — community.br-automation.com/3075
10. Retain Tag and Remanent Memory Usage — community.br-automation.com/4320
11. Use of “::” in IoMap.iom — community.br-automation.com/2176
12. Value Applied from References — community.br-automation.com/7017
13. Retain Variable Reset to Zero — community.br-automation.com/8142
14. Working with Large Strings — community.br-automation.com/5239
15. How to Assign Variables to IO Mapping of X20IF1043 — community.br-automation.com/8116
16. Automated Read/Write Access to ARSim Hardware I/O — community.br-automation.com/10409

Technical Articles and Guides

17. Programming B&R PLCs with Automation Studio — control.com
18. B&R PLC Hardware and Automation Studio Overview — industrialmonitordirect.com
19. B&R Automation Studio: Program & Transfer to PLC Hardware Guide — industrialmonitordirect.com

Community Knowledge

20. Reddit: B&R X20 Setup — reddit.com/r/PLC
21. Reddit: B&R Use of Pointers — reddit.com/r/PLC
22. Awesome B&R — Curated Resources — GitHub

Key Findings

1. B&R X20 CPUs use a dedicated I/O processor that refreshes the IO Image independently of the PLC task cycle. Input and output images are separate memory areas updated asynchronously from user program execution.

2. IO addresses are assigned automatically by Automation Studio starting from %IX0.0/%IW0 (inputs) and %QX0.0/%QW0 (outputs), allocated sequentially based on station order in the X2X Link chain, slot position, and module channel count. Module-qualified addressing (e.g., %IX."X20DI9371_3003DI01".Channel1) survives slot repositioning.

3. The AT overlay directive allows multiple variables to share the same memory address, creating union-like behavior: a WORD at %MW10 can be simultaneously accessed as BYTE at %MB10/%MB11 or individual bits at %MX10.0 through %MX10.7. This is the primary mechanism for type-punning and bit-level IO access.

4. Direct memory access uses ADR() to get pointers, ACCESS for type-safe dereferencing, and brsmemcpy() (from the AsBrStr library) for raw block copies. The IECCheck library provides runtime bounds checking for pointer operations – critical for preventing page faults during online changes.

5. Six variable storage classes exist: Non-Retain (lost on restart), Retain (battery-backed SRAM, survives warm restart), Remanent (like Retain but initialized on first cold boot), Persistent (Flash file system, survives cold restart), Persistent_Volatile (Persistent read but Non-Retain write), and Constant (compile-time). Maximum retentive data on CP1584 is 256 KB.

6. B&R extends IEC 61131-3 with CPU-qualified addressing (%IB."PLC1".BatteryStatusCPU) for reading internal CPU diagnostics like battery status, temperature, and firmware version directly from the IO image without system function calls.

7. For diagnostic access when IO mapping is unreliable, use absolute addressing (%IX0.5, %IW10) in code, the DIAG switch position on the CPU (prevents program execution while keeping IO image accessible), or PVI/OPC-UA external access to bypass the PLC program entirely.

8. The IoMap.iom file generated by Automation Studio maps hardware IO to software variables using VAR_CONFIG blocks. The :: prefix on variable names indicates application module scope. This file is the single source of truth for IO-to-variable mapping and must match the hardware configuration on the PLC.

Disclaimer: This document is compiled from publicly available sources including official B&R documentation, B&R community forum posts, technical articles, and community knowledge. For the most authoritative and up-to-date information, consult the official B&R Automation Help system at help.br-automation.com and the official data sheets available from br-automation.com.