The PIC18F6680 is the 64 KB member of the ECAN family (DS30491C): 3,328 bytes of RAM, 1,024 bytes of EEPROM, a parallel slave port and hardware CAN 2.0B in a 64-pin TQFP or 68-pin PLCC. Microchip has marked it Not Recommended for New Designs, but the installed base is large and automotive — which is where its protection layout matters most.
One bit of difference from the 6585
The 6680 divides its 64 KB like this: a 2 KB boot block (0x0000–0x07FF), Block 0 from 0x0800 to 0x3FFF (14 KB), then 16 KB blocks — 0x4000–0x7FFF, 0x8000–0xBFFF, and 0xC000–0xFFFF — under CP1, CP2 and CP3. All four CP bits exist. On the 48 KB PIC18F6585, CP3 is unimplemented because the block it would govern does not exist.
So a checker that assumes CP3 is always a phantom — or always real — is wrong on one of the two parts. The device ID at 0x3FFFFE resolves it, and it is readable no matter how the part is locked. A 6680 with only CP3 set returns 48 KB of firmware and a final 16 KB of zeros; the zeros disassemble into no-ops, because 0x0000 is a legal instruction, and nothing in the file complains. The per-block report is what turns that file into a statement: everything present except Block 3, which is code-protected rather than empty.
What the firmware holds
A 6680 image is a CAN node’s brain. The bit-timing registers are loaded from constants compiled at build time, which derive from the oscillator setting in the config words at 0x300000 — outside the array, carried by type-04 hex records that some tools drop. A rebuild with the config words missing runs on the bench and then samples every bit at the wrong point on a live bus. The 40 MHz ceiling means the timing budget is tight; this is the same failure mode the PIC18F4580 shows on its smaller CAN die.
The acceptance filters and message IDs are firmware data too, so they are in the array. The node’s identity — its address, its per-unit trim — is in the EEPROM.
The EEPROM half
The 1,024 bytes at 0xF00000 sit under their own CPD bit, independent of the four flash blocks. On automotive CAN nodes this is where the node address and calibration live. A clone with a correct flash image and a blank EEPROM either answers to nobody or answers to the same address as the original — and two nodes with one address on a shared bus is a fault that takes hours to trace back to a half-finished copy. Flash and EEPROM belong in one deliverable from the start.
Assessment
Sequence: ID first; array to 0xFFFF with a four-block report; config words; EEPROM attempt. Where the whole array is locked, the die-level routes on the services page apply, and the readout protection guide maps the read patterns to protection states. The deliverable: 65,536 array bytes ending at 0xFFFF, twelve config bytes, 1,024 EEPROM bytes, the ID — and a block report that used four bits, because on this part all four are real.
Two reads, and the package
The 6680 arrived in 64-pin TQFP and 68-pin PLCC, and the package shapes the first attempt. Socketed PLCC units come off the board in seconds, which makes the initial read — ID, four-block attempt, EEPROM attempt — a bench job with no extraction risk. Soldered TQFP units may route the programming pins to a header, in which case the same sequence happens in place; where they do not, the removal is fine-pitch work and the damaged-package question stops being hypothetical. On the file side, the check that matters is per-block: the four CP bits give the 6680 sixteen possible protection states, and the read report should name which of the four ranges returned firmware and which returned zeros. A report that says only “locked” has discarded information that the block map makes available for free.