Inside the CANdi startup path

The CANdi application is executable

The Tech2Win MSI contains candi.bin, a 65,544-byte addressed download containing a 64 KiB CANdi application image. Its instructions are Motorola 68000-family code. Our second CPU executes that application and exchanges native startup, information, inventory and baud-change messages with the Tech2 CPU.

This is a bounded application-entry experiment; it does not establish complete boot-ROM or physical CANdi board emulation. Firmware and vendor binaries are not included in this publication.

Where the native path stops

Following the Tech2-to-CANdi serial request 88 0E 6A, the firmware selects native channel 0. The inferred controller window is 0x202000. Before requesting transmission, its GPIO latch changes 0x27 → 0x24 → 0x26; assignment is 0x00 and direction is 0x7F.

CAN TX intent controller=2 native_channel=0 bus=SingleWire
electrical=single-wire-gpio latch=0x26 assignment=0x00 direction=0x7f
wake_control_selected=true board_mapping=unverified
id=0x00000100 extended=false rtr=false dlc=0 data=[]
btr0=0xdd btr1=0x36 external_tx=false

The write to 0x202001 stops at the missing backend. There is one controller TX intent and no TX confirmation. These GPIO values describe virtual registers; their physical transceiver mapping is still unverified. An empty ID 0x100 frame alone does not preserve electrical wake-up behavior.

Transmission requests now retain their GPIO snapshot even if firmware later changes the latch. The console distinguishes GPIO writes, TX intent and matching transport completion. The Nano high-speed profile rejects unknown or single-wire electrical states instead of silently routing them onto high-speed CAN.

What the older USB captures actually establish

We reassembled the Chipsoft streams across USB transfer boundaries before comparing diagnostic messages. A USB transfer is not necessarily one complete adapter message.

The update used offline analysis. No captured sequence was replayed to a vehicle. Raw captures, VINs, keys and proprietary firmware are not redistributed here.

Wake-up, the bench, and the missing bridge

GM's GMW3110 (2010), §§5.1–5.2.7 and 6.1, describes single-wire high-voltage wake-up using ID 0x100, a 500 ms allowance after wake-up, and an initial diagnostic virtual-network interval of at least eight seconds. That is network-management context, not a universal diagnostic-response timeout.

We did not obtain a complete standalone GMW3104 edition. GMW3110's discussion references GMW3104 version 1.5; applicability of later timing rules to this older Saab card still needs verification. The J2534 header defines SW_CAN_HV_TX = 0x00000400, but that definition alone does not prove Nano hardware or DLL support.

Saab's 2004 9-3 WIS bus description distinguishes ignition-powered 500 kbit/s P-bus from the approximately 33 kbit/s I-bus, which the CIM wakes. Our direct bench ECM reads succeeded. Whether the guest's wider vehicle-selection workflow requires additional modules remains unresolved; the current stop occurs before any physical wake-up transmission.

Use the command catalog as an evidence map

OpenSAAB's menu-action YAML definitions already connect menu paths with request/response IDs, service bytes, timing and capture references. The next comparison is to annotate the emulator's observed traffic against those definitions, preserving the source and confidence of each label.

The ignition-status entry is a useful candidate for investigation, but it is not yet shown to be the guest's startup sequence. Its notes disagree about prior security access. Module/address descriptions also need their vehicle and menu context; a catalog entry is not a substitute for a matched raw trace.

What would move this forward

1. Capture the missing Nano startup behavior. Original Tech2Win ECU Information on an identified vehicle, with adapter setup, pin selection, wake-up mode and timestamped requests/replies. A VIN-redacted trace with model year, engine family and adapter/driver version is useful.
2. Verify each physical bus. Match the native GPIO intent to documented or measured transceiver behavior and confirmed adapter capabilities. Chipsoft USB envelopes cannot simply be sent to a Nano.
3. Connect the persistent transport. Keep queue acceptance, driver TX confirmation and ECU response distinct. Preserve native flow control and timeout/cancellation behavior.
4. Prove the original page. Success means ECU Information populated through the guest's own receive path. Then validate the same transport boundaries for macOS and Android USB implementations.