The PIC18F8393 sits in an awkward place for anyone planning a recovery. It has four times the analogue resolution of its neighbours and half the flash, and it drives an LCD directly. That combination means the firmware is dense, the parameters are analogue, and a large part of the device’s behaviour is set in configuration rather than in code.
Documented in DS39896 alongside the PIC18F6393, 6493 and 8493, the part offers 8,192 bytes of program flash — 4,096 single-word instructions — 768 bytes of SRAM, 66 I/O, an 80-pin TQFP body, a twelve-channel 12-bit A/D converter, and an LCD module capable of 192 pixels across four commons. Operating voltage is 2.0 to 5.5 V, with the LCD driver happy down to 2.0 V on its own bias generator.
The applications follow from the feature list: utility meters, thermostats, medical handhelds, security panels. All of them display something, measure something, and remember a calibration.
8 KB Is Not Much
A 12-bit A/D conversion, an LCD refresh routine, a serial protocol and a measurement averaging loop will consume most of 4,096 instructions. Compiled C on this architecture typically lands around 1.5 to 2 instructions per source statement, and an extended instruction set is available to reduce stack pressure in re-entrant code.
The practical consequence is that a recovered image has little slack. Every routine in it is load-bearing, and code that looks like dead weight in a disassembly is more likely to be a state-machine branch that runs once an hour than an actual leftover.
The LCD Mapping Is Not in the Code
Segments are assigned by a driver that maps display RAM to COM and SEG lines through a fixed table, but the electrical behaviour of that table — bias level, drive waveform, frame rate — comes from the LCD control registers and, critically, from the configuration words.
Config on this device holds the oscillator source, the brown-out threshold, the watchdog, and CP itself. Somewhere in the same configuration space sits the LCD bias and the multiplex setting. Get those wrong and the recovered code drives a display that is dim, ghosting, or entirely dark while running a byte-perfect copy of the original logic. The product looks broken and the code is not.
This is the same trap as on any device with an analogue front end, sharpened by the fact that a display is the only user-facing output. If the panel does not light, nobody can tell whether the measurement routine works.
Twelve bits of A/D across twelve channels makes the calibration question unavoidable, because a 12-bit converter resolves one part in 4,096. The offset and gain trim for that resolution is stored as data, not as code. On this part the parameter store is a flash page the firmware writes at test time rather than a separate array — so it is recoverable with the code, which is the good news.
The Protection Gate
CP0 through CP3 in CONFIG5L cover four equal quarters of the 8 KB — 0x0000–0x07FF, 0x0800–0x0FFF, 0x1000–0x17FF, 0x1800–0x1FFF. CPB guards the boot block. CONFIG7L holds the EBTR bits that prevent running code from reading the array through TBLRD.
Set one and the array stops answering over ICSP while the device ID at 0x3FFFFE continues to read normally. Nothing is encrypted; the gate is closed. Because it is a flash cell and not a fuse, a programmer with access can reopen or reclose it, so a copy protection scheme on this part does not necessarily consume the sample.
What the Image Should Be Checked For
The reset vector at 0x000000 must land on real code, not in a hole. The interrupt vectors at 0x000008 and 0x000018 likewise. The region above the last used byte should be uniform — a single differing value inside an otherwise blank tail is a partial read, not data.
Then the checks this part specifically needs: does the image contain a cluster of constants consistent with twelve-channel trim values, and does it contain the LCD segment table as a contiguous block? Both are recognisable by shape without symbols, and both separate a file that runs from a file that produces a usable instrument.
That work is chip extraction analysis, and it is why a delivered image includes a report rather than a bare binary. Reading the program memory describes the verification method.
Compared to a Code-Heavy Part
An engineer coming from a PIC18F2458 recovery will be used to a 24 KB array where code dominates and config is a footnote. Here it inverts: 8 KB of code that is mostly I/O and arithmetic, and a configuration block that decides whether the product produces a reading anyone can see.
Send the marking photograph and say what the display shows when the board works. That sentence tells us more about the expected image than a part number alone. Contact us for a specific device.