MultiPROG-Ultimate-Kit/04_Workflows/EEPROM_READ_WRITE_WORKFLOW.md

EEPROM Read/Write Workflow

Purpose

Safely read and, where authorized, write EEPROM contents on an automotive module (ECU/BCM/immobilizer/instrument cluster) while preserving recoverability at every step.

Prerequisites

• Confirmed authorization for the specific vehicle/module (see 07_Authorized_Key_Immobilizer_Work/README.md if immobilizer-relevant data is involved).
• Exact EEPROM part number and package (identified visually or via schematic/service reference) — memory size and pinout vary by part family.
• Spare, known-good bench power supply with current limiting.
• Multi-PROG (or equivalent) with a device/adapter entry matching the exact part; confirm the "supported" indicator (see 01_Knowledge_Base/README.md → "Checksum strategy") rather than assuming compatibility from a similar part number.

Required adapters

• In-circuit clip or socket adapter matching the EEPROM package (e.g. SOIC8, TSSOP8, DIP8 — package varies by part).
• If desoldering is required: appropriate rework station and ESD protection; note desoldering as a higher-risk path with its own recovery burden if the part is damaged.

Wiring references

• Use the adapter/tool manufacturer's official pinout documentation for the specific clip/socket model in use; this repository does not maintain a general pinout table since it is adapter- and part-specific and changes across hardware revisions.
• Confirm orientation (pin 1 marking) before applying power — reversed orientation is a common cause of part damage.

Safety notes

• Never power the EEPROM in-circuit and out-of-circuit simultaneously.
• Use current-limited bench supply on first power-up of any in-circuit read to catch a short before it damages the part.
• Keep the module's original harness connections photographed/documented before disconnecting (per 04_Workflows/AUTHORIZED_REPAIR_WORKFLOW.md intake step).

Procedure (maps onto the baseline workflow)

1. Intake — record authorization, module identity, exact EEPROM part number.
2. Acquisition — two independent reads, byte-for-byte compared, SHA-256 recorded (see 03_Script_Starter_Kit/examples/02_double_read_verifier.mjs).
3. Development — work on a copy; maintain an explicit allow-list of writable offsets (see 03_Script_Starter_Kit/examples/04_allowlisted_patch_demo.mjs).
4. Validation — verify size, blank regions outside the allow-list are untouched, and checksum where applicable.
5. Release — write only after validation passes; save the original read under a preserved filename before writing anything back.

Common failures

• Wrong part/package selected in the tool's device list, producing a read that is the wrong size or all-blank/all-0xFF.
• Clip misalignment causing an intermittent read that differs between the two required reads (this is exactly what the dual-read check is designed to catch — do not proceed if reads differ).
• Write interrupted mid-cycle (power loss, clip slip) leaving the part in a partially-written, inconsistent state.

Recovery procedures

• If a write is interrupted or verification fails: do not attempt another write from the same (possibly corrupted) working copy. Re-read the module first to establish its actual current state, then restore from the last known-good backup.
• Always keep the original pre-write backup and at least one prior known-good backup, named with case ID/module/region/date, per 04_Workflows/AUTHORIZED_REPAIR_WORKFLOW.md → "Release".
• If the part appears bricked (reads as all-blank/garbage after a failed write and does not respond normally), the module is a candidate for the same "bench reading" recovery path documented in 04_Workflows/BENCH_AND_BOOT_READING_WORKFLOW.md, or physical EEPROM replacement/reprogramming with a known-good backup.

Related documents

• 01_Knowledge_Base/AUTOMOTIVE_MEMORY_CONCEPTS.md
• 17_MultiPROG_SDK/docs/EEPROM_API.md
• 17_MultiPROG_SDK/templates/template_eeprom.mjs
• 07_Authorized_Key_Immobilizer_Work/GODIAG_XHORSE_HARDWARE_REFERENCE.md — example bench-adapter hardware