Page Switching & Calibration Concepts - Calibration & XCP Protocol

Two-Page Model: Working vs Reference

Two-Page Calibration Memory Model

  Segment 0 (calibration data segment)
  ┌──────────────────────────────────────────────────────┐
  │  Page 0: WORKING (RAM)                               │
  │    IDLE_RPM_TARGET = 850   ← engineer modified       │
  │    ign_timing[16×16] = {...modified map...}          │
  ├──────────────────────────────────────────────────────┤
  │  Page 1: REFERENCE (Flash/NvM)                       │
  │    IDLE_RPM_TARGET = 800   ← OEM released value      │
  │    ign_timing[16×16] = {...original map...}          │
  └──────────────────────────────────────────────────────┘

  ECU algorithm reads from "active page" (SET_CAL_PAGE selects)
  Tool always writes to working page via DOWNLOAD
  Use SET_CAL_PAGE to switch ECU between pages mid-session
  Use SET_CAL_PAGE to switch tool-side view independently

SET_CAL_PAGE Mode Byte	Meaning	Use Case
0x01	ECU reads from specified page	Switch ECU algorithm between reference and working
0x02	XCP master (tool) accesses specified page	Switch tool UPLOAD to read reference values
0x80	Apply to all segments simultaneously	Switch all calibration segments at once

SET_CAL_PAGE Command in Detail

Pythonset_cal_page_demo.py

import inca_com as inca

# --- Compare working vs reference mid-session ---

# 1. Read current working page value (ECU using working page)
working_val = inca.GetCharacteristic("IDLE_RPM_TARGET")
print(f"Working page: {working_val} rpm")  # → 850 (modified)

# 2. Switch TOOL-side access to reference page (ECU still uses working)
inca.SetCalPage(segment=0, page=1, mode=0x02)  # tool-side only

# 3. Read reference page value via XCP UPLOAD
reference_val = inca.GetCharacteristic("IDLE_RPM_TARGET")
print(f"Reference page: {reference_val} rpm")  # → 800 (original)

# 4. Switch tool back to working page
inca.SetCalPage(segment=0, page=0, mode=0x02)

# 5. Now switch ECU algorithm to use reference page (live compare!)
inca.SetCalPage(segment=0, page=1, mode=0x01)  # ECU switches to reference
import time; time.sleep(5.0)  # observe ECU running on original map
print(f"ECU using reference: actual_rpm = {inca.GetMeasurement('actual_idle_speed')}")

# 6. Switch ECU back to working page
inca.SetCalPage(segment=0, page=0, mode=0x01)

COPY_CAL_PAGE: Promote or Reset

COPY_CAL_PAGE Operation	Source	Destination	Effect
Promote working → reference	Page 0 (working/RAM)	Page 1 (reference/Flash)	Saves current session changes to Flash (triggers Flash write)
Reset working from reference	Page 1 (reference/Flash)	Page 0 (working/RAM)	Discard all session changes, restore from Flash baseline

Hexcopy_cal_page_commands.txt

/* Promote working to reference: */
Tx: EC 00 00 01 00  /* COPY_CAL_PAGE: src_page=0(working), dst_page=1(reference) */
Rx: FF              /* Flash write complete (ECU may delay up to 200ms) */

/* Reset working from reference (discard bad calibration): */
Tx: EC 01 00 00 00  /* COPY_CAL_PAGE: src_page=1(reference), dst_page=0(working) */
Rx: FF              /* RAM immediately reset to reference values */

Init-on-Reset: NvM Shadow RAM Option

By default, an ECU reset reloads the working page from Flash reference — all unsaved working-page changes are lost. Some ECUs implement an NvM shadow RAM option: the working page is additionally saved to NvM on power-down and reloaded on startup, preserving inter-session changes without needing explicit COPY_CAL_PAGE to Flash.

Init Mode	Working Page on Reset	Flash Endurance Impact	A2L Declaration
Standard (Flash reference)	Reinitialised from Flash reference	None — no Flash write on reset	(default)
NvM shadow RAM	Loaded from NvM copy of working page	NvM write on every reset	SEGMENT capability attribute: INIT_DIRECTION = SLAVE_ONLY
No reinit (static RAM)	Retained if power not lost	None	Rare — used on battery-backed SRAM

Summary

The two-page model gives calibration engineers a safe sandbox (working page RAM) with a validated baseline (reference page Flash) always reachable via COPY_CAL_PAGE reset. SET_CAL_PAGE enables live A/B comparison between reference and working maps mid-session — a critical diagnostic tool for evaluating whether a calibration change actually improved vehicle behaviour.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.