The most common way a PIC18F2682 code extraction fails is not by returning nothing. It is by returning a file that is 95 percent correct — one block short, with the missing range filled by the constant the programmer hands back for protected cells. The image looks like firmware, loads without complaint, and dies at the first call into the gap.
80 KB is an awkward size to work with, and that is where the trouble starts. This part carries 40,960 instruction words of enhanced flash, 3,328 bytes of SRAM and 1,024 bytes of data EEPROM, in a 28-pin package, with the same ECAN block found on the rest of the family.
Why 80 KB Behaves Differently From 64 KB
A 64 KB image fills four equal protection blocks exactly. An 80 KB image does not: the top block is only partly populated, and the protection bits do not necessarily cover the same fraction of the array as the code does.
At 16 bytes per Intel HEX record, a full 80 KB image is 5,120 data records. Any read that comes back with a clean multiple of a block size, rather than 5,120 records plus the config region, deserves a second look before it is trusted.
Self-Programming Is the Second Source of Holes
The PIC18F2682 writes to its own flash under software control. In practice that means many boards ship with a bootloader sitting in low memory and the application linked to start above it — a layout chosen by the linker script, not by the datasheet.
Two consequences follow. First, the boundary between bootloader and application is invisible from outside: you cannot tell where one ends by looking at the package. Second, a field-updated unit may hold an application that is newer than the bootloader, or a bootloader that was never revised. Both have to come out contiguously or the reassembled image will not run.
A dump assembled without that boundary in mind often looks convincing in a hex viewer — vectors present, code present, padding at the end — while the jump from bootloader into application lands in filler.
How Completeness Is Proven
Extraction is only half the job; the other half is demonstrating the file is whole. Four checks do most of the work:
- Filler scan. Every 64-byte block is tested for the constant returned on protected cells. Inside a region that should hold code, a run of it is a hole.
- Vector table. The reset vector at
0x0000and the interrupt entries at0x0008and0x0018must all resolve inside the image, not past its end. - Record count and checksum. 5,120 records for a full flash plus the config and EEPROM regions; the extended linear address records must cover the whole span.
- Disassembly continuity. Branch targets are followed across the image. A branch into filler is a hole that the hex file itself will not reveal.
Chip extraction analysis is where these checks live, and where a failed read gets caught before it reaches a customer.
The EEPROM Is Part of the Code
1,024 bytes of data EEPROM on this part usually holds the values the application cannot compute: sensor trim, serial number, accumulated runtime, the last known actuator position. A unit that comes back from a program memory read-out without its EEPROM will boot and misbehave in ways that look like a code bug.
The EEPROM is also the cheapest thing to recover. On devices where CPD is left clear, it can be read through the normal programming interface without any package work at all — worth checking before anything is opened.
Family Notes
The 28-pin PIC18F2480 shares the ECAN block and the same 28-pin footprint with half the flash, so a read-out there follows the same sequence with a smaller record count. Where an application fits in 40 KB, that part is often the practical replacement when a 2682 cannot be sourced.
If the board is already on the bench, send the marking photograph and the ordering suffix. Extract firmware work is quoted against the actual device, not the family — see the services page for what a delivered image contains.