1

I have parsed hex files for the purpose of bootloading before. This is my first time with a hex file generated using Microchip's XC32 tool chain. Right away I noticed what appears to be a discrepancy between the hex file and the disassembly.

The first 3 lines of the hex file:

:020000040000fa
:020000041d00dd
:10000000030000100000000040f3060000000000a4

From the listing file:

9d000000 <_reset>:
9d000000: 10000003 b 9d000010 <__reset_switch_isa>
9d000004: 00000000 nop

9d000008 <__reset_micromips_isa>:
9d000008: f340 0006 jalx 9d000018 <_startup>
9d00000c: 0000 0000 nop

Notice that address 9d000008 looks like it should contain 0x06 in the listing file. However, the hex file seems to indicate 0x40 at this location. The following 3 bytes are also not in the expected order.

:10 0000 00 03 00 00 10 00 00 00 00 40 f3 06 00 00 00 00 00 a4

When I look though the file other records are as expected, but the bytes pertaining to this jalx instruction word seem to be out of order. Can someone set me straight?

Thanks!

UPDATE: Another perplexing data point. If I flash the hex file into the part using the debugger (not using my bootloader). Then if I view the execution memory and disassembly listing, I see the following:

Address     Instruction     Disassembly
1D00_0000   10000003        BEQ ZERO, ZERO, 0x1D000010
1D00_0004   00000000        NOP
1D00_0008   0006F340        SLL S8, A2, 13
1D00_000C   00000000        NOP

When the IDE reinterprets the code that it programmed in, it now shows a SLL instruction not a JALX. This is compiler generated startup code so I cannot be sure what it should be. The byte order matches the hex file not the listing file, so the Microchip tools interpret the hex file as I would but this does not match the listing file.

user3692971
  • 181
  • 2
  • 10

2 Answers2

1

I posted this question on the microchip.com forum and a couple users there provided the answer.

Basically the JALX instruction in the listing file excerpt is formatted in microMIPS not MIPS32. So there is not actually a discrepancy between the listing file and the hex file. The hex file is interpreted with each byte written into ascending address locations as I was attempting to do. However, viewing the disassembly as I did in the update does no interpret the instructions as microMIPS, so the disassembly for that instruction is incorrect when viewed through the IDE. When the JALX is executed, a flag in the CPU informs the processor to treat this instruction as mircoMIPS.

For more information, see the excellent responses I received at:

http://www.microchip.com/forums/FindPost/986740

user3692971
  • 181
  • 2
  • 10
0

It looks like the listing is using Little Endian for those 16-bit values. If that were meant to be a 32-bit value, the 0x06 would come first.

As long as that's the case, there's not really a problem.

donjuedo
  • 2,475
  • 18
  • 28
  • The hex file is in Intel format. If the 8th byte after the : is only 0 or 1, then it is I8=16 bit. If it is is 0 to 3, then is is I16=20 bit. if it is only 0, 1, 4, 5 then it is I32=32 bit. Microchip normally uses I8. – cup Apr 11 '17 at 04:34
  • @cup. Thanks for your input. All of the Microchip generated hex files I have seen have been I32. In the snippet that I posted above the first 2 records are type 4 to allow 32 bit addressing. – user3692971 Apr 11 '17 at 16:34
  • @donjuedo, Thanks for your response. I am definitely not an expert, but I have only ever seen bytes listed in consecutive order by ascending address in data records. If that can change how would an interpreter know? Based on the updated information I posted, I do not think that is happening in this case. – user3692971 Apr 11 '17 at 17:20
  • Maybe it is simply some reading aid for the listing, and is the 32-bit instruction mostly split in a 16-bit opcode + a 16-bit immediate value. (or combination of register identifiers). Such notation then makes it easier readable – Marco van de Voort Apr 18 '17 at 09:01