A PIC18F2685 copy succeeds or fails on four things, and only one of them is the program. The flash image, the config words, the data EEPROM and a blank device of the right revision all have to be correct. Most failed clones reported as “the copy did not work” turn out to be a config word or a missing EEPROM block, not a bad read.
The PIC18F2685 is the top of its family: 96 KB of enhanced flash — 49,152 instruction words — with 3,328 bytes of SRAM and 1,024 bytes of data EEPROM, in a 28-pin SPDIP or SOIC package, carrying the same ECAN module as the rest of the group. It is the part designers reached for when 64 KB was not enough and 128 KB was not needed.
What 96 KB Looks Like as a File
In Intel HEX, a 96 KB image is 6,144 data records of 16 bytes, plus extended linear address records to span the address space, plus the two config regions that sit outside flash entirely:
| Region | Start address | Content |
|---|---|---|
| Program flash | 0x000000 |
98,304 bytes of code and constant tables |
| Config words | 0x300000 |
Oscillator, watchdog, brown-out, protection state |
| Data EEPROM | 0xF00000 |
1,024 bytes of calibration and counters |
| Device ID | 0x3FFFFE |
Revision identifier |
A file missing the middle two rows will program cleanly and will not behave like the original. There is no error message for that — the programmer does not know what was supposed to be there.
The Config Words Decide Whether the Copy Runs at All
The oscillator setting is the usual offender. A device configured for a high-speed crystal and copied into a blank part with default internal-oscillator settings will run, badly, at the wrong speed — which shows up first as a communications failure rather than as a dead board.
Watchdog, brown-out threshold, low-voltage programming and the protection bits themselves all travel with the image. Copying protection state onto a clone is a common mistake: it makes the new part as locked as the original and no easier to service later. A deliberate copy should normally be written with protection cleared.
The 0x014000 Line, and When a 2682 Can Take Over
The 80 KB PIC18F2682 shares this device’s peripherals and pinout; only the flash size differs. That makes one very practical check worth doing before a 2685 is treated as unobtainable.
If the extracted image ends below 0x014000 — 81,920 bytes — and no code, table or interrupt vector sits above that line, the application fits a 2682 unchanged. In that case the cheaper and more available part runs the same firmware, with the config words and EEPROM copied across as usual.
If the image runs past 0x014000, the substitution is not available and the options narrow to recovering another 2685 or re-engineering the overflow.
When Copying Is the Wrong Answer
Three situations where a copy will not solve the problem:
- The behaviour has to change. A copy reproduces the original, including the bug that made you open the unit.
- No blank parts exist. A hex file with nothing to program it into is not a production plan, and second-source silicon with a different mask revision can differ in peripheral errata.
- The image is incomplete. A read that stopped at a protected block produces a file that appears to program and then fails at one specific function.
In those cases the useful deliverable is a read plus a disassembly, not a copy. MCU extraction covers both outcomes, and the decision usually becomes clear once the image size and the config words are known.
Practical Sequence
Read the original, verify the record count and checksum, confirm the vector table resolves, capture the EEPROM byte-for-byte, then program a blank device with protection cleared and run it against the original on the same harness. Comparing behaviour on the bench is the only test that matters.
If the unit is still in production and the design house is gone, start with the marking photograph and the ordering suffix. Extract firmware can begin under NDA before any file is transferred, and the services page sets out exactly what comes back.