The PIC18F8410 is an odd member of Microchip’s large-package PIC18 line: eighty pins, 66 I/O, a full peripheral set, and only 16 KB of program flash. Most devices in this package family carry 32 KB or more. Documented in the PIC18F6310/6410/8310/8410 data sheet, it provides 8,192 single-word instructions, 768 bytes of SRAM, a 12-channel 10-bit A/D converter, two comparators, an EUSART with LIN support, and an MSSP for SPI and I2C. Notably, the parameter table lists data EEPROM as zero — there is none.
What the Eighty Pins Are For
A 16 KB part on an 80-pin package is usually there for pin count reasons: a product that drives many relays, LEDs or display lines with modest logic. The firmware tends to be I/O scheduling rather than computation, and the image is small — 1,024 Intel HEX records of 16 bytes. That is a file you can read in an afternoon, which is not the same as understanding it.
Small images leave little slack. A routine that looks like dead code in the disassembly is more likely a state-machine branch that runs once a shift. Treat the disassembly as a map to verify, not as documentation.
The Protection Map
Flash occupies byte addresses 0x000000 to 0x003FFF, and the code protection bits divide it into four equal blocks of 4 KB each: CP0 through CP3. A board can lock half its program and leave the bootloader readable, or lock everything, and the read you get depends on which bits were set.
Two consequences follow. First, a dump where one region reads 0xFFFF and another reads 0x0000 usually means the protected blocks answered with zeros — how PIC18 copy protection behaves explains the gate. Second, 0x0000 is also a legal NOP instruction on PIC18, so a padded hole looks like code in the disassembly. You cannot tell protection from absence by the value alone; the device ID at 0x3FFFFE and the data sheet’s array size tell you where the array actually ends.
There Is No EEPROM
The PIC18F8493 and the 8390 family carry the same 80-pin footprint with different peripherals, and several siblings do have data EEPROM. The 8410 does not. If a title or a service page promises “recovery of code and EEPROM” for this device, it is describing a different chip.
Products built on the 8410 keep their parameters somewhere: a flash page written at final test, an external serial EEPROM on the board, or nothing at all. The flash page is part of the array and comes with the dump. The external part is a separate job, and it is worth saying so in the request — our services page lists what is delivered for memory read-outs versus board-level recovery.
Config Words Live Outside the Array
The configuration registers sit at 0x300000 and above: oscillator selection, watchdog, brown-out level, and the code protection bits themselves. They do not appear in a linear read of the array, and a recovered file without them programs into a blank part that runs at the wrong clock or never starts.
This matters more than usual on this device because it has a Fail-Safe Clock Monitor and a wide 2.0 to 5.5 V operating range — settings that were clearly used across different board designs. The config values are not inferable from the code; they have to come off the device or from a known-good reference.
Getting a Read at All
The 8410 programs through the standard ICSP pair of pins, and a locked device still answers the programmer: the ID read works, the config region works, and only the protected array answers with zeros. That behaviour is worth confirming before any silicon-level work is considered, because it distinguishes a locked part from a dead one. A dead chip — no ID, no config — is a different job with a different price, and one bench session with a programmer settles which situation you are in.
Supply discipline matters more than usual on this part because of its wide operating range. A device specified from 2.0 to 5.5 V has been designed into boards running at 3.3 V and boards running at 5 V, and the brown-out threshold in the config words tells you which class the board belongs to. Read the config region first for that reason alone: it is the cheapest source of information about how the board was built, and it is available even on a fully locked part.
Verification Before Delivery
A read-out is not a delivery. The checks that separate a usable image from a merely complete one: read the array twice from independent sessions and compare; confirm the reset vector at 0x0000 resolves into real code; scan the tail of each 4 KB block for abrupt holes; and confirm the device ID matches the marking, because the same package carries the 8310, 8410, 8490 and 8493 variants with different memory and analogue silicon.
Reading the program memory describes the full procedure, and chip extraction analysis covers the post-read report. If the board in front of you is marked PIC18F8410 and it drives a large I/O load, send the marking photo and a line about what the board does when it works — contact us with the details and we will confirm the memory layout before anyone touches the die.