The PIC18F6585 is the 48 KB member of the ECAN family (DS30491C): 3,328 bytes of RAM, 1,024 bytes of data EEPROM, a parallel slave port and hardware CAN 2.0B in a 64-pin TQFP or 68-pin PLCC. Its code protection is close to the 40-pin CAN parts but not identical, and the difference is a trap for anyone checking a dump with the wrong template.
The block map — and the missing bit
The array runs 0x0000–0x0BFFF: a 2 KB boot block at the bottom, Block 0 from 0x0800 to 0x3FFF (14 KB), then Block 1 (0x4000–0x7FFF) and Block 2 (0x8000–0xBFFF) at 16 KB each. CP0 through CP2 cover them. CP3 appears in the register map but is unimplemented on the FX585 members — the physical block it would govern, 0xC000–0xFFFF, does not exist on a 48 KB part.
The consequence: a checker that treats an unset or set “CP3” as meaningful on a 6585 is reading a bit that has no hardware behind it. The real state has three positions, not four. On the 64 KB PIC18F6680, the same family’s CP3 is real and covers 0xC000–0xFFFF — one more reason the device ID at 0x3FFFFE gets read before any block interpretation. The same family rule appeared on the 28/40-pin PIC18F4585, where the 48 KB member also lacks its top bit.
What the firmware carries
A 6585 image is a CAN node: bit-timing constants computed at build time, acceptance filter masks, message IDs, and the node’s identity data. The bit timing is the part that punishes incomplete copies — it is derived from the oscillator configuration, which lives in the config words at 0x300000 outside the array. A rebuilt chip with missing config words runs, enumerates on the bench, and then drops frames on a live bus because it samples at the wrong point in the bit. That failure is reported as “the copy doesn’t work” when the array itself copied fine.
The EEPROM holds the identity
The 1,024 bytes at 0xF00000 sit under their own CPD bit, independent of the flash blocks. On CAN nodes this is where the node address and per-unit parameters live, and a blank EEPROM produces a clone that answers to nobody — or to the same address as the original, which is worse on a shared bus. Flash and EEPROM should be one deliverable; the copy protection overview explains how CPD separates the two during a locked read.
Assessment
The sequence: read the ID to confirm a 6585 rather than its 64 KB sibling; read the array to 0x0BFFF; read the config words; attempt the EEPROM. A per-block report — firmware or zeros for boot, Block 0, Block 1, Block 2 — describes the lock state without opening the package, and the readout protection guide maps those patterns to states. Where the array reads as zeros throughout, the die-level routes described on the services page apply. The complete deliverable: 48 KB array, config words, EEPROM, and a block map that used three bits because that is all this part has.
In place or off the board
The 6585 came in two packages — 64-pin TQFP and 68-pin PLCC — and the package decides how the first read attempt goes. TQFP boards frequently route PGC and PGD to a service header, so the initial assessment happens in circuit: ID, per-block attempt, EEPROM attempt, done in minutes. The PLCC is a socketed style on some industrial boards, which makes removal trivial and in-circuit work unnecessary. Where neither applies, removal from a 68-pin PLCC is low-risk compared with fine-pitch TQFP work. Either way the read sequence is identical, and so is the deliverable: the 48 KB array with its three-block report, the config words that fix the CAN bit timing, the EEPROM with the node’s identity, and the device ID that says which member of the family — and therefore how many protect bits — the report should count.