Every request for a program copy arrives with the same two lines: flash and EEPROM. On a PIC18F4450 the second line has no answer, because Microchip’s own parametric table lists zero bytes of data EEPROM for this device.
That is not a documentation gap. The 4450 is the cost-reduced member of the USB family: 16 KB of program memory (8,192 instruction words), 768 bytes of SRAM, 34 I/O pins, a full-speed USB 2.0 interface at 12 Mbit/s with 16 endpoints, 256 bytes of dual-port USB RAM plus 512 bytes of general-purpose RAM, thirteen channels of 10-bit ADC, one CCP module, and 48 MHz operation for 12 MIPS. It is pin-compatible with the PIC16C765, which is the whole point of the part — it drops into an existing board and adds USB without a redesign.
What Gets Removed to Hit a Price
Data EEPROM is one of the first things to go when a family is cost-reduced. It is a separate array with its own charge pump, its own endurance specification and its own test time. Removing it saves die area and production cost, and it removes the ability to store a small amount of non-volatile data without wearing out the flash.
So “where does this product keep its settings” has exactly three possible answers on a 4450, and they behave very differently:
| Storage | Survives power loss | Endurance | In a flash copy |
|---|---|---|---|
Flash as a const table |
Yes | 100k cycles, whole block erase | Yes |
Flash written at runtime via TBLWT |
Yes | 100k cycles, block granularity | Yes, but not as data |
| Dual-port USB RAM | No | Unlimited | No |
The third row is the one that bites. The 256 bytes of dual-port RAM belong to the USB serial interface engine, not to the application’s non-volatile storage, and they are lost on power-down.
What a Copy of This Part Actually Contains
A complete device image for a 4450 is:
- 16 KB of program memory at
0x000000–0x003FFF, in four 4 KB protection blocks - Twelve configuration bytes at
0x300000 - Device ID at
0x3FFFFEand revision at0x3FFFFF - No data EEPROM. There is nothing at
0xF00000to read.
If a supplier hands you a file for a 4450 that contains an EEPROM section, one of three things is true: they read a different part, they copied a template from a 4455 job, or the file is padded. All three are worth catching before the file is programmed into anything.
The Acceptance Test Has to Be Enumeration
Because there is no EEPROM to compare, “the EEPROM matches the original” is not available as a pass condition. The test that replaces it is behavioural:
1. The host enumerates the device — descriptor read completes without a stall. 2. The VID and PID match what the host driver expects, or the INF has been updated deliberately. 3. The endpoints behave — the same interface class, the same transfer type, the same packet size. 4. The application function runs — the analogue channel reads, the output switches, the measurement is in range.
Steps 1 to 3 are in the flash image, because USB descriptors on this family are const data compiled into program memory. Step 4 depends on the calibration constants, and on this part those constants are also in flash — either as literals or in a table. There is no other place for them to be.
That is actually an advantage: a 4450 image is self-contained in a way that a 4455 image is not, because on the 4455 the 256-byte EEPROM may hold trim that must travel with the file. On the 4450, if the image is complete, it is complete.
The Sibling Confusion
The pin-compatible neighbours are not equivalent:
- PIC18F4455 — 24 KB flash, 2,048 bytes SRAM, 256 bytes EEPROM, 1 KB dual-port USB RAM. Different datasheet, DS39632.
- PIC18F4550 — 32 KB flash, 2,048 bytes SRAM, same DS39632, the PIC18F4550 being the part most often substituted when a 4450 is unavailable.
Substituting upward works in one direction: a 4450 image programs into a 4455 or a 4550 and runs. The reverse does not — a 4550 image will not fit a 4450, and a file truncated to 16 KB loses whatever lived above 0x3FFF.
If the replacement part is not a 4450, say so before the work starts. The extract firmware scope is set by the target, not by the source.
What to Send
The marking photograph, the board photograph, and a note on whether the product holds settings that survive power loss. That last question determines whether the recovered image needs a data block at all — and on this part, the answer is usually no.
The frequently asked questions page covers the general turnaround, and contact us is the fastest route for a part-specific question.