Two Microchip parts share exactly 48 KB of flash, 64 pins and an almost identical feature list: the PIC18F6525 and the PIC18F6527. They come from different datasheet families, and their code-protection geometry is different. The 6527 belongs to the PIC18F8722 family (DS39646), and its block map — including a boot block whose size is a configuration bit — is what a read-out has to interpret.
The block map
The 6527 array runs from 0x0000 to 0x0BFFF. Its boot block is selectable to 2, 4 or 8 KB through the BBSIZ bits in CONFIG4L; Block 0 then runs from the end of the boot block to 0x3FFF, and above it sit Block 1 (0x4000–0x7FFF) and Block 2 (0x8000–0xBFFF) at 16 KB each. CP0 through CP2 cover those blocks; CP3 is unimplemented on the 48 KB members, along with CP4 and CP5.
The BBSIZ selection is the part that catches people. With a 2 KB boot block, Block 0 starts at 0x0800; with 4 KB it starts at 0x1000; with 8 KB, at 0x2000. The same physical dump describes three different block maps depending on a config bit, and the config words at 0x300000 live outside the array, carried in the hex file by type-04 records that some tools silently drop. A reader that assumes the 2 KB default on a unit programmed with an 8 KB boot block reports Block 0’s boundary 6 KB wrong.
Distinguishing it from the 6525
The 6525 holds the same 48 KB with a fixed 2 KB boot block, a 14 KB Block 0, and CP0–CP2 above it. Both parts return 48 KB, both carry 1,024 bytes of EEPROM, and both look the same in a listing. The device ID at 0x3FFFFE is the discriminator, and it is readable regardless of the protection state. Reading the ID before interpreting the dump is not a formality here — the two parts want different block maps, and the wrong one mislocates every locked region. The PIC18F6525 page covers its map; the PIC18F6720 shows where the 8722 family tops out.
RAM and what it says about the firmware
The 6527 has 3,936 bytes of RAM, the larger allocation in its family, and together with PSP and dual enhanced USARTs that points at firmware that buffers — protocol handlers, logging, host communication. That kind of code keeps its tables in flash and indexes them, so the upper blocks matter even when the application logic sits low. A read that covers 0x0000–0x7FFF and reports the top 16 KB as zeros may be missing Block 2, where the constant data lives.
The assessment
The read sequence: ID first, then the array to 0x0BFFF, then CONFIG4L to fix the boot-block size, then the config words and the EEPROM. From the per-block pattern the protection state follows without decapsulation; where blocks are locked, the die-level code protection routes apply, and the services page describes what each adds. The complete deliverable for a 6527 is the array, the config words including BBSIZ, the EEPROM, and a block map interpreted with the right boot size — four items, all checked against the ID.
What the firmware is like
The 6527 pairs its 48 KB with dual enhanced USARTs and a parallel slave port, so its firmware usually has two lives: the control loop and the host conversation. The control loop keeps its tables — scaling constants, ramp curves, limit sets — in flash, and on a 48 KB part those tables reach the upper blocks well before the array is full. The host side buffers, which is what the 3,936 bytes of RAM are for, and the strings it sends live high in the array too. A read that stops partway and disassembles cleanly is therefore common and misleading: the code runs, the menus display, and every value that came from a table in the missing block is wrong. The completeness test stays arithmetic — 49,152 bytes ending at 0x0BFFF, config words, EEPROM, ID — and the user ID locations, where the firmware often stashes a date code or serial, come along in the same pass and cost nothing to include.