Connection & Detection

This page covers what happens when pcu cannot detect the hardware, refuses a command the platform does not support, or loses the connection. pcu detects your platform automatically from the board identity and validates it before any write, so these messages are how it fails safely rather than guessing.

”This hardware is not supported.”

pcu did not recognise the machine as a supported vehicle PC, so it connects to nothing rather than risk writing to an unknown MCU. The GUI splash shows:

This hardware is not supported.

Detected board: <manufacturer> / <product>

See supported systems on the Home or About page.

From a terminal, pcu-cli prints the board and CPU it read, then the list of platforms it does support:

ERROR: Could not auto-detect platform.
  Board: <manufacturer> / <product>
  CPU:   <cpu>

Supported platforms:
  ...

Detection is deliberately fail-closed: an unrecognised board is never driven. See Supported Platforms for the boards pcu supports.

1. Confirm the machine is an In-CarPC CQ20 or CQ40 series unit.
2. If it is, send the exact Board and CPU strings above, plus the vehicle PC model, to In-CarPC support so the board identity can be added.

”… are not available on …” (feature not available)

pcu recognised and validated the hardware, but you asked for a feature the platform does not have. Asking for ignition timers on a CQ40:

ERROR: Ignition timers are not available on In-CarPC CQ40 series.

Asking for digital I/O on a CQ20:

ERROR: Digital I/O is not available on In-CarPC CQ20.

These exit with code 2 (feature not available), which is distinct from a general error, so a script can tell them apart. Ignition timers are CQ20 only; digital I/O is CQ40 only. In the GUI the matching sidebar page is greyed out with a tooltip. See Supported Platforms for the full capability matrix.

”Connection to MCU hardware was lost.”

The GUI polls the MCU every 5 seconds. If a poll fails, it drops the connection, stops the live dashboards, and shows in the sidebar:

Connection to MCU hardware was lost.

On the Ignition and Digital I/O pages an in-progress action may instead report Connection lost.

1. Check the vehicle PC power and the MCU cabling.
2. Click Retry in the sidebar to reconnect.
3. On Windows, if the PawnIO driver was removed, a Driver Setup button also appears; use it to reinstall the driver, then retry. See Windows Issues.

A write could not be verified

Every write is read back to confirm it took effect. If the readback does not match, pcu warns and the command exits with code 1. An ignition timer that the MCU clamped:

  WARNING: Wrote 300 but read back 250. MCU may have clamped the value.

A digital output that did not change:

  WARNING: Set DO1 to High but read back Low.

1. Retry the command once. A single bus glitch usually clears.
2. If the value keeps reading back wrong, it may be outside the range the MCU accepts, or the channel’s wiring may be faulty. Note the exact warning and contact In-CarPC support.

The bus is held by another tool

pcu shares the standard system-bus locks with other low-level utilities so they do not clash on the hardware. If another tool (for example HWiNFO) is holding the bus, pcu waits up to 5 seconds and then fails cleanly rather than forcing its way in. On a CQ20:

ERROR: Timed out waiting for SMBus mutex.

On a CQ40:

ERROR: Timed out waiting for the ISA-bus mutex.

1. Close the other tool that reads hardware sensors or buses (HWiNFO and similar).
2. Retry the command.

The PC will not restart after a software shutdown

You shut the vehicle PC down from the operating system (rather than by turning the ignition off), and now it will not power back on until you cycle the ignition. This is expected behaviour of the CQ20 ignition module, not a fault.

The ignition input is edge-triggered, so the PC waits for the ignition to switch off and on again before it will start. The full explanation and the caution are on Ignition Timers.