Copying the whole device is the obvious approach and, on this part, often the wrong one. The 1 KB of data EEPROM can contain a usage counter, an error log and a service date, and a replacement that inherits all three will report someone else’s history.
The PIC18F4525 carries 48 KB of program memory — 24,576 instruction words — with 3,968 bytes of SRAM, 1,024 bytes of data EEPROM, 36 I/O pins, thirteen channels of 10-bit ADC, and 40-pin PDIP or 44-pin TQFP and QFN packaging. It belongs to the PIC18F2525/2620/4525/4620 datasheet.
One Kilobyte Is a Lot of Room
The PIC18F4520 shares the same footprint but offers 256 bytes of EEPROM. Four hundred percent more non-volatile space is not a rounding error; it is a design decision.
A kilobyte holds a 512-byte circular log with a head pointer, a run-hours and a cycle counter, a calibration block of 16 to 64 bytes, a serial number and build date, and the thresholds a service engineer can adjust.
Products that carry the 4525 rather than the 4520 usually do so because they want that space. The larger part is itself a hint that the EEPROM is load-bearing.
What Happens When You Copy It
A full device copy takes the flash and the EEPROM together. That is correct for a like-for-like replacement: the board goes back into the same machine with the same counters, and the maintenance schedule is undisturbed.
It is wrong in three other cases:
1. A new build. The replacement goes into a new machine and starts life claiming 14,000 run-hours. The warranty clock is already expired from the controller’s point of view. 2. A repaired unit returned to service. The error log still contains the fault that caused the failure, so a technician reading it diagnoses a problem that has already been fixed. 3. Volume production. Every unit carries the donor’s serial number. Traceability fails the first time two units are compared.
None of these failures is in the flash. All of them are in one kilobyte that nobody looked at.
Separating the Blocks Without a Reference
You do not need a second unit to classify the EEPROM. The firmware tells you.
Every EEPROM access is an address written to EEADR before the read or write control sequence. Disassemble the image and collect the constants loaded into EEADR. They form clusters: a run of consecutive addresses accessed in a loop is a buffer; a single address written once at startup and read periodically is a counter; a block copied to RAM at boot is calibration.
| Pattern in the code | Likely content | Copy or reset |
|---|---|---|
Loop over EEADR = 0x00–0x1FF |
Ring buffer | Reset head pointer |
| Single address, incremented | Usage counter | Reset to zero |
| Block read at startup into RAM | Calibration | Copy |
| Address written only from a service routine | Setpoints | Copy |
This analysis takes a few hours and removes the most common post-delivery complaint about this part: “the clone works, but the machine says it is six years old.”
The Boundary Map
Forty-eight kilobytes is 0x0000 to 0xBFFF in byte addresses, in four protection blocks of 12 KB each. Configuration is at 0x300000–0x30000B, the data EEPROM at 0xF00000 for 1,024 bytes, the device ID at 0x3FFFFE, the revision at 0x3FFFFF.
Two details specific to this size:
- The top block matters. A 48 KB part with a bootloader keeps it in the last 12 KB, and the reset vector at
0x0000jumps up there. A read that stops at the first erased run returns an image that cannot boot. - The EEPROM is a separate range. A file that ends at
0xBFFFis a flash-only image. It is not wrong, but it is incomplete for a device replacement, and the difference is 1,024 bytes of production data.
What to Specify
Say which of the two jobs you want, because they produce different files:
- Replacement of a failed unit — full copy, EEPROM included, counters preserved.
- Reproduction of a product — flash plus calibration, usage blocks reset.
The second costs the same and needs one extra line in the delivery note. It also avoids handing a production line a file that brands every new unit with a stranger’s serial number.
If the code protection covers the whole array, the EEPROM is a separate question: CPD in CONFIG5H protects it independently, and plenty of designs protect the flash while leaving the data readable — the best case here, because counters can be read and classified even when the code has to come through the die.
Reading the firmware out of this family is routine, and the reading the firmware page covers the sequence. What is worth deciding before the work starts is what the EEPROM is for. Everything runs under the non-disclosure agreement, and the services page lists what each route includes.