How GhostTune handles ECU changes

Changing an ECU value is more than editing a number on a screen. GhostTune keeps temporary changes, permanent storage, communication control, and verification as separate parts of one guarded workflow.

Temporary Write and Permanent Burn are different actions

GhostTune does not treat every saved edit as a permanent change. It presents two distinct choices:

• Temporary Write changes the active ECU value for the current powered session. The change does not survive an ECU power cycle.
• Permanent Burn stores the supported change in retained ECU memory so it remains after a power cycle.

Keeping these actions separate lets a user evaluate a supported change temporarily before deciding whether it should be retained.

The active ECU profile controls what can be written

GhostTune uses the detected ECU profile to determine addresses, data sizes, scaling, option definitions, and write capability. It does not reuse another profile’s constants when the active profile is unknown or unsupported.

If the required profile or capability is not available, the write path remains locked rather than guessing.

What happens during a supported change

1. The current data is already known. GhostTune begins from values read from the active ECU profile rather than from an assumed default.
2. Live polling is paused. Normal live-data traffic is coordinated so it does not continue through the write sequence.
3. The requested value is written. The change uses the active profile’s defined storage location and encoding.
4. A permanent request adds the burn step. Temporary Write stops after the active value is changed; Permanent Burn continues through the profile’s guarded burn sequence.
5. The changed data is read again. GhostTune re-reads the relevant ECU data after the operation.
6. The result is verified. The value read back is compared with the requested value before the app reports the operation as complete.
7. Polling resumes. Normal live communication returns after the guarded operation finishes or exits.

Why read-back verification matters

Sending a command does not, by itself, prove that the ECU accepted and retained the expected value. A connection interruption, rejected response, unexpected data, or hardware problem can prevent the requested result.

GhostTune therefore re-reads the affected data and checks the returned value. A mismatch is reported as a mismatch rather than being presented as a successful write.

What happens when the sequence is interrupted

If communication does not complete normally, GhostTune stops the operation, reports the detected condition, and uses its recovery and stale-data handling rather than silently assuming success.

This does not eliminate every possible risk. Power loss, wiring faults, ECU faults, firmware behavior, and other hardware conditions can still affect an operation. A known-good backup and a safe working environment remain essential.

A practical way to use the workflow

• Keep a known-good tune backup before making live changes.
• Use Temporary Write when evaluating a supported adjustment that should not yet survive a power cycle.
• Use Permanent Burn only after confirming that the change is intended to remain.
• Do not bypass a locked or unsupported profile path.
• Treat a reported mismatch or interruption as unresolved until the ECU state is confirmed.

Why the workflow is intentionally conservative

GhostTune’s goal is not to make every ECU operation available under every condition. Its write paths are enabled only where the required profile information and guarded operation are present. Unsupported operations remain unavailable until they can be validated independently.