PIC18F6520: The Boot Block Is 2 KB, Not 512 Bytes

The PIC18F6520 belongs to the DS39609 family, which also contains the 6620 (64 KB) and the 6720 (128 KB). Sharing a datasheet does not mean sharing a protection layout, and this is the part where assuming it does leads readings astray: the 6520 divides its 32 KB into a 2 KB boot block, a 6 KB block and three 8 KB blocks — a geometry the bigger members do not use.

The actual block map

Per the family documentation and the device header, the 6520 array runs 0x0000–0x7FFF and splits as:

Each range has its own CP, WRT and EBTR bits in the CONFIG5L/6L/7L registers at 0x300008–0x30000C, plus CPD for the 1,024 bytes of data EEPROM at 0xF00000. Any of the five flash ranges can be locked alone, which produces protection states the uniform-block families cannot express: a boot block and nothing else, or the top 8 KB while the rest reads normally.

That matters when reading a locked unit. A dump from a part with only CP3 set is 24 KB of firmware followed by 8 KB of zeros — and zeros are a legal instruction, so the file still looks like a program. Interpreting those zeros with the 6620’s map, where the equivalent region would be mid-array, puts the boundary in the wrong place and misreports which code is missing.

The 40 MHz ceiling

The 6520 clocks to 40 MHz; the 6620 and 6720 stop at 25 MHz. The oscillator setting lives in the configuration words at 0x300000, which sit outside the array and are carried in a hex file by type-04 records. A rebuilt image with the config words missing, or copied from a faster sibling, changes the instruction clock by more than half on a board tuned for it — UART baud rates, PWM frequency and CCP timing all shift together. The PIC18F6620 page covers its side of that split.

What the EEPROM holds

The 1 KB of data EEPROM is the classic second file. On 6520 boards — instrumentation, metering, industrial control — it typically carries per-unit calibration and serial numbers. A clone with a correct flash image and a blank EEPROM boots and passes bench tests, then reads sensors wrong by the calibration constant. The failure presents as “the copy did not take” when the copy is fine and the EEPROM was never read; the CPD bit protects it separately from the flash, so a part can return full firmware and a locked EEPROM in the same session.

Reading one properly

The sequence is fixed: confirm the die from the ID at 0x3FFFFE, read the array to 0x7FFF, read the config words and the EEPROM, and record the per-block state rather than a single locked/unlocked flag. Where some blocks read as zeros, the map above says which code is missing without opening the package; where the whole array reads as zeros, the code protection work moves to the die, and the services page sets out what that route adds over a programmer attempt. The complete deliverable is three files — array, config words, EEPROM — and a block map that used this part’s geometry, not its bigger sibling’s.

What the firmware tends to look like

Five CCP modules and two addressable USARTs put the 6520 on metering panels, instrumentation and industrial monitoring boards — firmware that talks to a host and drives outputs at the same time. That mix fills the array from both ends: application logic low, protocol strings and calibration tables high. It also means the 1 KB EEPROM is doing real work rather than storing a serial number — energy constants, metering accumulators, communication parameters that the board’s operator has tuned in the field. An EEPROM copied from a different unit of the same model is better than a blank one and still wrong in the specifics, which is why the EEPROM read targets the same physical part as the flash, not a reference dump — a distinction worth settling before the work is quoted. The 2,048 bytes of RAM are generous for the family and usually mean buffered protocols, which in turn means the flash’s upper blocks hold the string tables those buffers get filled from.