The PIC18F6627 carries 96 KB of flash — 49,152 instructions — in the PIC18F8722 family: 3,936 bytes of RAM, 1,024 bytes of EEPROM, PSP and a 40 MHz ceiling in a 64-pin TQFP. The array runs from 0x0000 to 0x17FFF, which means the top third of the part lives above 0xFFFF, the boundary a generation of dump tools treats as the end of memory.
The block map
Like all 8722-family members, the 6627 has a BBSIZ-selectable boot block — 2, 4 or 8 KB through CONFIG4L — with Block 0 running from the boot block’s end to 0x3FFF. Above it:
| Block | Range | Controlled by |
|---|---|---|
| 0 | boot end–0x3FFF |
CP0 |
| 1 | 0x4000–0x7FFF |
CP1 |
| 2 | 0x8000–0xBFFF |
CP2 |
| 3 | 0xC000–0xFFFF |
CP3 |
| 4 | 0x10000–0x13FFF |
CP4 |
| 5 | 0x14000–0x17FFF |
CP5 |
Blocks 4 and 5 are the ones a wrong template loses. A dump that stops at 0xFFFF covers 64 KB — two thirds of the part — and reports Blocks 4 and 5 as absent rather than as locked. Since the missing region is where XC8 places large constant arrays on a part this size, the truncated image can still run most firmware and fail only on table lookups into the top of the array. The PIC18F6622 needs the same arithmetic at 64 KB; the PIC18F6720 needs it at 128 KB.
The hex side
Addresses above 0xFFFF are carried in Intel HEX by type-04 extended linear address records. A 6627 image contains at least two of them — one to cross into 0x00010000, one for 0x00020000 territory if config and ID space are included. Tools that ignore type-04 records do not error out; the checksums still pass and the file just ends early. Checking the highest data record against 0x17FFF is the completeness test, and it takes seconds.
What the firmware and EEPROM hold
With 3,936 bytes of RAM and dual enhanced USARTs, 6627 firmware typically buffers — protocol stacks, logging, host links. Constant tables grow with the application, and on a 96 KB part they grow into Blocks 4 and 5. The 1,024 EEPROM bytes at 0xF00000 sit under their own CPD bit and carry per-unit data: node parameters, trim, serials. A clone with a blank EEPROM behaves correctly on the bench and drifts in the field — the standard half-copy failure, described on the copy protection page.
The assessment
Read the ID at 0x3FFFFE first: it fixes the family, the array size and which CP bits exist. Read the array to 0x17FFF with a per-block report interpreted at the BBSIZ the config words actually specify. Read the config words — they are also the evidence for the oscillator setting behind the 40 MHz clock. Attempt the EEPROM. Where blocks return zeros, the protection state follows from the pattern; where the array is locked wholesale, the die-level routes on the services page apply. The deliverable is the same either way: 98,304 array bytes ending at 0x17FFF, config words, EEPROM, ID — with nothing above 0xFFFF assumed absent.
What the firmware is like
At 96 KB with dual enhanced USARTs and 3,936 bytes of RAM, the 6627’s firmware is usually a protocol stack wearing a control loop: logging, host links, buffered telemetry. Code of that shape grows upward — the low blocks hold the loop, the middle blocks hold the protocol, and Blocks 4 and 5 hold the string tables and stored datasets the protocol serves. That is precisely the region a 0xFFFF-limited dump drops. The failure mode is quiet: the unit boots, answers the host, and returns truncated or stale data for every request that touches a table above the boundary. A second read pass targeting 0x10000–0x17FFF directly, with the type-04 records verified in the file, closes the gap; the EEPROM and ID come along in the same session, and the user IDs — often a production date code — cost nothing to include.