Fault Codes

The device continuously monitors its own configuration, its inputs and outputs, and the CAN buses it is attached to. When something is wrong it raises a fault — a structured record that can be read back with the configuration software or the data logger.

This page documents every fault the firmware can currently raise, what triggers it, and what to check when you see one.

Step-by-step diagnostic procedures for the precisely-defined codes are on the companion page: Fault diagnostics.

Related pages: CAN bus diagnostics, Configuration concepts, Common IO settings, Working with the CAN bus.

How a fault is structured

Every fault is reported as five fields plus an optional parameter list:

The Component ID is the most useful field for diagnosis — the Fault ID tells you what kind of problem occurred, the Component ID tells you where. Its meaning depends on the fault and is listed for every code in the tables below.

Fault IDs are shown in hexadecimal throughout this page, matching the configuration software display. The first digit of the Fault ID corresponds to its category, so a code is unambiguous on its own.

Fault modes

Monitored signals use a debounce before a fault is confirmed: the fault appears first as Intermittent, and is promoted to Continuous only if the condition is still present some time later. A brief glitch therefore shows up as Intermittent and never escalates.

The debounce period depends on the subsystem. Input watchdog and sensor supply faults escalate after roughly 200 processing cycles. CAN entity frame timeouts count missed frames instead, and escalate once more than six consecutive frame periods have been missed.

Configuration faults skip the debounce entirely — they are raised directly as Continuous, because a configuration is either valid or it is not.

Active and inactive faults

When a monitored condition clears, the fault is not deleted. It is moved to Inactive so the event remains visible after the fact — this is what lets you find an intermittent wiring problem that was present during a drive but is gone by the time the vehicle is on the bench.

The configuration software reports the two counts separately, as Faults active/inactive.

Fault lifecycle

A fault is identified by the combination of Category + Fault ID + Component ID. Raising the same combination twice does not create a second entry — the existing entry is updated. Two different inputs failing the same way therefore produce two separate faults, which is what you want when tracing a harness problem.

Important operational notes

• Faults are held in RAM and are lost on power-down. They are not written to non-volatile memory, so a fault list must be read while the device is still powered from the session you are diagnosing. Cycling the ignition clears the list.
• The fault table holds 32 entries. Once 32 distinct faults are present, further faults are discarded until the table is cleared. A badly broken configuration can fill the table on its own during startup and mask later run-time faults — fix configuration faults first, then re-check.
• Clearing removes everything, both active and inactive entries. Active conditions are re-raised on the next processing cycle, so after a clear, any fault that comes straight back is a live problem.

Reading and clearing faults

Both PC applications read faults over the same device link:

• Configuration software — the Faults view polls the device roughly five times per second while it is open and shows Type, Category, Fault ID, Component ID and Mode, plus a description. Clear faults empties the table.
• Data logger — shows the same list as severity-coded cards, with a Read and a Clear all action.

Neither application resolves a fault code without this page: the description column is populated from a lookup table that is currently empty, so codes are displayed numerically. Use the tables below to interpret them.

Fault categories

Categories 17 (dual-clutch controller) and 18 (transmission) are defined in the protocol but are not raised by the current firmware — see Reserved codes.

Category 1 — Configuration faults

Configuration faults mean a requested element could not be applied. They are always Continuous. The affected element is not created — an input that failed to configure produces no value, and an output that failed to configure does not drive anything.

Most of these are raised once, while the configuration is being parsed at startup. The exception is the map tuner group (0x0035, 0x0036, 0x0039), which is raised at run time when the tuning tool requests a cell or variant that does not exist in the map — those appear while you are editing, not at startup.

These are the faults to resolve first: everything downstream depends on the configuration being valid.

Inputs

When the Component ID is 0, the fault does not identify which element failed — check every input of that type in the configuration.

Outputs

Unassigned mandatory elements

The transmission drivers check their mandatory inputs, outputs and maps when the configuration is applied, and raise these when one is missing. This is the most common fault on a first install — the driver refuses to run and the transmission will not engage a gear.

The mandatory sets differ per driver, and vehicle speed is mandatory on the PDK gateway but not on the 8HP one: 8HP · PDK.

Calibration

Calibration faults mean the device's stored calibration does not match the configuration being loaded — usually a configuration built for a different hardware variant.

If several of these appear together, the device is running a configuration intended for different hardware. Verify the device variant before continuing.

Maps and map tuners

See Scaling and maps for axis requirements.

CAN configuration

These faults mean a CAN element could not be attached to a bus. The usual root cause is a single mistake: a frame, input, output or preset assigned to a CAN channel that is not enabled in the configuration. Enable the bus, or move the element to a configured one.

Category 2 — Input watchdog faults

The input watchdog checks configured inputs against their expected range while the device is running, and reports the input by ID. It is inhibited while the ignition input is low or the battery voltage is below 8 V, so cranking does not generate spurious faults.

Every fault in this category carries the Input ID as its Component ID — for an analog or frequency input. A CAN bus input can also have a fault window, and its faults land in this category too, but the identifier they carry is not set from the configuration, so it does not point back at the channel. Identify those from the fault window you configured and what the datalogger was showing.

The four frequency codes monitor the DC voltage on the input pin, not the measured frequency — a frequency value that is simply wrong raises nothing. The distinction between an out of range fault (0x0101, 0x0102, 0x0111, 0x0112) and a short fault (0x0103, 0x0104, 0x0113, 0x0114) is how far the reading is from the valid band. A short fault is raised when the value is pinned at a supply rail, which points at the harness rather than at the sensor's calibration. Out-of-range limits come from the fault minimum and maximum you set on the input — see Common IO settings.

Category 3 — Output watchdog faults

Output faults are detected by the current-controlled and voltage-controlled output drivers. The Component ID is the output pin number.

Both are detected during the output adaptation phase that runs after ignition-on, and resistance monitoring is only performed when it has been enabled for that output.

Category 4 — System faults

System faults concern the device itself rather than the configuration. All are raised with Component ID 0.

Sensor supply

While either fault is active, input range checking is suspended — with a bad reference every analog reading would be wrong, so the input watchdog would otherwise raise a fault on every sensor at once. Fix the supply first; input faults can only be assessed once it is back in range.

Stored data

0x03F3 is informational after a firmware update or a first power-up. If it returns on every start, the storage is failing or power is being removed before the device finishes writing.

Category 32 — CAN entity faults

A CAN entity (or preset) is a packaged integration with a specific ECU or transmission — it knows which frames to expect and which to send. These faults report problems with that traffic. See Working with the CAN bus.

For 0x2001, the Component ID is the preset's own frame index, not the CAN identifier — which frame that is depends on the preset in use. Confirm with a CAN analyzer which expected frame is absent; see CAN bus diagnostics.

Category 33 — CAN bus faults

These come directly from the CAN controller's error state, and describe the physical bus rather than the message content. The Component ID is the CAN channel number.

For 0x210B, the Component ID is encoded as (0x100 × channel) + stage, where the stage indicates how far initialisation progressed. Report the raw value when raising a support request.

The practical order of interpretation is: 0x2107 first, since a bus with no acknowledging node produces it constantly and cascades into the others; then 0x2101/0x2104, which indicate the bus has already degraded; then the individual bit and frame errors, which point at wiring and termination. Each error type maps to a physical cause in CAN bus diagnostics.

Quick reference — first checks by category

Reserved codes

The following codes are defined in the device protocol but are not raised by the current firmware. They are listed so that the numbering is documented and so a code seen in a protocol capture can be identified. Seeing one of these in the field is not expected.

Output short-circuit conditions (0x0201, 0x0202) are still protected against in hardware — the driver's protection acts whether or not a fault code is raised. What is absent is the diagnostic report, not the protection.

Limitations of the current implementation

Known constraints, so that fault data is not over-interpreted:

• Faults are not stored across power cycles. Read them in the same power session in which the problem occurred.
• The table is limited to 32 entries, after which new faults are silently dropped.
• No timestamps or occurrence counts. A fault records that a condition occurred, not when or how often.
• Additional parameters are not transmitted. The protocol reserves a parameter list for measured values, but the device does not currently send one; only the five identification fields are available.
• Inactive faults are not distinguished per occurrence. A condition that comes and goes repeatedly appears as one entry in its most recent state.