Small flash changes the nature of a read-out. On an 80 KB or 96 KB part the deliverable is a binary you hand over and hope boots; on a PIC18F4220 the whole program is 2,048 instructions, which is few enough that a disassembly can be read end to end. That difference matters more than the protection state.
The PIC18F4220 is a 40-pin device: 4 KB of enhanced flash, 512 bytes of SRAM, 256 bytes of data EEPROM, 36 I/O pins, a 10-bit ADC with thirteen channels, two comparators and two CCP modules, with an addressable USART for serial links. No CAN, no USB — it is a general-purpose control part, and it turns up in timers, chargers, bench instruments and small machine controllers where a 40-pin package was needed for I/O count rather than for compute.
One Block Means All or Nothing
Protection on this family is still CP0–CP3 in CONFIG5L, but 4 KB of flash does not divide into four meaningful regions. In practice a device is either open or closed: there is no large unprotected window that survives a partial read.
That removes the single most common failure mode on bigger parts. A 96 KB image can come back 95 percent correct with one block of filler in the middle and still look like a valid file; a 4 KB image cannot hide that. If the read worked, you have the program. If it did not, you have nothing, and you know it immediately.
The file itself is compact: 256 Intel HEX data records of 16 bytes, plus the config words at 0x300000 and 256 bytes of EEPROM at 0xF00000. A complete dump fits in a single screen of a hex editor, which is why verification here is quick — the chip extraction analysis step is mostly checking that the reset vector at 0x0000 branches into real code and that no run of filler appears inside the image.
What 2,048 Instructions Actually Buys You
A program this size has a shape you can hold in your head. In practice it is an initialisation block, a main loop, an ADC scan, a lookup table or two, and the interrupt handlers for a timer and the serial port. There is no RTOS, no filesystem, no protocol stack — 512 bytes of RAM rules all of that out.
The practical consequence is that for these parts the useful deliverable is often not just the binary. A disassembly with the I/O registers and the ADC channel assignments annotated answers the question the customer actually has: what does this board measure, and how does it decide. That work is not feasible on a 49,152-instruction image at a sane budget; here it is days, not months.
It also means a read-out can be judged before it is paid for. If the recovered code is recognisably a control loop, the extraction succeeded. If it is 4 KB of filler with a valid-looking header, it did not.
The Parameter Block Is Tiny — and Load-Bearing
256 bytes of EEPROM is not enough for calibration curves, but it is exactly enough for the values a device cannot recompute: a serial number, a run-hour counter, a user-set threshold, the last state before power-down.
Boards built on this part frequently refuse to start cleanly when that block is erased, because the firmware reads it at boot and trusts it. Preserve it byte-for-byte rather than letting the programmer fill defaults — reading the program memory without the EEPROM produces a file that runs and misreports.
Before You Assume a Swap Will Work
The obvious reaction to an obsolete 4220 is to fit the newer PIC18F4221: same 40-pin footprint, same 4 KB of flash, same 36 I/O. It is not a drop-in for a binary, though — the peripheral set and the config layout moved. That page covers why a 4220 image will not simply run on it.
If the board is in front of you, the marking photograph and the ordering suffix are enough to start. Contact us with those and we will say whether the device is readable before any package work is quoted.