GCU v3 Debugging

This page covers the v3 GCU only — the current-generation black-box unit with a native CAN connection to the ECU. It runs firmware 4.0.0 and later, distributed as .bin files.

How to tell if you have a v3: it’s obvious at a glance. A v3 is a small flat box with a single plastic harness connector, about the size of two decks of cards. The older GCUs are much larger — a grey rectangular box with two metal (Amphenol) connectors, roughly the size of a large coffee can. If you’re not sure, connect with the GCU Flasher and check the version (the flasher prints it automatically on connect, or send GET_VERSION in the console) — a v3 reports firmware 4.x. A v3 also has a single multicolor status LED instead of the separate red/yellow/green diagnostic LEDs on older boards, and its firmware releases contain .bin files rather than .hex.

Caution

If your GCU runs firmware 3.x or earlier (.hex files, three separate diagnostic LEDs), this page does not apply — see Updating GCU Firmware and Shift Debugging instead. The mechanical and pneumatic troubleshooting on the Shift Debugging page (valve block, linkage, compressor hardware) still applies to every car.

The v3’s wiring is different from the older GCUs — don’t use the original GCU wiring diagram to trace a v3. A dedicated v3 wiring diagram is coming; it hasn’t been published yet. For general shift-harness electrical reference in the meantime, see Shift Harness and GCU.

What the v3 Adds

The v3 is a significantly more capable unit than the older GCUs, thanks to its native CANBUS link to the ECU. Feature highlights:

• Money-shift prevention — blocks a downshift that would over-rev the engine.
• Auto-downshift — coordinated downshifts without a paddle pull for each gear.
• Automatic failed-shift retries and logging — a shift that doesn’t complete is retried and recorded, so the event is in the log.
• Additional AiM channels — the richer CAN data is exposed to the dash (see below).
• Neutral relocation below 1st (optional) — moves the neutral position under 1st gear.

Because the v3 speaks CANBUS, its logs are much richer than the older boards’ — the heartbeat, shift traces, and failure records below all carry data that only exists on a CAN unit.

Note

KLine (Gen1) cars: the v3 will support KLine, but that path isn’t out yet — it will need an adapter box, and as currently scoped it won’t have most of the v3’s smart features (money-shift prevention, auto-downshift, and the like), which depend on the CAN data. We may attempt to decode KLine directly, but that likely won’t happen. The one way to get the smart features on a KLine car is to have the AiM dash rebroadcast the vital channels on CAN2 for the v3 to read.

AiM Dash Channels

To see the v3’s extra channels on the dash, the AiM configuration needs to be updated. A release is coming in aim-configs and can be merged into your dash config through the AiM Config Merge tool. The config release hasn’t shipped yet — check back for it.

Status LED Quick Reference

The v3 carries all its status on one multicolor LED. Highest-priority active pattern wins:

Pattern	Meaning
Solid color during a shift	Shift in progress (green = upshift, red = downshift, cyan = N→1)
Fast amber flash	Fallback gear source — no valid gear data; shifts run time-based with safety gates off. Investigate.
Slow red blink (1 Hz)	Flash safe mode — logging disabled after repeated boot failures. Racing unaffected. Power cycle (unplug, not RESET) to retry; contact Rush Auto Works if it persists.
Fast yellow flash	Compressor running (normal during 70–90 PSI refills)
Slow cyan-blue breathing	Idle heartbeat — healthy
White flash, 300 ms on/off, forever	Fatal init error — the reason is printed on serial. The board needs attention.

Flashing Firmware

You need a laptop and a USB cable to the GCU.

1. Download the latest 4.x (.bin) release zip from the GCU firmware releases and unzip it. Each zip contains the firmware files, the GCU Flasher app, and the flashing tool — no installation required.
2. Connect the GCU to your computer via USB.
3. Open the GCU Flasher:
   • macOS: double-click GCU Flasher.app
   • Windows: double-click GCU Flasher.bat
4. Select the correct firmware from the dropdown:
   • Gen2 (CAN / drive-by-wire): release_CAN_feather-X.X.X.bin
   • Gen1 (KLine / throttle cable): release_KLine_feather-X.X.X.bin
5. Select your serial port (click Refresh if it doesn’t appear).
6. Click Flash Firmware and confirm. The GCU reboots into bootloader mode automatically.
7. Wait for “Flash complete!” in the log.

Note

If flashing fails, double-tap the small RESET button on the GCU’s controller board to enter bootloader mode manually, then try again. Not sure which generation your car is? Gen1 cars have a throttle cable at the pedal box; Gen2 cars have an accelerator pedal sensor (no cable).

Caution

If the flasher offers a diag firmware file, don’t race on it — diagnostic builds disable the watchdog and are for bench troubleshooting only.

Pulling Logs over USB

The v3 logs everything it does to USB serial and to onboard flash. The flash logs survive power cycles, so you can pull a whole weekend’s worth of shift history back in the paddock.

Capturing a log

1. Connect the GCU via USB and open the GCU Flasher.
2. Click View Console to connect to the serial output at 115200 baud. Live lines start streaming immediately.
3. In the Diagnostics tab, click Dump Exception Log (failures only — start here) and/or Dump Rolling Log (everything). Large dumps take a few seconds. You can also type the commands DUMP_EXCEPTIONS and DUMP_ROLLING directly into the command input below the console.
4. Click Save Log to write the full console buffer to a timestamped text file. The flasher also offers to save on disconnect.

For a quick health summary without a full dump, send DUMP_STATUS — it reports the last reset cause, uptime, flash health, and CAN status in one shot.

Note

Bench gotcha: with the engine off, the GCU holds recent log records in RAM and hasn’t flushed them to flash yet. Before a bench DUMP_ROLLING, send UNLOCK_ACCESS CONFIRM and then FLUSH_LOGS in the command input, or the latest records won’t appear in the dump.

What’s in the log file

A saved capture mixes four kinds of lines:

1. Live telemetry — 1 Hz HB (heartbeat) and AIM lines plus per-shift SHIFT/VALVE/COUNT traces, stamped with uptime [HH:MM:SS.mmm].
2. Flash log records — the DUMP_ROLLING/DUMP_EXCEPTIONS output, stamped with raw milliseconds like [1297638], plus a wall-clock time when the AiM dash had a GPS fix.
3. Command responses — OK ..., ERR ..., VERSION ..., framed by BEGIN/END.
4. Boot banners and warnings — RESET_CAUSE, WARN ....

Multiple sessions in one dump

The flash log keeps one numbered file per boot, so a DUMP_ROLLING can contain several sessions back-to-back, separated by --- SESSION N --- markers. Within a session, watch for the [ms] counter resetting to a small number — that’s a new boot. The flasher’s Sessions button does this splitting for you: it fetches the flash log, lists each session with its start time and an anomaly flag, and lets you preview or save individual sessions. That per-session export is exactly what you want to hand to the maintenance assistant.

Crash and reboot triage

If a log just stops mid-shift and then shows a boot banner, the GCU reset. The RESET_CAUSE line (also in DUMP_STATUS) tells you why: 0x01 power-on means the supply collapsed — classically a voltage sag when a shift solenoid fires; 0x20 WATCHDOG means the firmware hung; 0x04/0x08 are brownouts; 0x40 is a clean commanded reboot. Repeated power-on resets mid-shift point at wiring/ground, not firmware — check the shift harness power and ground paths.

Using the Live Debugger

When the console is connected, the flasher expands into a live control panel with three tabs — Live Data, Diagnostics, and Configuration — next to the scrolling console log. Filter checkboxes (HB, SHIFT, PADDL, VALVE, Other) let you hide line types you don’t care about; the saved log always keeps everything.

The heartbeat (HB) line

Once per second the GCU prints a health snapshot:

[00:01:49.001] HB phase=0 shifting=0 g=2 cg=2 src=GP rpm= 8190 psi=  81 nt_mode=MOTO drop=00000 pdrop=00000 ghosts=00000 doubles=00000 rpmv=1 gearv=1 ...

The Live Data tab parses this into a dashboard, but the raw line is worth knowing. The essentials:

• g= / cg= — current gear from the GCU’s gear-position sensor vs. the ECU over CAN. They should agree; 255 means unknown.
• src= — active gear source. GP is healthy; FALL means no gear data at all (safety gates off — matches the amber-flashing LED).
• rpm= and psi= — engine RPM via CAN and tank pressure. Pressure should sit in the 70–90 PSI compressor band.
• Error counters (drop, pdrop, ghosts, doubles, bo, emi) — all should be zero and stay zero. Growing ghosts= or emi= points at electrical interference on the paddle wiring; any bo= (CAN bus-off) points at a CAN wiring fault.

AIM lines are the dash side of the picture — wall-clock time from the dash’s GPS, speed, throttle, and brake data at 1 Hz. If there are no AIM lines at all, the dash is off or the CAN link between dash and GCU is down.

Watching the compressor and tank pressure

Watch psi= across consecutive HB lines: it should climb while the compressor runs (yellow-flashing LED) and stop at ~90 PSI. A compressor that cycles rapidly or never shuts off shows up plainly in this trace — then follow the pneumatic leak-hunting steps in Shift Debugging, which apply to every generation.

Per-shift traces

Every shift gets a correlation ID (#00042) that appears on every related line, so you can follow one shift from paddle pull to completion:

[00:04:12.101] SHIFT #00042 start   src=USER dir=DOWN from=3 tgt=2 rpm= 7100 psi= 78
[00:04:12.103] VALVE #00042 DOWN HIGH cmdr=SHIFT
[00:04:12.165] SHIFT #00042 gchange g=2 at=  62ms
[00:04:12.167] SHIFT #00042 success from=3 to=2 in=  64ms
[00:04:12.243] SHIFT #00042 complete total= 142ms

A failed shift prints SHIFT #NNNNN fail with the gear it actually landed in (landed=0 is the classic false-neutral case). In the flash records, look for event names like SHIFT_CL_TIMEOUT, MISSHIFT_RETRY, GEAR_MISMATCH, and PRESSURE_CRIT — these failure events are the story; the SHIFT_OK records are the background.

Command protocol basics

Commands are plain text, newline-terminated, typed into the input field below the console. Read commands are always accepted:

Command	What you get
DUMP_STATUS	Reset cause, uptime, flash and CAN health
DUMP_EXCEPTIONS / DUMP_ROLLING	Failure-only log / full rolling log
LOG_STATS	Log file sizes and counters
GET_VERSION / GET_CONSTS / GET_STATE	Firmware version, all runtime tunables, live state

Write commands (test shifts, tunable changes, clearing logs) require enabling write access first — the Enable Write Access button in the Diagnostics tab (it sends UNLOCK_ACCESS CONFIRM). Access auto-locks after 5 minutes. The Configuration tab then lets you view and adjust the runtime tunables with range validation; Save to Flash persists changes across power cycles.

Caution

Don’t change tunables speculatively. Pull the logs first, identify the actual failure signature, and change one thing at a time — or let Rush Auto Works look at the log.

Have the Maintenance Assistant Read Your Logs

You don’t need to interpret any of the above yourself. The owner maintenance assistant on rushautoworks.com knows the v3 log format — heartbeat fields, shift traces, flash records, failure signatures — and can walk a log with you.

1. Pull the log as described in Pulling Logs over USB. Use the Sessions button to save just the session where the problem happened.
2. Open the assistant: Owner Maintenance Assistant in the Driver Toolbox.
3. Tell it you have a v3 GCU and that you have the logs in hand — it will otherwise walk you through pulling them first.
4. Paste the relevant excerpt: the session around the fault, not the whole file. Include the boot banner and VERSION line if you have them, plus the lines around the failed shift or reset.
5. Describe what the car did (“missed the 2→1 downshift into T5, ended up in neutral”) — the assistant matches your description against the failure events in the log and cites the manual pages for any follow-up procedure.

Related Pages

• Shift Harness and GCU — pin-level electrical reference and interactive wiring diagrams
• Shift Debugging — symptom-based troubleshooting for the pneumatic and mechanical shift system (all generations) and older GCU boards
• Updating GCU Firmware — firmware releases and flashing for pre-v3 GCUs