The PIC18F6621 and the PIC18F6620 are the same on paper: 64 KB of flash, 3,840 bytes of RAM, 1,024 bytes of EEPROM, a 64-pin TQFP, PSP, dual serial ports. They come from different datasheet families — DS39612 versus DS39609 — and the differences are exactly the ones that decide whether a rebuilt unit works: the block map, the peripheral mix and the clock ceiling.
What actually differs
The 6621’s family pairs two CCP modules with three enhanced ECCP modules and clocks to 40 MHz. The 6620 carries five plain CCP modules and stops at 25 MHz. Same socket, same array size, different silicon — the same pattern as the PIC18F4680 versus 4620 pairing, and with the same practical rule: the device ID at 0x3FFFFE is read before anything else, because the two parts accept each other’s packages and their firmware is not interchangeable.
The block maps differ too. The 6621 divides its 64 KB the DS39612 way: a fixed 2 KB boot block, Block 0 from 0x0800 to 0x3FFF (14 KB), then 16 KB blocks up to 0xFFFF under CP1–CP3. The 6620 uses a 512-byte boot and a 15.5 KB Block 0. Interpreting one dump with the other’s map shifts every block boundary and misreports which regions returned zeros — on parts where the zeros are a legal instruction and disassemble cleanly.
What the firmware is like
Three ECCPs make the 6621 the motor-control member: half-bridge and full-bridge outputs, programmable dead time, auto-shutdown. Firmware on this part is PWM-heavy, and the dead-time and polarity settings live in firmware registers configured at startup — which means they are in the flash array, and an incomplete read shows up as a bridge that fires wrong rather than as a crash. The array ends at 0xFFFF; anything less is incomplete by arithmetic, not by judgment.
The 40 MHz difference
The config words at 0x300000 set the oscillator, and on a 6621 board built around a 40 MHz crystal the timing budget is tight: a rebuild with missing or wrong config words runs the UART and PWM at two-thirds speed on a 25 MHz ceiling assumption, or misconfigures the PLL. The config words travel in the hex file as type-04 records, which some tools drop silently. Checking for them is part of the completeness test, alongside the flash image itself.
Reading one out
The sequence: ID first to fix the family; array to 0xFFFF with a per-block report against the 6621 map; config words; EEPROM attempt. The 1,024 EEPROM bytes sit under their own CPD bit and carry the per-unit data — on PWM-control boards, phase offsets and trim. A clone with a blank EEPROM drives the right outputs at the wrong trim, which fails quietly rather than loudly.
Where blocks return zeros, the protection state follows from the pattern; where the array is locked wholesale, the code protection work moves to the die, and the services page describes the routes. The deliverable is the same four files either way — array, config words, EEPROM, ID — with the block map chosen by the ID, not by the part number printed on the board.
The half-copy failure, precisely
The ECCP half-bridge outputs make the 6621’s failure mode worth spelling out. Dead time and auto-shutdown are configured by firmware at startup, from values compiled into the array. A rebuild with the array complete but the config words missing — or with the EEPROM blank where the firmware expects trim values — produces outputs that switch at the wrong instant. On a bench load that looks like slightly more switching loss; on a motor it sounds like it and then smells like it. None of it traces back to the copy visibly, because every register the firmware writes is written correctly with a wrong value. This is why the deliverable on a 6621 is four files and not one, and why the services engagement treats EEPROM and config words as part of the base scope rather than extras — the alternative is a unit that works until it is attached to the load it was built for.