A hex file can be complete at the flash level and empty where it matters. On a PIC18F4510 the configuration words sit at 0x300000, and the only thing that carries an address that high is a record type most simple parsers throw away without saying so.
The part is a 32 KB device: 16,384 instruction words at 0x000000–0x007FFF, 1,536 bytes of SRAM, 36 I/O pins, thirteen channels of 10-bit ADC sampling at 100 ksps, one CCP and one ECCP module, and 40-pin PDIP or 44-pin TQFP and QFN packaging. It belongs to the PIC18F2X1X/4X1X datasheet, alongside the 48 KB PIC18F4515.
Four Record Types, One of Them Optional
Intel HEX is a line format. Each line starts with a colon, then a byte count, a 16-bit address, a record type and the payload, ending with a checksum.
| Type | Name | What it carries |
|---|---|---|
| 00 | Data | The actual bytes, at the current base address |
| 01 | End of file | Nothing; terminates the parse |
| 02 | Extended segment address | Base address, paragraph units |
| 04 | Extended linear address | Base address, upper 16 bits |
The 16-bit address field in a data record can only reach 64 KB. Everything above that — including the PIC18 configuration space at 0x300000 and the device ID at 0x3FFFFE — is reached by emitting a type-04 record that sets the upper half of a 32-bit address, then following it with ordinary data records whose 16-bit address is the lower half.
A parser that handles 00 and 01 and ignores 04 does not error. It keeps writing data records at whatever address the 16-bit field says, so the config bytes land at 0x0000, 0x0002 and so on — overwriting the reset vector, or being discarded as out of range. Either way the file opens, the byte count looks right for the flash range, and the configuration is not in it.
Why the Checksum Does Not Save You
The usual completeness check is a checksum over the flash range. Compare 0x000000–0x007FFF between the recovered file and a reference, or compute a CRC and compare it to the one in the delivery note.
That check passes on a file with no configuration words, because they are not in the range being summed. The file is 32 KB of correct code with a missing header, and every tool that looks at the code says it is fine.
The board then fetches the reset vector and runs the startup code, until it configures the oscillator — which comes from CONFIG1H, reading as erased. On this family an erased CONFIG1H does not select the HS mode a crystal needs. The device sits in a clock mode the board was not built for, and the symptom is a dead board with a perfect hex file.
Reading the File at Record Level
Three checks that take a minute:
1. Count the record types. A complete PIC18 image has type-04 records before the config and ID blocks. If the file contains only type 00 and one type 01, the upper address space was never written. 2. Look for the config address. Search the file for 0x300000. In a type-04 scheme it appears as a base record with payload 0x0030, followed by data records starting at 0x0000. 3. Check the last data address. It should be 0x3FFFFF or 0x3FFFFE if the device and revision IDs are included. If the highest address in the file is 0x7FFF, the file stops at the flash boundary.
None of these needs a programmer — only that the file be opened as text.
What a 4510 Image Should Contain
- 32 KB of program memory at
0x0000–0x7FFF, in four 8 KB protection blocks - Twelve configuration bytes at
0x300000 - 256 bytes of data EEPROM at
0xF00000 - Device ID at
0x3FFFFE, revision at0x3FFFFF
A Note on the 4515
The 4515 is the 48 KB member of the same family and package. A 4510 image programs into a 4515 and runs — the top 16 KB stays erased — which is a reasonable substitution when the 32 KB part is unavailable. The reverse does not work: a 4515 file truncated to 32 KB loses whatever lived above 0x7FFF, often the bootloader itself.
Reading the program memory out of this family is routine work, and the reading the program memory page describes the sequence. The thing to insist on is the format: Intel HEX with the extended address records intact, not a .bin truncated to the flash size. A .bin cannot carry 0x300000 at all, which makes the omission permanent.
If a file has arrived and the board does not start, the frequently asked questions page covers the common causes, and contact us will take the file and the marking photograph together.