The PIC18F8621 belongs to the PIC18F6525/6621/8525/8621 family documented in DS39612: 64 KB of enhanced flash — 32,768 single-word instructions — 3,840 bytes of SRAM, 1,024 bytes of data EEPROM, a 16-channel 10-bit A/D converter, two CCP plus three Enhanced CCP modules capable of twelve PWM outputs, two addressable EUSARTs, a parallel slave port, and an external memory interface addressing up to 2 MB. The package is an 80-pin TQFP.
The Question the Dump Cannot Answer
This is the part where the internal array being complete does not settle the job. The external memory interface supports several operating modes — running entirely from external memory, mixing on-chip and external flash, and using external RAM for data. The active mode is set in the config words at 0x300000, not in the code.
In microcontroller mode, everything the processor executes lives in the internal 64 KB and a full dump is the program. In extended microcontroller mode, code can be fetched from external devices, and the internal dump — however complete — references bytes that live on a flash or EPROM sitting beside the MCU. In microprocessor mode the internal flash is not even the program store.
So the first question for a PIC18F8621 recovery is not about the die at all; it is about the board. What sits next to the processor, and was the design built around it? Asking before depackaging avoids discovering, after the read, that a second image is needed from a 27C-type part. Our services page separates die-level read-outs from board-level memory recovery for exactly this situation.
Reading the Mode from the Image
Even without the board, the image usually answers the mode question itself. Code running purely internally never touches the bus-setup registers; code built for extended mode initialises the bus early, and its constant tables may sit at addresses above 0xFFFF — a file layout impossible for an internal-only image. A hex dump that stops at 0xFFFF with clean code right up to the last byte points to microcontroller mode; a dump with sparse high-address tables or a blank upper quarter points to a design that expected more memory than it had on chip.
Both findings are useful to a customer, and neither requires the die to be opened first. That is the argument for asking for a photograph of the board and, where possible, a read of the config region through the programmer before any invasive step — the config words answer the mode question directly, and a locked array does not block the config read. Reading the program memory describes what a bench session can establish before silicon work starts.
The Protection Map
Flash occupies byte addresses 0x000000 to 0x00FFFF, and the code protection bits quarter it into four blocks of 16 KB — CP0 through CP3. A full internal dump is 4,096 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. The device ID at 0x3FFFFE resolves the ambiguity. The PIC18 copy protection scheme covers the mechanism — a rewritable gate rather than a fuse, so the sample can survive the read.
Same 64 KB, Different Family
The PIC18F8620 shares the flash size, the package and the footprint but comes from the XX20 family — five plain CCP modules instead of the 2+3 ECCP arrangement, a different data sheet, different config behaviour. Code compiled for one usually executes on the other, so a board repaired with the wrong sibling passes a bench test and fails later under PWM fault conditions or EUSART edge cases. The ID read settles it in one instruction, before any silicon work.
Where the ECCP Settings Live
Three Enhanced CCP modules with programmable dead time, auto-shutdown and half-bridge or full-bridge output mean this part drives real power electronics. The auto-shutdown sources, the dead-time values’ configuration and the PWM output pin mapping live in the config registers and ECCP control registers — the start-up values in config, the runtime values in code. An image delivered without the config words at 0x300000 programs a blank part that boots and then misdrives its outputs the first time a fault condition occurs. On a motor board that is not a cosmetic failure.
Verification
The internal array read twice from independent sessions. The EEPROM at 0xF00000 read twice — setpoints and calibration for the typical application live there, and marginal cells return wrong values on a single pass. The config words recorded and sanity-checked against the board’s oscillator and bus design. Chip extraction analysis is the post-read step, and reading the program memory describes the two-pass standard. For boards where the die cannot be reached cleanly, invasive MCU extraction is the fallback, and the decision belongs before the first attempt. Contact us with the marking photo and what the board drives.