Sixty-Four Pins, Sixty-Four Kilobytes
The PIC18F46J13 sits at the top of the J13 line in pin count: 64 pins, 64 KB of program memory spanning 0x0000-0xFFFF, 4 KB of SRAM, a twelve-bit ADC, three analog comparators, three ECCP modules, two EUSARTs and two MSSPs, plus the CTMU, RTCC and PPS fabric that the whole J13 family shares. There is no data EEPROM on the die – any parameter block a designer needed lives in flash and is therefore inside the same protected region. Supply range is 2.0-3.6 V and the core runs to 64 MHz.
Because the package carries so many pins, boards built around the 46J13 tend to be the full-feature version of a product line: motor drive with three complementary pairs, a graphics or keypad interface on the parallel-ish port pins, and two serial links running different protocols at once.
Configuration Space And The Sweep Order
On PIC18 the configuration bytes live at 0x300000 through 0x300007, with the code-protect bits spread across CONFIG1L through CONFIG4H; the device ID sits at 0x3FFFFE and 0x3FFFFF. A read session walks the array first, then the configuration window, then the ID, because the ID read confirms which silicon revision the array came from – the J13 family shares a device ID prefix across capacities and the revision nibble decides whether a known errata applies.
– Array: 0x0000-0xFFFF, erased state 0x3FFF per word. – Under code protection every address returns 0x0000, which decodes as NOP and makes a locked part look like a long run of no-ops. – Configuration: 0x300000-0x300007, 1 KB erase block granularity. – ID: 0x3FFFFE-0x3FFFFF.
What The Image Looks Like
A 64-pin J13 image is dense. The three ECCP blocks appear as three clusters of period and duty register writes with dead-band setup, and the PPS routing table near the bottom of the array records which pin each peripheral was mapped to – without that table the disassembly names peripherals but cannot say where they go. The 12-bit ADC setup registers show the acquisition-time constants a designer tuned for their sensor impedance, and those constants are usually the reason a client cannot simply recompile from source they still have.
The RTCC and CTMU code is small but distinctive: a handful of unlock sequences followed by single register writes, sitting in a low page that also holds the interrupt vectors.
Failure Signatures Worth Knowing
Three patterns come back from the field on this part. A part that reads 0x0000 everywhere but returns a plausible ID is locked, not dead. A part that returns a valid ID and a partially readable array has a configuration block that was corrupted by a brown-out during a self-write, and the read has to be repeated with the configuration window re-read twice for comparison. A part that returns nothing at all usually has a failed VDDCORE regulator, and the recovery then goes through decapsulation rather than through the programming interface.
Deliverables And Handover
The handover is a HEX file at word addresses, a separate binary for any flash-resident parameter block, an annotated disassembly with the three PWM clusters, the serial links and the PPS table labelled, a configuration report listing every protect bit as found, and a checksum bound to the physical die. Nothing on the part is erased; the device goes back into its socket with the original protection intact.
If the same board exists in the 28-pin form, the PIC18F26J13 uses the identical core and memory map; the USB-equipped PIC18F46J50 shares the pin count but not the converter.
Delivery
The three PWM clusters are reported with their period, duty and dead-band values grouped per cluster, which is the form a client needs when porting the drive logic to a different bridge.
To start a 46J13 recovery, send the marking photo and the board function through the services desk or the contact form.