The workflow creates one consistent contract between the generated Linux application, the A2L file, the HEX image, and calibration tools. This prevents a common failure mode in which application, A2L, and data set are from different builds.
Build flow
- Generic ERT generation: the model is generated with
HardwareBoard=Noneandert.tlcin an unsaved configuration. - Transactional staging: generated model sources, XCPlite headers/sources, build glue, and an explicit manifest are staged into a dedicated temporary tree.
- Local cross-compilation: the selected profile compiler builds the Linux target ELF. The ELF architecture is validated before artefacts are generated.
- Runtime split: the unstripped ELF remains available for DWARF/A2L processing. A stripped runtime ELF is used for deployment and the virtual flash image.
- Calibration package: A2L, complete Intel HEX, and INCA ProF files are generated from the same resolved configuration and EPK identity.
XCP runtime responsibilities
| Subsystem | Responsibility |
|---|---|
| XCPlite TCP server | Connect, DAQ, upload/download, memory-page handling, and programming services. |
| Model scheduler | Runs generated model task functions with configured affinity and real-time priority. |
| Calibration segment | Maintains working and reference parameter pages. The active page is copied into the model parameter structure once per base-rate step. |
| A2L generator | Uses ELF/DWARF information and generated-code metadata to export valid addresses, XCP memory segments, events, and calibration objects. |
| Virtual flash service | Stages a programmed executable, verifies it, then atomically swaps the runtime on a complete transfer/reset. |
EPK and rebuild discipline
The EPK is the shared software identity. After every rebuilt application, import the matching A2L and HEX. Do not combine an old A2L with a new runtime or use a HEX from a different build. The workflow creates an EPK automatically; Epk should only be overridden when a controlled identity is required.
Measurement events and multi-rate models
The generated runtime discovers model tasks and exposes one XCP DAQ event per task. A multi-rate model therefore has rasters such as Task_1ms and Task_10ms, instead of forcing all signals into a single rate. For accurate rate mapping, use multitasking generation and keep task periods as integer multiples of the base rate.
Default diagnostics
The A2L includes runtime diagnostics in addition to Simulink test-point measurements: cycle_count, overrun_count, exec_time_us, cpu_usage_coreN_permille, and cpu_temperature_mdegC. Use these signals when tuning CPU allocation or diagnosing overloaded DAQ traffic.
Practical implication
The offline build produces files that are ready for review and import before hardware is available. Hardware validation remains essential for Linux userspace compatibility, pin mapping, Ethernet throughput, scheduling jitter, XCP connection, and flash/restart behaviour.