One Hundred Twenty-Eight KB On Twenty-Eight Pins
The PIC18F27J13 doubles the PIC18F26J13: 128 KB of program memory (0x0000-0x1FFFF), 3.8 KB of SRAM, 48 MHz, Deep Sleep, PPS, hardware RTCC, CTMU, three ECCP modules, two EUSARTs, two MSSPs, three comparators, and the twelve-bit ADC with ten channels that marks the J13 generation. No USB – that remains the J50/J53 territory. No EEPROM; persistent data lives in emulated-EEPROM flash regions.
Lock And Sweep
PIC18 configuration at 0x300000: CP0/CP1, WRT, boot-block bits. Erased config 0xFF; locked array 0x0000. Sweep:
– Array: 0x0000-0x1FFFF. – Configuration: 0x300000 window. – ID: 0x3FFFFE-0x3FFFFF.
The 128 KB boundary separates the 27J13 from the 64 KB 26J13 and from the USB-equipped PIC18F27J53 in the same package – three dies share the footprint, so the ID word decides before any interpretation.
Image Anatomy
The doubled array accommodates larger stacks and logging structures; twelve-bit results keep the scan loops wide as on all J13 parts. The RTCC wake scheduler and CTMU touch logic appear as on the smaller member, and emulated-EEPROM parameter blocks near the array top carry the persistent values a clone must reproduce byte-for-byte.
The Session
A hundred and twenty-eight kilobytes in a twenty-eight pin body almost always holds a bootloader, so the session starts by finding the reset vector’s jump target and treating everything below it as a separate program. The array is then read as two images – boot block and application – each with its own checksum, which is also how they are delivered.
Deliverables
HEX file, annotated disassembly with the analog, control and parameter regions labeled, configuration report, checksum tied to the die.
The 128 KB Member
The 27J13 doubles the 26J13 array to 128 KB at 0x0000-0x1FFFF while keeping the 28-pin body, 4 KB of SRAM and the twelve-bit converter. An image of that size in a 28-pin part almost always contains a bootloader, because 128 KB is enough to justify field updates and the low block is where the update logic lives.
Reading Past A Bootloader
The reset vector of a bootloaded 27J13 jumps to an address above 0x2000, and the application’s own vector table sits at that target. The session records both boundaries: the bootloader occupies the low block up to its protected limit, and the application fills the rest. When the client later reflashes the image onto new silicon, those boundaries have to be reproduced exactly, which is why the report gives them as addresses rather than as a description.
– Array: 0x0000-0x1FFFF, 0x3FFF erased, 0x0000 protected. – Configuration: 0x300000-0x300007. – ID: 0x3FFFFE-0x3FFFFF.
Coefficient Tables At Double Size
With 128 KB the firmware can afford lookup tables instead of computation, and that is what the disassembly typically shows: long constant runs, short code. The twelve-bit ADC coefficients, the temperature curve and the linearisation table are all present as separate blocks, and each is labelled by the routine that indexes it rather than by address alone.
Handover Package
HEX at word addresses, annotated disassembly with the bootloader boundary and the table blocks marked, configuration report, checksum tied to the die. Protection left as found.
Confirming The Bootloader Boundary
Two independent checks pin the boundary down: the jump target of the reset vector, and the address below which the client’s own linker map placed nothing. When both agree, the split is reported as confirmed; when they disagree, the session re-reads the low block and looks for a second vector table, which happens on parts that were updated with a bootloader added after the original build.
One More Check
Before release the image is loaded into a programmer set to the correct device and verified against itself. A 128 KB file that verifies is one whose address decoding is right; a file that fails at a high address usually means the sweep stopped early rather than that the die is damaged.
To copy a locked 27J13, use the services desk or the contact form.