I am trying to understand a HEX file I compiled with Microchip MPLAB X IDE using the Microchip MPLAB XC16 Compiler.
Concerning the MCU, I am targeting the PIC24EP512GU814. However the scope of this question should at least apply to all PIC24 MCUs.
To compile the example HEX below, during the "New Project" wizard, I selected Samples > Microchip Embedded > PIC24 C Template and picked the XC16_24EP512GU814 configuration.
According to the PIC24EP / dsPIC33 Datasheet section 4.1.1 page 48, The memory is segmented into 16-bit words, such that each position (0x0000, 0x0001, …) contains 16 bits. On the same page of the datasheet, program instructions are said to be 24-bit and span 2 words, such that the most significant byte of the most significant word is zero (00000000b).
This does not appear to be consistent with the compiled HEX file. Here are the first 5 lines of the file, numbered and with the different parts spaced out according to the Intel HEX specifications.
1. :02 0000 04 0000 fa
2. :08 0000 00 0002040000000000 f2
3. :02 0000 04 0000 fa
4. :10 0008 00 c8020000ce020000e4020000d4020000 92
5. :10 0018 00 da020000e8020000ec020000e0020000 42
Consider lines 4 and 5. The first field correctly counts 0x10 (16) bytes in the data field. However, the second field which denotes location in the memory jumps from 0x0008 to 0x0018, or 0x0010 (16) positions.
From my interpretation, this means that this particular HEX file is 8-bit instead of 16-bit because each position is occupied by one byte.
- Is there a way to make the compiler output a 16-bit file?
- Is this file still valid for a 16-bit MCU? How can I interpret the HEX file so that I can manually flash the MCU?
Best Answer
Intel HEX files are always byte-addressed. This does not mean they can't handle information for other word sizes, only that there needs to be a convention about how those words are mapped to the bytes of the HEX file.
Just like with all the other non-byte addressed PICs (PIC 10, 12, and 16), the addresses are doubled in the HEX file. PIC programmer software knows this and interprets the HEX file addresses accordingly. This is of course all well documented in the programming spec for whatever part you want to program.
You say you want to make your own programmer. That's fine as long as you understand this will take way more time and frustration than just getting a known working one. If the point is the experience and learning of making your own, then fine, but otherwise go buy one.
If you really do want to make your own, you should look at the code for my PIC programmers. All the host code and firmware is open and available in the Development Software release at http://www.embedinc.com/picprg/sw.htm. By looking thru the host source code, you can see how there are flags indicating whether HEX file addresses are doubled for various parts of the PIC's memory.
If you make your programmer compatible with my PIC programmers protocol, then you can make use of all my host-side tools. This could be very helpful when bringing up your system since you have known working code on the other side. The protocol spec may look intimidating at first, but look carefully and you will see much of it is optional, especially if you plan to only support a single PIC.