B&R CP1584 Compact Flash Card Boot Sequence — Complete Technical Reference

The Compact Flash card is the heart of a B&R CP1584 system — it contains the operating system, firmware, user program, hardware configuration, and all runtime data. Understanding every file on the CF card, their load order, and what happens at each boot stage is critical when you need to modify a program without Automation Studio, recover from a corrupted card, or diagnose boot failures on a legacy machine with no OEM support. This document provides a file-by-file analysis of the CF card contents, the complete boot sequence, and practical procedures for imaging, modifying, and recovering CF card data. Cross-references: bootloader-recovery.md for recovery when the CF card is missing or corrupted, firmware.md for firmware architecture details, and config-file-formats.md for configuration file formats.

Table of Contents

1. Overview
2. CF Card Hardware Requirements
3. CF Card Partition Structure
4. File System and Directory Layout
5. File Types and Their Purposes
6. Boot Sequence — Stage by Stage
7. Runtime Operating States
8. How AR Determines Which Program to Execute
9. Network Configuration Files
10. User Partition Structure
11. Imaging and Analyzing CF Card Contents
12. Modifying Boot Parameters Without Automation Studio
13. Changing the Loaded Program Binary Manually
14. Backup and Restore Procedures
15. CF Card Corruption and Missing Card Scenarios
16. Creating a Bootable CF Card from Scratch
17. Safe Boot Modes and Recovery Options
18. Sources

1. Overview

The B&R CP1584 (also referenced as X20CP1584) is an Industrial PC controller from B&R Automation. It runs Automation Runtime (AR), B&R’s proprietary real-time operating system built on top of VxWorks. The controller boots from an Industrial Compact Flash (CF) card that contains the bootloader, operating system kernel, hardware configuration, and compiled user program.

Key characteristics of the CP1584 platform:

• CPU: x86-based Intel processor
• OS: B&R Automation Runtime (based on Wind River VxWorks)
• Boot media: Compact Flash card (industrial-grade, SLC or high-endurance MLC)
• File system: FAT16 or FAT32 (depending on card size and AR version)
• HMI: None (headless controller — no integrated display)
• Communication: Ethernet (Gigabit), POWERLINK, X2X Link, RS232, USB, plus optional interface modules (CAN, Modbus, etc.)

The entire boot process, runtime environment, and user application are stored on the CF card. Without a valid CF card, the controller cannot boot.

2. CF Card Hardware Requirements

Industrial-Grade Cards Only

B&R controllers are extremely picky about CF card compatibility. Consumer-grade CF cards typically will not work for booting because:

1. Missing bootable media flag: Consumer CF cards do not set the “Fixed Disk / Bootable” flag in their ATA identification data. The BIOS requires this flag to attempt booting from the CF card.
2. No wear leveling controller: Consumer cards lack the multi-partition controller needed for the 4-partition layout.
3. Limited write endurance: Consumer MLC flash may fail after thousands of write cycles; industrial SLC cards handle hundreds of thousands.
4. Temperature range: Industrial cards operate -40°C to +85°C; consumer cards typically 0°C to +70°C.

Known Compatible Cards

• SiliconDrive SSD series (e.g., SSD-C64M-3076, part number 5CFCRD.0064-03) — used in Power Panel 300/400
• B&R branded CF cards (part numbers starting with 5CFCRD)
• Siemens SIMATIC industrial CF cards (similar bootable flag requirements)
• Cards with ATA “Fixed Disk” identification set by the manufacturer

Card Sizes

• Older systems (Power Panel 300, early X20): 64MB — 256MB (FAT16)
• Mid-range systems (X20 CP1584 era): 128MB — 1GB (FAT16/FAT32)
• Newer systems: 1GB — 8GB (FAT32)

Warning

Cloning partition tables and files to a consumer CF card will not work even with identical data. The boot process hangs at “Attempting to boot a Hard Drive… VxLD 1.4.1” indefinitely because the BIOS does not recognize the card as a boot device.

3. CF Card Partition Structure

B&R typically creates up to 4 partitions on a CF card. This is one of the reasons consumer CF cards fail — they often lack the on-card controller that can maintain multiple partitions.

Partition Layout

┌─────────────────────────────────────────────┐
│  Master Boot Record (MBR)                    │
│  - Partition table with 4 entries            │
│  - VxWorks bootloader signature              │
├─────────────────────────────────────────────┤
│  Partition 1: Active System Partition       │
│  - FAT16 or FAT32                            │
│  - Contains: bootloader (VxLD), AR kernel,    │
│    hardware config, user program              │
│  - Boot flag: ACTIVE (0x80)                  │
├─────────────────────────────────────────────┤
│  Partition 2: Passive / Update Partition     │
│  - FAT16 or FAT32                            │
│  - Mirror/update partition for fail-safe    │
│    updates (used by Runtime Update feature)  │
│  - Boot flag: INACTIVE (0x00)                │
├─────────────────────────────────────────────┤
│  Partition 3: User Partition                │
│  - FAT16 or FAT32                            │
│  - Contains: user data files, SystemDump     │
│    data, file device storage, recipes, logs   │
│  - Non-bootable                              │
├─────────────────────────────────────────────┤
│  Partition 4: Diagnostic / Utility          │
│  - Optional, may not exist on all cards     │
│  - Contains: diagnostic logs, crash dumps,   │
│    service mode data                         │
├─────────────────────────────────────────────┤
│  Remaining space (unpartitioned)             │
└─────────────────────────────────────────────┘

Active vs. Passive Partition

B&R uses an A/B partition scheme for fail-safe updates:

• Active partition (A): Currently booted and running. Contains the live bootloader + AR + program.
• Passive partition (B): Updated in the background during Runtime Update. On next reboot, if the passive partition is valid, the system switches to boot from it. If boot fails, it falls back to the old active partition.

This dual-partition approach ensures that a failed firmware or program update does not brick the controller.

Partition Types

The MBR partition type IDs used:

• 0x06 — FAT16 (for smaller cards ≤ 2GB)
• 0x0B or 0x0C — FAT32 (for larger cards)
• The active partition has the boot flag (0x80) set in byte 0 of the MBR partition entry

4. File System and Directory Layout

Active System Partition Directory Tree

/ (Root of Active Partition)
├── VxLD              — VxWorks Loader (bootloader executable)
├── brconfig.sys      — Automation Runtime system configuration
├── autoexec.bat      — Optional startup commands (legacy)
├── boot.ini          — Boot configuration / boot parameters
├── CPUTemp.ini       — CPU temperature monitoring settings
├── *.sys             — System driver files
├── *.dll             — Runtime libraries
├── *.bin             — Binary blobs (kernel extensions, firmware)
│
├── Flash/
│   ├── Project/       — Project folder for Power Panel systems
│   │   ├── *.apj      — Automation Studio project file
│   │   ├── *.acp      — Compiled automation component package
│   │   ├── *.br       — B&R runtime binary
│   │   ├── *.pc       — Program configuration
│   │   ├── *.obj      — Compiled object modules
│   │   ├── *.par      — Parameter/configuration files
│   │   ├── Hardware.hwl — Hardware configuration description
│   │   ├── Hardware.hw  — Hardware configuration binary
│   │   └── *.sys       — Additional system files
│   └── *.log          — Runtime and application log files
│
├── Mynte/             — Automation Runtime package directory
│   ├── X86/           — x86 architecture binaries
│   │   ├── APP/       — Application programs
│   │   │   ├── *.acp  — Compiled automation components
│   │   │   ├── *.br   — Runtime binaries
│   │   │   ├── *.obj  — Object modules
│   │   │   └── *.par  — Parameter files
│   │   ├── ACP/       — Automation Component Packages
│   │   ├── SYS/       — System modules
│   │   └── SAFETY/    — Safety application (Safe Series)
│   └── CONFIG/        — Configuration data
│
├── System/            — System-level files and drivers
│   ├── *.sys          — Kernel drivers
│   ├── *.dll          — Shared libraries
│   └── *.bin          — Binary components
│
├── Config/            — Configuration directory
│   ├── *.ini          — INI configuration files
│   ├── *.par          — Parameter files
│   └── *.xml          — XML configuration
│
├── Temp/              — Temporary files
│
├── Log/               — Runtime and application logs
│   ├── *.log          — Log files
│   └── SystemDump/    — System crash dump files
│
└── RAS/               — Remote Access Service files (optional)

Directory Path Variations by Controller Model

5. File Types and Their Purposes

Boot and System Files

Configuration Files

Program Files

Other Files

6. Boot Sequence — Stage by Stage

Stage 1: Power-On and BIOS POST (0–3 seconds)

Power On
  │
  ├─ CPU reset, x86 real-mode entry at 0xFFFF0
  ├─ BIOS POST: RAM test, CPU init, bus scan
  ├─ Detect CF card on IDE/CF interface
  ├─ Read CF card ATA identification data
  │    └─ Verify "Fixed Disk" flag (industrial cards only)
  ├─ Read MBR from CF card (sector 0)
  ├─ Parse partition table, find ACTIVE partition
  └─ Load first sector of active partition (VBR)

What happens: The x86 BIOS performs standard POST. It enumerates the CF card as an IDE drive. If the CF card does not report as a “Fixed Disk” (consumer cards typically report as “Removable”), the BIOS may skip it or fail to boot. The BIOS reads the MBR, identifies the active partition, loads the Volume Boot Record (VBR), which then loads the bootloader.

Stage 2: VxWorks Loader — VxLD (3–8 seconds)

VxLD 1.4.1 Loading...
  │
  ├─ Reads FAT filesystem from active partition
  ├─ Locates and loads VxWorks kernel image (vxWorks)
  ├─ Loads kernel symbol table (if present)
  ├─ Parses kernel boot parameters from brconfig.sys
  ├─ Initializes minimal hardware (CPU, RAM, interrupt controller)
  ├─ Transfers control to VxWorks kernel entry point
  └─ Display: "BR Automation Runtime B4.XX booting..."

What happens: The VxLD bootloader is the second-stage loader. It understands the FAT filesystem, reads the VxWorks kernel binary from the CF card, loads it into RAM, and jumps to its entry point. The VxLD version string (e.g., “VxLD 1.4.1”) appears on the display during this phase. If the bootloader cannot find the kernel, the system hangs here.

Stage 3: VxWorks Kernel Initialization (8–15 seconds)

VxWorks kernel startup
  │
  ├─ Kernel data structures initialization
  ├─ Memory subsystem initialization (MMU, virtual memory)
  ├─ Interrupt controller setup
  ├─ Timer initialization (system clock)
  ├─ Task scheduler initialization
  ├─ Load AR kernel modules (*.sys, *.dll from /System/)
  ├─ Initialize I/O subsystem
  ├─ Initialize file system drivers (FAT driver for CF access)
  ├─ Mount CF card partitions
  └─ Start Automation Runtime initialization

What happens: The VxWorks kernel initializes its core subsystems. B&R has extended VxWorks with custom task class scheduling, I/O management, abstraction layers, and drivers specific to their hardware platform. The kernel mounts the CF card filesystem(s) so that AR can access its configuration and programs.

Stage 4: Automation Runtime Initialization (15–25 seconds)

Automation Runtime initialization
  │
  ├─ Read brconfig.sys for system configuration
  ├─ Initialize task class scheduler
  │    └─ Task Class 1 (highest priority, cyclic)
  │    └─ Task Class 2
  │    └─ ...
  │    └─ Task Class N (lowest priority, background)
  ├─ Load and initialize hardware configuration (Hardware.hw)
  ├─ Scan and initialize hardware modules
  │    └─ CPU I/O modules
  │    └─ X2X bus modules
  │    └─ Fieldbus interfaces
  │    └─ Communication interfaces (Ethernet, etc.)
  ├─ Initialize network stack
  │    └─ Read IP configuration from .par or brconfig.sys
  │    └─ Configure Ethernet interface
  │    └─ Set hostname
  ├─ Initialize file devices
  │    └─ User partition mount point
  │    └─ FTP server
  │    └─ OPC UA server (if configured)
  └─ Enter INIT state

What happens: AR loads its configuration, sets up the real-time task class scheduler (a key B&R differentiator — task classes provide deterministic scheduling), initializes all hardware from the Hardware.hw configuration, and sets up networking. The system is now in the INIT state but no user programs are running yet.

Stage 5: User Program Loading (25–35 seconds)

User program loading
  │
  ├─ Locate program in active partition
  │    └─ Search path: /Flash/Project/ or /Mynte/X86/APP/
  ├─ Load compiled modules (*.acp, *.br, *.obj)
  ├─ Resolve library dependencies
  ├─ Link modules together
  ├─ Load parameter files (*.par)
  ├─ Initialize program data areas (retain persistent variables)
  ├─ Execute INIT routines (if configured)
  │    └─ User INIT code runs once
  └─ Start cyclic task execution

What happens: AR loads the compiled user program from the CF card. It reads the program configuration (.pc files) to determine which modules to load, loads the compiled binary modules (.acp, .br, .obj), and links them together. If the program was previously running and had persistent data, AR restores the retained data from the CF card. INIT routines run once (configurable), then the cyclic tasks begin.

Stage 6: RUN State (35+ seconds)

RUN state
  │
  ├─ All task classes running cyclically
  │    └─ Task Class 1: highest priority cyclic tasks
  │    └─ Task Class 2: ...
  │    └─ Background tasks (HMI update, communication)
  ├─ Network services active
  │    └─ Ethernet/IP
  │    └─ OPC UA
  │    └─ HTTP (SDM - System Diagnostics Manager)
  │    └─ FTP
  ├─ HMI visualization running (if applicable)
  ├─ LED indicators: RUN solid green
  └─ Ready for Automation Studio connection

Boot State LED Indicators

7. Runtime Operating States

B&R Automation Runtime has several operating states that the controller transitions through during boot and operation:

State Diagram

          ┌──────────────────────────────────────┐
          │           POWER ON                    │
          └──────────────┬───────────────────────┘
                         │
                         ▼
          ┌──────────────────────────────────────┐
          │           BOOT mode                   │
          │  (No CF card, or CF card not bootable)│
          └──────────────┬───────────────────────┘
                         │ CF card valid, AR loads
                         ▼
          ┌──────────────────────────────────────┐
          │           INIT state                  │
          │  (AR loaded, hardware initialized,    │
          │   user program loading)               │
          └──────────────┬───────────────────────┘
                         │ INIT routines complete
                         ▼
          ┌──────────────────────────────────────┐
          │           CONF / CONFIG state          │
          │  (System configured, tasks not started) │
          └──────────────┬───────────────────────┘
                         │ Configuration complete
                         ▼
          ┌──────────────────────────────────────┐
          │           RUN state                    │
          │  (All task classes executing normally) │
          └──────────────┬───────────────────────┘
                         │ Error detected
                         ▼
          ┌──────────────────────────────────────┐
          │           SERVICE mode                │
          │  (Task classes stopped,               │
          │   system accessible for diagnostics)  │
          └──────────────┬───────────────────────┘
                         │ Critical error
                         ▼
          ┌──────────────────────────────────────┐
          │           DIAG mode                   │
          │  (Diagnostic mode, AR boot failed)     │
          └──────────────────────────────────────┘

State Descriptions

• BOOT mode: The controller has power but could not load Automation Runtime. This means the CF card is missing, corrupted, not recognized, or the bootloader/kernel is damaged. The display may show “BOOT mode” text. No network services are available.

• INIT state: AR is loaded and initializing. Hardware modules are being detected and configured. This is a transient state during normal boot.

• CONF state: System is fully configured but tasks have not yet started. This state is brief during normal boot but can be entered during configuration changes.

• RUN state: Normal operating state. All user-defined task classes are executing cyclically. Network services are active. Automation Studio can connect and perform online changes.

• SERVICE mode: No task classes are running. Triggered by: runtime errors (divide by zero, cycle time violation, page fault, access violation), major transfer operations, or manual warm restart. The system is accessible via Ethernet (SDM at http://<IP>/sdm) and the logger is available for diagnostics. A warm restart exits service mode if the error condition is resolved.

• DIAG mode: Automation Runtime failed to boot correctly. Triggered by: corrupted CF card memory, kernel panic, or fatal hardware failure. More severe than service mode — AR is not fully operational.

How to Transition Between States

8. How AR Determines Which Program to Execute

Program Discovery Sequence

Automation Runtime follows a deterministic search order to locate and load the user program:

1. Read boot configuration from brconfig.sys — may specify an explicit program path
2. Check Hardware.hw for the program module list — the hardware configuration references the program components
3. Search standard directories in order:
   • /Flash/Project/ (Power Panel controllers)
   • /Mynte/X86/APP/ (X20 controllers including CP1584)
   • /Mynte/ACP/ (Automation PC controllers)
4. Load the .pc (Program Configuration) file — this is the entry point that defines the program structure
5. Load referenced modules (.acp, .br, .obj) as specified in the .pc file
6. Load parameter files (.par) for module configuration
7. Verify module integrity — checksums and version compatibility

Program-to-Hardware Binding

The program is tightly coupled to the hardware configuration:

• The .hw file describes the exact hardware topology (module types, positions, addresses)
• The .pc file references specific modules that expect certain hardware to be present
• If the actual hardware does not match the .hw configuration, AR will not enter RUN state
• This is why programs are hardware-specific and cannot simply be moved between different controller models

Runtime Archive (.rta) Loading

When using Automation Studio’s “Download Runtime to Target”:

• The .rta file contains all program modules + hardware config + AR system files
• AS writes these to the active partition of the CF card
• The system is configured to load from the newly written files on next boot
• The passive partition may be updated simultaneously for redundancy

9. Network Configuration Files

IP Address Configuration

Network settings are stored in multiple possible locations depending on the AR version and configuration method:

1. Hardware configuration (.hw / .par files): The primary location. When you configure the Ethernet interface in Automation Studio’s Physical View → CPU → ETH node, the IP address, subnet mask, and gateway are embedded in the hardware configuration.

2. brconfig.sys: May contain override network parameters.

3. Parameter files (.par): Can contain IP-related parameters that are applied at runtime.

Default Network Settings

Setting IP Without Automation Studio

1. Via SDM (System Diagnostics Manager): Access http://<current_IP>/sdm in a web browser. Navigate to network configuration and set static IP.

2. Via CF card: Mount the CF card, navigate to the project’s configuration directory, and edit the relevant .par file to change the IP address values. This requires understanding the binary or text format of the parameter file.

3. Via B&R Service Tool (RUC): Runtime Utility Center can set IP addresses during CF card generation.

4. Via Ethernet Setting Mode: On some X20 controllers, hold the RUN/STOP switch in a specific position during power-on to enter an Ethernet configuration mode where the default IP 192.168.100.1 is activated.

10. User Partition Structure

Purpose

The user partition (Partition 3) provides persistent storage for:

• User data files (recipes, configuration data, measurement logs)
• SystemDump files (crash dump data written after fatal errors)
• File device storage (arbitrary user files accessible via AR file functions)
• Application-generated data (CSV exports, data logging)

Setting Up the User Partition

The user partition must be configured to be usable:

1. During CF card creation: Automation Studio or Runtime Utility Center can create the user partition when generating the CF card.

2. Via Automation Studio: In the CPU configuration, set up a “File Device” that points to the user partition.

3. Programmatic: Use the AR FileDeviceCreate() function to define a file device pointing to the user partition.

File device mapping:
  User Partition → /USER/ (or configured mount point)
  Active Partition → /SYSTEM/

Important Notes

• RUC (Runtime Utility Center) cannot repartition an existing CF card. If no user partition exists, you cannot create one through RUC alone — you must recreate the CF card from scratch via Automation Studio’s “Generate Compact Flash” or “Offline Install” feature.
• The user partition survives program updates and AR updates (it is not overwritten during normal operations).
• SystemDump data is written to the user partition when configured via SysDump settings.

User Partition Directory Structure

/ (Root of User Partition)
├── data/              — User data files
├── recipes/           — Recipe data
├── logs/              — Application-generated logs
├── SystemDump/        — Crash dump files
│   ├── dump_XXXXX.sys — Individual dump files
│   └── ...
├── backup/            — User backups
└── *.csv, *.txt, etc. — Application data files

11. Imaging and Analyzing CF Card Contents

Method 1: dd (Linux)

Sector-by-sector imaging of the entire CF card:

# Create image from CF card
dd if=/dev/sdX of=/path/to/backup.img bs=512 status=progress

# Write image to new CF card
dd if=/path/to/backup.img of=/dev/sdX bs=512 status=progress

# Verify image integrity
dd if=/dev/sdX of=/dev/null bs=512 status=progress
md5sum /path/to/backup.img

# Create compressed image
dd if=/dev/sdX bs=512 status=progress | gzip > /path/to/backup.img.gz

Where /dev/sdX is the CF card device (verify with lsblk or fdisk -l).

Method 2: Win32DiskImager (Windows)

1. Download Win32DiskImager from https://win32diskimager.org/
2. Insert CF card via USB reader
3. Select the CF card drive letter
4. Click "Read" to create an image file
5. Click "Write" to restore an image to a new card

Method 3: HDD Raw Copy Tool (Windows)

1. Download from https://hddguru.com/software/HDD-Raw-Copy-Tool/
2. Select source CF card
3. Create .imgc (compressed raw image) file
4. Restore to target CF card

This tool is recommended by industrial automation technicians for CF card cloning.

Method 4: B&R Runtime Utility Center (Official)

1. Insert CF card into PC reader
2. Launch Runtime Utility Center (RUC)
3. Press F9 → "Generate Compact Flash"
4. Click "Select disk" → choose CF card
5. Click "Create image file from CF"
6. Image saved as .zp2 or .zp3 format

To restore:
1. RUC → Tools → Restore CF Card Image
2. Select .zp2/.zp3 file
3. Select target CF card
4. Write image

The .zp2/.zp3 format is B&R proprietary and contains metadata about the image in addition to the raw partition data.

Method 5: Automation Studio — Runtime Archive

1. Connect to controller via Ethernet
2. Transfer → Receive Runtime Archive from Target
3. Saves as .rta file

To restore:
1. Transfer → Download Runtime to Target
2. Select .rta file
3. Downloads to CF card via Ethernet (requires AR to be running)

Mounting and Analyzing CF Card Partitions (Linux)

# Identify CF card device
lsblk

# Mount active partition (first partition)
sudo mount /dev/sdX1 /mnt/cf_active -t vfat

# Mount user partition (third partition)
sudo mount /dev/sdX3 /mnt/cf_user -t vfat

# Explore
ls -laR /mnt/cf_active/
ls -laR /mnt/cf_user/

# Examine partition table
sudo fdisk -l /dev/sdX
sudo parted /dev/sdX print

# Hexdump MBR
sudo dd if=/dev/sdX bs=512 count=1 | xxd

# Extract individual files
cp -r /mnt/cf_active/Flash/ /tmp/flash_backup/

12. Modifying Boot Parameters Without Automation Studio

Editing Configuration Files Directly on the CF Card

1. Remove CF card from controller (power down first!)
2. Mount on PC using a CF card reader
3. Navigate to the configuration directory
4. Edit the relevant file with a text or hex editor:

IP Address in Parameter Files

Location: /Flash/Project/ or /Mynte/X86/APP/
File: *.par (parameter file, may be text or binary)

If text format, edit IP address values directly.
If binary format, use a hex editor to locate and modify IP octets.

Boot Configuration in brconfig.sys

Location: / (root of active partition)
File: brconfig.sys

This file may be binary or text. If text, edit boot parameters directly.
Common parameters include:
  - Default boot partition
  - Kernel boot arguments
  - Memory allocation settings
  - Driver initialization options

Changing the Active Boot Partition

Use fdisk (Linux) or diskpart (Windows) to toggle the ACTIVE flag:
  
  Linux: sudo fdisk /dev/sdX → use 'a' command to toggle boot flag
  Windows: diskpart → select disk → select partition → active
  
Then swap partition contents between active and passive partitions
to boot from the updated partition.

Warnings

• Always backup the CF card before editing — a single corrupted byte can prevent booting.
• Do not edit binary files with a text editor — use a hex editor.
• Verify file checksums after editing if available.
• Test on a spare CF card first if possible.

13. Changing the Loaded Program Binary Manually

Method 1: Copy Program Files to CF Card

If you have a compiled program (from Automation Studio or from another working controller):

1. Backup the existing CF card (dd image)
2. Mount the active partition on a PC
3. Navigate to the program directory:
   • X20: /Mynte/X86/APP/
   • Power Panel: /Flash/Project/
4. Replace the program files:
   • Copy new .acp, .br, .obj, .pc files
   • Copy matching .hw and .hwl files (hardware must match!)
   • Copy matching .par parameter files
5. Safely eject the CF card
6. Insert into controller and power on

Method 2: Swap Active/Passive Partition

If the passive partition already contains the desired program (e.g., from a previous update):

1. Use fdisk/diskpart to make the passive partition active
2. Boot the controller — it will now load from the formerly-passive partition
3. Verify program operation

Method 3: Replace Individual Modules

AR loads modules individually based on the .pc file. You can:

1. Identify which .obj module corresponds to which program function
2. Replace individual .obj files on the CF card
3. Keep the .hw and .pc files unchanged (unless hardware changed)
4. Boot and verify

Critical Constraints

• The hardware configuration (.hw) must match the physical hardware exactly. If you copy a program from a CP1584 to a CP1484, it will fail.
• Library modules must be compatible with the AR version on the CF card.
• The .pc file references modules by name — renamed or missing modules will cause load failure.
• Persistent/retained variables may cause unexpected behavior if the data layout changed.

14. Backup and Restore Procedures

Backup Methods (Ranked by Completeness)

1. Full CF Card Image (Most Complete)

# Linux
dd if=/dev/sdX of=/backup/cp1584_backup_$(date +%Y%m%d).img bs=512 status=progress

# Also backup MBR separately for safety
dd if=/dev/sdX of=/backup/mbr_backup.bin bs=512 count=1

This captures everything: MBR, partition table, all partitions, bootloader, OS, program, user data.

2. Runtime Utility Center Image (.zp2/.zp3)

RUC → F9 → Generate CF → Create image file from CF

Creates compressed image with B&R metadata. Recommended official method.

3. Runtime Archive (.rta)

Automation Studio → Transfer → Receive Runtime Archive from Target

Captures the compiled runtime (program + hardware config + system files) but NOT the bootloader or partition structure. Requires Ethernet connection to a running controller.

4. Individual File Backup

1. Mount CF card
2. Copy entire directory tree:
   - /Flash/ or /Mynte/ (program and configuration)
   - /Config/
   - brconfig.sys, VxLD, boot.ini
   - All .apj, .acp, .br, .pc, .obj, .hw, .hwl, .par files
   - Log files
3. Note: this misses the MBR, partition table, and bootloader

Restore Procedures

Restoring a Full Image

# Verify target card is correct!
lsblk
# Write image
dd if=/backup/cp1584_backup.img of=/dev/sdX bs=512 status=progress

CRITICAL: The target CF card must be identical in capacity or larger, and must be an industrial-grade card with the bootable flag.

Restoring via RUC

RUC → Tools → Restore CF Card Image → select .zp2/.zp3 → select target disk

Restoring via Automation Studio

1. Create a new project for the target hardware
2. Transfer → Download Runtime to Target → select .rta
3. This requires AR to already be running on the target

Best Practices

• Always create backups after any program change
• Store original Automation Studio project files (.pkg) in version control (Git, SVN)
• Keep multiple backup copies: full image (.img), RUC image (.zp3), and runtime archive (.rta)
• Label CF cards with controller serial number and backup date
• Schedule periodic CF card replacement every 3-5 years (industrial cards have finite write endurance)
• Never remove CF card while controller is powered on

15. CF Card Corruption and Missing Card Scenarios

Missing CF Card

Symptoms:

• Display shows: “no boot device present, halting”
• No LED activity
• No network connectivity
• Controller is completely non-functional

Resolution: Insert a valid CF card and perform warm restart.

Corrupted Boot Sector / MBR

Symptoms:

• Display shows: “Attempting to boot a Hard Drive… VxLD 1.4.1” then hangs
• Continuous reboot loop
• No progress beyond bootloader stage

Cause:

• Improper shutdown (power loss during write)
• CF card wear-out (exceeded write cycle limit)
• Physical card damage
• Corrupted partition table

Resolution:

1. Remove CF card and create a sector-by-sector backup using dd or HDD Raw Copy
2. Attempt to repair using fdisk or test disk tools
3. If repair fails, restore from backup image
4. If no backup exists, recreate CF card from scratch (see Section 16)

Corrupted File System

Symptoms:

• Boot progresses past VxLD but AR fails to start
• Controller enters DIAG mode
• Display shows: “BOOT mode: Diagnosis” or “BOOT mode: Service”
• Runtime error messages in log files

Cause:

• Power interruption during file write
• Excessive write cycles degrading flash cells
• File system metadata corruption

Resolution:

1. Mount CF card on PC and check file system integrity
2. Copy off all readable files
3. Run filesystem check: fsck.vfat -a /dev/sdX1
4. If repairable, restore missing/corrupted files from backup
5. If not repairable, restore from full image backup

Corrupted User Program

Symptoms:

• AR boots successfully (past INIT state)
• Controller enters SERVICE mode after attempting to run user program
• Cycle time violations or page fault errors in logger

Cause:

• Program file corruption (power loss during download)
• Incompatible program version
• Missing library modules

Resolution:

1. Connect via Automation Studio or SDM to read error logs
2. Re-download the program from Automation Studio
3. If no AS project available, restore from .rta backup

Intermittent Boot Failures

Symptoms:

• Sometimes boots successfully, sometimes fails
• Random reboots during operation

Cause:

• Failing CF card (intermittent bad sectors)
• Loose CF card connector
• Failing card reader pins

Resolution:

1. Reseat CF card firmly
2. Replace CF card (clone first)
3. Inspect card reader pins for damage

16. Creating a Bootable CF Card from Scratch

Method 1: Automation Studio — Generate Compact Flash (Recommended)

This is the official and most reliable method.

1. Open Automation Studio
2. Create a new project or open existing project
3. Configure hardware (Physical View) to match the target controller:
   - Add the correct CPU module (X20CP1584)
   - Configure I/O modules matching physical hardware
   - Configure Ethernet interface (set IP address)
4. Build the project (Ctrl+Shift+B)
5. Online → Create Configuration → select "Compact Flash"
   OR
   In Automation Studio, use "Transfer" → "Download to Target"
   with a CF card connected via USB reader
6. Automation Studio writes:
   - MBR and partition table
   - Active partition with bootloader, AR, program
   - Passive partition (if configured)
   - User partition
7. Verify the card boots in the target controller

Method 2: Automation Studio — Offline Install

For larger systems where CF card is too small for the full AR installation:

1. In Automation Studio: Tools → Offline Install
2. Select target AR version
3. Create installation media on CF card or USB stick
4. Insert into controller and boot — AR installs from media

Method 3: Manual Creation (Advanced, Not Recommended)

Creating a CF card from scratch without Automation Studio requires:

1. Industrial CF card with bootable flag
2. Bootloader binary (VxLD) — must match target AR version
3. AR kernel and modules — from B&R service pack or extracted from backup
4. Hardware configuration (.hw, .hwl) — matching physical hardware
5. User program files (.acp, .br, .obj, .pc) — compiled and matching

# Create partition table
sudo fdisk /dev/sdX
  # Create 3-4 primary partitions
  # Set partition 1 as ACTIVE (bootable)
  # Partition 1: FAT16, ~200MB (or more for larger programs)
  # Partition 2: FAT16, ~200MB (passive/backup)
  # Partition 3: FAT16/FAT32, remaining space (user)

# Format partitions
sudo mkfs.vfat -F 16 /dev/sdX1
sudo mkfs.vfat -F 16 /dev/sdX2
sudo mkfs.vfat -F 16 /dev/sdX3

# Mount and copy files
sudo mount /dev/sdX1 /mnt/cf
# Copy bootloader, kernel, AR modules, hardware config, program
sudo cp VxLD /mnt/cf/
sudo cp brconfig.sys /mnt/cf/
sudo cp -r System/ /mnt/cf/
sudo cp -r Mynte/ /mnt/cf/
sudo cp -r Flash/ /mnt/cf/
sudo cp -r Config/ /mnt/cf/
sudo umount /mnt/cf

# Install bootloader to MBR/VBR
# (This is the tricky part — requires the correct VBR with
#  VxLD chain-loading code, which is specific to B&R's setup)

Method 4: Clone from Working Card

If you have a working CF card:

# Full sector-by-sector clone
dd if=/dev/sdX of=/dev/sdY bs=512 status=progress

The target card must be identical capacity and industrial-grade.

17. Safe Boot Modes and Recovery Options

Warm Restart (Controlled Restart)

• Trigger: Automation Studio command, SDM web interface, RUN/STOP switch
• Effect: AR shuts down gracefully, saves persistent data, restarts from CF card
• Use for: Recovering from SERVICE mode, applying configuration changes

Cold Restart (Power Cycle)

• Trigger: Physical power off → wait → power on
• Effect: Full hardware reset, complete boot from scratch
• Use for: Clearing transient errors, full system restart

BOOT Mode Recovery

When the controller is in BOOT mode (no AR loaded):

1. Check CF card insertion — reseat the card
2. Verify CF card is industrial-grade with bootable flag
3. Connect via serial console (if available) for diagnostic output
4. Replace CF card with known-good backup
5. Use Runtime Utility Center to create a new CF card from backup image

SERVICE Mode Recovery

When the controller is in SERVICE mode:

1. Access SDM at http://<IP>/sdm — available even in SERVICE mode
2. Open Logger in Automation Studio or SDM to identify the error
3. Review backtrace to find the code location that caused the fault
4. Common causes:
   • Cycle time violation (code stuck in loop or blocking IO in fast task)
   • Page fault / access violation (writing beyond array/string bounds)
   • Divide by zero
   • Library module incompatibility
5. Fix the code in Automation Studio, re-download
6. Warm restart to exit SERVICE mode

DIAG Mode Recovery

When the controller is in DIAG mode:

1. CF card corruption is likely — the AR kernel failed to fully initialize
2. Remove CF card and create a backup (dd image) before attempting repair
3. Restore from known-good backup image
4. If no backup, recreate CF card from scratch using Automation Studio
5. Check for hardware problems — damaged card reader, CPU failure

Emergency Recovery via USB

Some newer B&R controllers support automatic AR installation from USB:

1. Create a USB flash drive (FAT16/FAT32) with AR installation files
2. Download AR service pack from B&R website (www.br-automation.com)
3. Extract to USB drive
4. Insert USB into controller
5. Power on — AR detects USB and offers to install

Recovery via Serial Console

For advanced debugging:

1. Connect serial console cable to controller's serial port
2. Terminal settings: 57600 baud (factory default), 8N1, no flow control. If no output appears, try 9600 or 115200.
3. Boot output includes detailed VxWorks kernel messages
4. Can access VxWorks shell for low-level diagnostics

Key Findings

• Consumer CF cards will not work even with identical partition data cloned onto them — the BIOS requires the ATA “Fixed Disk” flag that only industrial-grade cards (B&R 5CFCRD series) set; the boot hangs at “VxLD 1.4.1” indefinitely on consumer cards.
• The boot sequence has 6 distinct stages from BIOS POST through VxLD bootloader loading, VxWorks kernel init, Automation Runtime initialization, user program loading, to full RUN state — failures at different stages point to different root causes (hardware vs. OS vs. application).
• The A/B (Active/Passive) partition scheme provides fail-safe updates — firmware and program updates are written to the passive partition first; on reboot the system switches to it only if valid, falling back to the old active partition if the new one fails, which prevents bricking during updates.
• The SYSTEM partition must contain at minimum: VxLD bootloader, brconfig.sys (master AR configuration), the VxWorks kernel, Hardware.hw (compiled hardware topology), and the compiled user program (.acp/.br/.pc/.obj files) in /Mynte/X86/APP/ for X20 controllers.
• Boot parameters (IP address, kernel arguments) can be modified without Automation Studio by mounting the CF card on a PC and editing .par files or brconfig.sys — but always image the card first since a single corrupted byte prevents booting, and binary files require a hex editor, not a text editor.
• The hardware configuration (.hw) is tightly coupled to the physical I/O topology — programs cannot be moved between different controller models or different I/O configurations without matching the .hw file to the actual hardware, or AR will refuse to enter RUN state.
• Four imaging methods are available ranked by completeness: (1) full sector-level dd image captures everything including MBR, (2) Runtime Utility Center .zp2/.zp3 with B&R metadata, (3) Automation Studio .rta runtime archive (misses bootloader and partition structure), (4) individual file copy (misses MBR and partition table).
• Runtime Utility Center cannot repartition an existing CF card — if you need a user partition that doesn’t exist, the entire card must be recreated from scratch via Automation Studio’s Offline Installation.

18. Cross-References

19. Sources

B&R Official Documentation

• B&R Automation Runtime Overview and Setup (TM213) — https://www.br-automation.com
• B&R Automation Studio Quick Start (MASYS2ASQS) — https://instrumentacionycontrol.net
• B&R BIOS Upgrade Documentation — https://www.br-automation.com/en/downloads/industrial-pcs-and-panels/power-panel-100200/bios-upgrade/
• B&R Automation Runtime Product Page — https://www.br-automation.com/en-us/products/software/automation-runtime/

B&R Community Forum Discussions

• “How to get PLC to go from boot mode to run mode?” — https://community.br-automation.com/t/how-to-get-plc-to-go-from-boot-mode-to-run-mode/5866
• “Configuration Files deleted in CF card” — https://community.br-automation.com/t/configuration-files-deleted-in-cf-card/8210/11
• “The OS behind AR” — https://community.br-automation.com/t/the-os-behind-ar/3303
• “User Program trigger Execution of Init and Exit Routine” — https://community.br-automation.com/t/user-program-trigger-execution-of-init-and-exit-routine/3718
• “Arsim fails to boot” — https://community.br-automation.com/t/arsim-fails-to-boot/1638
• “CF Card stops functioning once variable is changed” — https://community.br-automation.com/t/cf-card-stops-functioning-once-variable-is-changed/2827
• “Creating a CF Card With Files From Mapp Backup” — https://community.br-automation.com/t/creating-a-cf-card-with-files-from-mapp-backup/1987
• “USER partition not creating” — https://community.br-automation.com/t/user-partition-not-creating/4654
• “Service Mode - What is it and how to collect diagnostics” — https://community.br-automation.com/t/service-mode-what-is-it-and-how-to-collect-diagnostics/1613
• “How can I save SystemDump data on the user partition” — https://community.br-automation.com/t/how-can-i-save-systemdump-data-on-the-user-partition-of-the-cf-card/2454
• “Shipping CompactFlash Card” — https://community.br-automation.com/t/shipping-compactflash-card/2033
• “CPU x20cp1584 cannot find target” — https://community.br-automation.com/t/cpu-x20cp1584-cannot-find-target/5019

Third-Party Technical Resources

• Industrial Monitor Direct: “B&R PCMCIA CF Card Backup and Restore Procedure” — https://industrialmonitordirect.com/blogs/knowledgebase/br-pcmcia-cf-card-backup-and-restore-procedure
• Industrial Monitor Direct: “B&R Power Panel 400 CF Card Boot Failure and Program Backup Procedures” — https://industrialmonitordirect.com/blogs/knowledgebase/br-power-panel-400-cf-card-boot-failure-and-program-backup-procedures
• Industrial Monitor Direct: “Uploading B&R Project from CF Card in Automation Studio” — https://industrialmonitordirect.com/blogs/knowledgebase/uploading-br-project-from-compact-flash-card-in-automation-studio
• Industrial Monitor Direct: “How to Backup B&R CF Card Using Runtime Utility Center” — https://industrialmonitordirect.com/blogs/knowledgebase/br-cf-card-backup-using-runtime-utility-center
• DMC Inc: “B&R Automation — Changing Automation Runtime Configurations” — https://www.dmcinfo.com/blog/26437/br-automation-changing-automation-runtime-configurations/
• B&R Process Control: CF Upgrade Instructions — https://www.process-control.com/wp-content/uploads/b-r-cf-upgrade-instructions.pdf

Community Forum Discussions (PLCTalk, Reddit)

• PLCtalk: “Do B&R Industries Power Panel 300 work only with specific models of CF cards?” — https://www.plctalk.net/forums/threads/do-b-r-industries-power-panel-300-work-only-with-specific-models-of-cf-cards.145986/
• PLCtalk: “B&R X20 service mode” — https://www.plctalk.net/forums/threads/b-r-x20-service-mode.91845/
• PLCtalk: “B&R CP476 upload” — https://www.plctalk.net/forums/threads/b-r-cp476-upload.55486/page-3
• Reddit r/PLC: “B&R PLC Program Loading” — https://www.reddit.com/r/PLC/comments/1amxzp6/br_plc_program_loading/
• Reddit r/PLC: “B&R 5PC600 5X02-00 Boot Mode: Diagnosis, Service” — https://www.reddit.com/r/PLC/comments/nd94vw/br_5pc600_5x0200_boot_mode_diagnosis_service/

Technical References

• Scribd: Runtime Utility Center Overview — https://www.scribd.com/document/938093397/03-RuntimeUtilityCenter-V4-7-10-6-2016-EN
• VxWorks Boot Process (general reference) — https://medium.com/@knownsec404team/analysis-of-vxworks-boot-process-and-overflow-testing-599897fb862b
• HDDGURU Raw Copy Tool — https://hddguru.com/software/HDD-Raw-Copy-Tool/
• Win32DiskImager — https://win32diskimager.org/

Document generated from research across B&R official documentation, community forums, and third-party technical resources. Some details are inferred from VxWorks general behavior and B&R community knowledge — verify against your specific AR version and hardware manual.

Related Documents

• firmware.md — B&R firmware architecture, AR version landscape, memory layout, and firmware update mechanisms
• bootloader-recovery.md — Recovery procedures when the CF card is corrupted or the PLC won’t boot
• config-file-formats.md — Detailed format reference for every configuration file on the CF card
• ar-rtos.md — Automation Runtime OS internals including VxWorks boot process and security vulnerabilities
• ftp-web-interface.md — FTP-based remote access to CF card contents for backup and diagnostics
• cp1584-forensics.md — Extracting information from a running CP1584 without project files
• access-recovery.md — Gaining initial access to an undocumented PLC, including CF card backup procedures
• execution-model.md — Task class scheduling and how task configuration is loaded from CF card
• memory-map.md — CPU memory regions including how CF card partitions map to the address space
• retentive-data.md — Battery-backed SRAM data preservation during CF card swaps and cold restarts
• project-reconstruction.md — Rebuilding an AS project from CF card contents
• diagnostics-sdm.md — Using SDM to monitor CF card health and boot errors
• cp1584-hardware-ref.md — CP1584 physical interfaces, CF card slot, and hardware specifications
• online-changes.md — How CF card persistence works when making online changes to running programs
• spare-parts.md — Sourcing replacement CF cards and certified media
• remanufacturing.md — Migration from CF-card-based CP1584 to SD-card-based newer controllers