Most quotes for reading a locked PIC18F4320 assume the expensive route. But this part comes in a 40-pin PDIP that drops straight into a socket, and a socket read over ICSP answers the only question that matters first: is the code protected at all, or is the chip simply blank, or dead?
The PIC18F4320 holds 8 KB of flash — 4,096 instruction words — alongside 512 bytes of SRAM, 256 bytes of data EEPROM, 36 I/O pins, a thirteen-channel 10-bit ADC and two analog comparators. Its datasheet is DS39599, shared with the 2220, 2320 and 4220.
Three Patterns, Three Answers
When a programmer reads a PIC18 over ICSP, the silicon answers differently depending on the protection state. That answer is not a status code — it is the data itself.
| What comes back | What it means | Next step |
|---|---|---|
Every word 0xFFFF |
Erased. The array is blank, either never programmed or wiped | Nothing to recover from flash; check EEPROM anyway |
Every word 0x0000 |
Read blocked by code protection | Physical work is the only route |
| Real, varying data | Not protected, or protection only on part of the array | Read it directly and skip the lab entirely |
The all-zeros pattern is the one people misread. A file full of 0x0000 looks like a failed read, and it gets reported as a dead chip — but a dead chip does not return a clean, uniform pattern at all. It returns nothing, or it fails to enter programming mode. Uniform zeros are the device deliberately refusing to hand over the array, which is a completely different diagnosis.
The Device ID Still Answers
Code protection on this family covers the program array. It does not cover the device ID at 0x3FFFFE. That two-byte location responds even on a fully locked part, which makes it the cheapest way to confirm you are holding the silicon you think you are holding, and that it is alive.
This matters more than it sounds, because the 4320 has been in production since the early 2000s and boards get reworked. A part that was replaced during a repair may be a 4321, or a 4220 from the smaller-flash branch of the same datasheet. Reading the ID before reading anything else keeps a job from being quoted against the wrong die.
EEPROM Has Its Own Bit
Protection of the data EEPROM is controlled separately, by the CPD bit in CONFIG5H at 0x300009. It is not set by the same action that sets CP0 through CP3 in CONFIG5L, and in a great many designs it is simply left clear.
That is a real opening. Two hundred and fifty-six bytes of EEPROM on this part typically hold a serial number, a calibration offset, accumulated operating hours or a stored threshold — the values a firmware reads at boot. Even where the flash array is fully locked, that block may still read normally over the same socketed connection.
So the order of work is: ID, then EEPROM, then the pattern test on flash. Only after all three does the question of physical access arise.
When the Physical Route Is Genuinely Needed
Full code protection on all blocks leaves no software path. The semi-invasive route — opening the package and accessing the array through the die rather than through the programming interface — is then the standard approach, and it is where most of the cost sits.
Two things make it cheaper than expected on this specific part. The die is a mature 0.5 µm process with wide metal, which tolerates optical access better than a modern fine-geometry device. And the 8 KB array is small: at 4,096 words, a full program memory image is 8,192 bytes of payload, so the read itself is fast and the verification pass is trivial to repeat.
The Diagnostic Is Worth Doing Anyway
Even when the outcome is obviously “it is locked”, running the socket test first is not wasted effort. It produces a record of what the part reported, it confirms the device ID, and it sometimes recovers the EEPROM for free. Jobs that skip it occasionally turn out to have been quoted for decapsulation on a chip that was blank.
The same three-step order applies to the PIC18F4331 and to every other part in this datasheet family; only the array size changes. If you can send the marking photograph, the package type and whatever the programmer reported, contact us and the answer usually comes back the same day — including the cases where the honest answer is that nothing needs to be opened.