The PIC18F6310 is an odd-looking combination on paper: 8 KB of flash and 768 bytes of RAM wrapped in a 64-pin TQFP with 54 I/O lines, a parallel slave port and a 12-channel 10-bit ADC. It exists because some boards need the pins and the PSP more than they need the memory. That shape has a direct consequence for read-outs: the whole program array — 0x0000 to 0x1FFF — sits behind a single code-protect bit.
One bit, not a block map
Unlike the 40-pin parts where CP0 through CP3 divide the array, the 6310 has exactly one CP bit in CONFIG5L, and it covers the entire 8 KB. There is no boot block, no CPB, and no CPD — because there is no data EEPROM at all. Microchip lists zero bytes of data EEPROM for this part, which means any request phrased as “read the flash and EEPROM” ends with the flash alone: there is nothing else to read.
That simplifies the analysis and sharpens it. A read either returns the array or it does not. A locked 6310 returns 0x0000 across 0x0000–0x1FFF; an unlocked, blank one returns 0xFFFF. Since the two states are uniform, the protection state can be stated in one line instead of a per-block table, and there is no partial-lock configuration to reconstruct. The part either gives up its firmware over ICSP or it gives up nothing.
What the small array means for the file
Eight kilobytes is 4,096 instructions, and XC8 fills them densely. Constant tables, string literals and the startup code share the array with application logic, so there is no “empty half” to use as a sanity check. A complete hex ends at 0x1FFF; a file that stops at 0x0FFF is half of a 6310 — or all of a different part, which is the more dangerous confusion.
The device ID at 0x3FFFFE is what separates the 6310 from its sibling the PIC18F6410, which doubles the array to 16 KB in the same 64-pin package. Both carry the same 768-byte RAM and the same peripherals, so a board built around one accepts the other without a layout change. A dump labeled as one part and burned into the other produces a chip that runs until it reaches the missing half — or silently leaves half its flash blank.
No EEPROM means no hidden calibration
On most PIC18 parts the data EEPROM is where per-unit calibration hides, and a clone with a blank EEPROM is the classic half-copy failure. The 6310 removes that failure mode by removing the memory. Whatever calibration the firmware needs is either computed at runtime or stored in the flash array itself, which is why the flash image is the entire product here. There is no second file to forget.
How a locked one is assessed
The assessment is correspondingly short: confirm the die from the ID, attempt the ICSP read, and record whether the array came back as firmware or as zeros. If it reads as zeros, the single CP bit is set, and the remaining routes are die-level — the same code protection work that applies to any PIC18, described on the readout protection guide and offered through the services page. The small array does not make the part easier to unlock; it only makes the answer easier to state.
Reading one in place
The 6310 supports in-circuit serial programming over the standard two-wire clock-and-data pair, gated by MCLR at programming voltage. On a 64-pin TQFP already soldered to a board, that is usually the difference between a five-minute assessment and a reballing session: if PGC and PGD are routed to a header, the first read attempt happens in place, and the uniform 0x0000-or-firmware answer arrives without touching the package. If the pins are not brought out, the assessment starts with removal — and a 64-pin TQFP with 0.5 mm pitch is where damage during extraction becomes a real risk. Boards that went through conformal coating add a cleaning step before any clip makes contact. None of it changes what a locked 6310 returns; it changes what reaching the pins costs.