The PIC18F8585 belongs to the ECAN family documented in the PIC18F6585/8585/6680/8680 data sheet: 48 KB of flash — 24,576 single-word instructions — 3,328 bytes of SRAM, 1,024 bytes of data EEPROM, a 16-channel 10-bit A/D converter, one CCP and one Enhanced CCP module, and, the reason this part exists, an ECAN module that implements the CAN 2.0B protocol with hardware message buffering. The package is an 80-pin TQFP with an external memory interface addressing up to 2 MB.
Automotive Context Changes the Job
Parts chosen for their CAN controller end up in body controllers, gateway prototypes, motor-drive nodes and instrumentation that talks to a vehicle bus. Two things follow for a recovery. The ECAN configuration — baud rate, filters, masks, the buffer allocation between transmit and receive — lives partly in config and control registers and partly in data the firmware writes at start-up, so a code-only understanding of the image is incomplete.
And the 1,024-byte EEPROM usually carries what the product was about: node identifiers, DIP-switch overrides, calibration for the analogue front end, service counters. It is mapped at 0xF00000 and read as its own region, twice, because EEPROM cells with high write counts can return marginal values on the first pass. A rebuilt node with the right code and an empty EEPROM joins the bus and then behaves unlike the original the first time an identifier matters.
ECAN in the Image
The ECAN module gives the firmware a set of hardware buffers with programmable filters and masks, and the start-up code that loads them is one of the most informative regions of the whole image. The baud rate prescaler, the identifier filters, the buffer-to-transmit assignment — all written by code at boot, all readable in the disassembly, and all describing how the node behaved on the bus. For a customer rebuilding a controller, that is often the part of the recovery they care about most, because a node with the wrong filters joins the bus silently and goes unheard.
The module also has its own register set inside the SFR space, which means a disassembly that ignores it produces plausible nonsense around every CAN interaction. Knowing the peripheral layout is part of reading the image correctly, and it is one more reason the post-read review is a separate step rather than a formality. How a verified read-out is checked covers the electrical part; the interpretation is chip extraction analysis.
The Memory Map
Flash occupies byte addresses 0x000000 to 0x00BFFF, quartered by the code protection bits into four blocks of 12 KB — CP0 through CP3. A full internal dump is 3,072 Intel HEX records at 16 bytes. Protected blocks answer 0x0000, which is a legal NOP instruction on PIC18 and therefore disassembles as if it were code; erased flash reads 0xFFFF. Only the device ID at 0x3FFFFE tells you cleanly what you are looking at. How PIC18 copy protection behaves covers the mechanism.
The Nearest Neighbour Is Not a Sibling
At 48 KB the natural confusion is with the PIC18F8525, which shares the flash size and the 80-pin package but comes from a different family: 3,840 bytes of SRAM instead of 3,328, no ECAN, and a different data sheet. Boards get repaired with the wrong 48 KB part because the footprint is identical, and the failure shows up later — the replacement part has no CAN controller at all.
When a customer sends a board for recovery, the first verification is which device is really fitted, and the ID read settles it. Where the package is conformal-coated or the marking is suspect, semi-invasive IC extraction reaches the die without destructive depackaging, which is often the deciding factor for automotive boards that must go back into service.
What a Complete Delivery Contains
The internal array, read twice from independent sessions and compared. The EEPROM at 0xF00000, also read twice. The config words at 0x300000, recorded — on this family they include the ECAN-related settings and the CCP2 pin muxing, neither of which is inferable from code. And a statement about external references: the external memory interface means the image can legitimately contain table reads pointed above 0xBFFF at devices sitting next to the MCU. If the board carries an external flash or RAM, the internal dump alone does not rebuild the product, and it is better to know that before the die is opened. Chip extraction analysis is the post-read step, and reading the program memory describes the verification standard.
Send the marking photograph and one line about what the node does on the bus. Our services page lists what is delivered; contact us if you are unsure which 48 KB variant the board carries.