A short enquiry reaches us at least once a month: “we sent the PIC18F2553 for reading and got the hex back, but where is the EEPROM?” The answer is that the PIC18F2553 does not have one. Not a protected one, not an empty one — the array is absent from the silicon. Reading 32 KB of flash and nothing else is the complete job on this device.
That surprises people because the part sits in the same 28-pin family as devices that do carry EEPROM, and because boards built on it behave as though they have persistent storage. They do have it. It is kept in flash.
The PIC18F2553 is documented in DS39887: 32,768 bytes of enhanced flash, 16,384 single-word instructions, 2,048 bytes of SRAM, 2.0–5.5 V operation, and a full-speed USB 2.0 engine with 32 endpoints.
Where the Parameters Are
Without EEPROM, firmware that needs to remember a calibration constant across power cycles has three options, and a recovered image usually contains at least one of them.
The first is save-on-shutdown: the USB stack detects a host suspend or an intentional power-down and writes the values into a flash page reserved for the purpose. The second is save-on-change, writing whenever a setpoint is edited. The third is a lookup table compiled into the image — constants that were never meant to change and are therefore part of the code rather than part of the data.
All three look identical from the outside: the product remembers its settings. From inside the image they are easy to tell apart. A flash write sequence in the disassembly — the unlock sequence, the page erase, the byte write — means the parameters were written at runtime, and they are sitting somewhere in the array. A table of constants with no write path means the values are in the code.
That distinction decides whether a recovered image reproduces a working unit or merely a booting one. A device that powers up blank because the calibrations were wiped before the chip reached us needs those values from somewhere else.
Protection on This Device
The gate is the familiar one: CP0 through CP3 in CONFIG5L, one per quarter of the array, CPB for the boot block in CONFIG5H, and the EBTR bits in CONFIG7L that stop running code from reading the array through TBLRD. On 32 KB the quarters are 8 KB each — 0x0000–0x1FFF, 0x2000–0x3FFF, 0x4000–0x5FFF, 0x6000–0x7FFF in byte addresses.
CONFIG5H also carries the usual CPD bit. On parts without EEPROM that bit has nothing to protect — a tidy illustration of how the config map is shared across a family rather than tailored per device.
Set any of the CP bits and the programmer still connects, the ID at 0x3FFFFE still answers, and the read returns a constant. It is a copy protection scheme in the literal sense — a gate, rewritable by a programmer with access, not a one-time fuse. The sample need not be destroyed by a read.
What a Delivered File Contains
Two regions. Flash occupies byte addresses 0x000000 to 0x007FFF, which is 2,048 Intel HEX records of 16 bytes. Configuration sits at 0x300000 and above, and on a USB part this is where the recovery either works or does not, because the configuration words select the oscillator, enable the USB voltage regulator and set the brown-out level. The regulator setting is not recoverable by inference: a board running the transceiver from the internal regulator and a board that feeds it 3.3 V externally have different config values.
The Family Substitution
The PIC18F2458 is the 24,576-byte sibling in the same 28-pin package. An image from a 2458 runs on a 2553 unchanged; an image from a 2553 needs a 2553 or larger. When the supply of one part is tight, check which way the substitution is safe before redesigning.
Confirm the device by reading the ID rather than by reading the marking alone. The two siblings share a package and a family, and the difference between them is 8 KB that only matters when you run out of it.
What Is Worth Checking Before Sending
Two questions save a wasted cycle. Is the board still alive — does it enumerate, or is it fully dead? And do you have a second unit, working or not, that can supply parameters if the first one lost them? A dead unit with no sibling is a different job, and one that may not be worth starting.
Reading the program memory describes the verification step; chip extraction analysis covers what a post-read report should tell you; the services page lists what is delivered.