The PIC18F8390 has the most lopsided ratio in the metering families we work with: an 80-pin TQFP carrying 66 I/O lines and a 192-pixel LCD driver — 48 segments by 4 commons — around just 8 KB of program memory. DS39629, the family data sheet, confirms the rest: 4,096 single-word instructions, 768 bytes of SRAM, no data EEPROM, a 10-bit A/D converter with twelve channels, two CCP modules, and an EUSART with LIN support. The package says industrial instrument; the code space says someone counted every byte twice. Nobody designed that split by accident — the pins belong to the panel, the 8 KB belongs to a product that counts, displays and reports, and nothing more. The silicon is obsolete by catalogue standards and the installed base is not, which is why these recoveries keep arriving.
What That Ratio Means for a Recovery
Firmware that fits 8 KB while driving a 192-segment panel is dense. Every routine is load-bearing; there are no leftovers. Segment maps are table-driven, the multiplexing interrupt runs on a tight period, and the calibration constants sit next to the tables that use them. In a disassembly this shows up as code that reads nothing accidentally: every peripheral register reference belongs. For the analyst it is good news — dense firmware with a clear structure is quick to verify — but it removes slack from the delivery: a hole of even a few words in the array is a visible fault in the display’s behaviour, not a subtle one.
Sizes and Boundaries
Flash occupies byte addresses 0x000000 to 0x001FFF: 512 Intel HEX records at 16 bytes. Erased cells read 0xFFFF. Code protection is a single gate across the array; a locked part reads 0x0000 back while the device ID at 0x3FFFFE stays accessible. The trap is the sibling: the PIC18F8490 is the same 80-pin package, the same 192-pixel driver, the same peripherals — with 16 KB instead of 8 KB. Markings on refurbished parts are not always trustworthy, so the ID read happens before any other work. A 1,024-record file does not belong to this device.
The Missing EEPROM and the Display Config
Like every member of the DS39629 family, the 8390 has no data EEPROM. The stored values a meter needs — trim constants, serials, usage counters — live in a flash page the firmware rewrites, which the array read captures, or in an external serial device on the board, which it does not. And the LCD’s bias mode, multiplexing and drive clock are configuration bits at 0x300000, outside the array. Deliver those with the code: a byte-identical image with wrong display configuration produces a rebuilt unit whose panel misbehaves while the firmware runs perfectly — the fault that generates the most confusion in this family’s rebuilds.
Why 8 KB Designs Look the Way They Do
A part with this little code driving this large a panel almost never uses a high-level language comfortably. The image is likely assembled by hand or generated from a heavily constrained toolchain, and it shows: short routines, tables instead of computed values, tight reuse of the 768 bytes of SRAM, and a multiplexing interrupt that owns the timing. That density is an advantage for verification — structure is visible, and anything anomalous stands out — but it leaves no margin for delivery errors. A single corrupted record inside a segment table produces a wrong digit on the panel every multiplex cycle, so the two-pass byte comparison is not a formality on this part; it is the check that catches the one damaged sector that would otherwise ship.
The EUSART with LIN support hints at where the design’s communication went: metering nodes that report over LIN carry protocol constants and address assignments inside the 8 KB, and those regions are dense enough to spot by shape. If the rebuilt node must join an existing LIN network, confirm that region came through intact before anything else is declared done.
One more consequence of the tight code space deserves its own sentence: the array leaves no room for a copy of anything. Larger parts can lose a page and still contain a second copy of a critical table somewhere else; the 8390 cannot. Every verification pass therefore carries full weight, and the delivery standard — two passes compared byte for byte, with a third arbitrating any disagreement — exists because there is no redundancy inside the image to fall back on. The part’s economics made the firmware small; the recovery standard makes up for it in care.
Verification
Two independent flash passes compared byte for byte, config words delivered separately, the 512-record array scanned for holes near the segment tables, reset vector resolved, ID reconciled with the marking. Chip extraction analysis describes the review; reading the program memory the two-pass standard.
The 64-pin members — PIC18F6390 and PIC18F6490 — drive 128 pixels and follow the same logic. Send the marking photograph and what the display should show when the board works; the services page lists deliverables and contact us covers a specific device.