4

I have this .hex file:

:020000040000FA
:020000000528D1
:080008000528831686138312FC
:1000100015280F30A0000D2008007F30A100A00B94
:1000200012280800A10B12280D2886130920861714
:040030000920152866
:02400E00B03FC1
:00000001FF

I know it has been burned on a PIC, but I don't know what PIC.

What can we say about the identity (part number, family, etc.) of the chip with only this data?

  • It's impossible to say from the hex file alone. You'll have to verify them all against this file, one at a time. – Dave Tweed Mar 24 '13 at 15:29
  • @DaveTweed is there something you can say? Family perhaps? (edited my question as well) –  Mar 24 '13 at 15:31

1 Answers1

10

The first thing to do is to see what values the HEX file contains at what addresses. Here is the output of my HEX_DUMP program on your HEX file:

00000000-00000001 (2): 05 28
00000008-0000000F (8): 05 28 83 16 86 13 83 12
00000010-0000001F (16): 15 28 0F 30 A0 00 0D 20 08 00 7F 30 A1 00 A0 0B
00000020-0000002F (16): 12 28 08 00 A1 0B 12 28 0D 28 86 13 09 20 86 17
00000030-00000033 (4): 09 20 15 28
0000400E-0000400F (2): B0 3F

The last line is most likely the config word, which means this is for a traditional PIC 16. For those PICs, the HEX file addresses are doubled since each PIC address holds 14 bits and HEX files only hold 8 bits of data per address. The last line is therefore setting the PIC address 2007h to 3FB0h, which is exactly the kind of thing you'd expect the end of a HEX file for one of these PICs to contain.

The exact PIC 16 model is impossible to tell. Since we know it is a PIC 16, we can have MPLAB show us the dissassembled code:

To get this I set the processor in MPLAB to a 16F877, since that is a full memory traditional PIC 16.

Note that the instructions are quite plausible, although this is clearly written by someone that didn't really know what they were doing and probably didn't even use the linker.

The GOTO at 0 is probably attempting to jump 1 past the interrupt routine at 4, although that doesn't apparently exist since a GOTO 5 there makes no sense (at least to anyone that knows what they are doing, there is a lot of bad code out there). The next instruction attempts to set the bank, mess with TRISB, mess with the bank again, and jump to 15h.

I'm not going to try to decode the rest of this mess, but it seems quite certain we have the right processor architecture. We can't know the exact model because this would actually run on most basic PIC 16. If you decode the config word, you might get a clue to narrow down the model more, but I really don't think you can get to a exact model because this code will in fact run on a bunch of them.

Olin Lathrop
  • 310,974
  • 36
  • 428
  • 915
  • In addition to the disassembly review: the code at 15h is toggling RB7. In addition to that, there is a call to 09h, which is an ordinary delay function (though not very neat). So this program is most likely to be a blink-a-LED, hence the bad programming style - it's written by an absolute beginner. Also, thanks for the 16F family! –  Mar 24 '13 at 16:02
  • 2
    Not being an EE, I come here to be awed by answers like this. Thanks, all! – New Alexandria Mar 24 '13 at 20:02
  • "clearly written by someone that didn't really know what they were doing" - Can you say this not knowing if the code was written in C and the compiler made this supposed mess? – justing Mar 26 '13 at 18:51
  • @justing: Yes. The compiler doesn't put a GOTO 5 at location 4, for example. – Olin Lathrop Mar 26 '13 at 20:33
  • When the question rises why that's bad: it's bad because a `GOTO` uses two clock cycles, while a `NOP` would only use one. The extra clock cycle doesn't have any use on this point. –  Mar 27 '13 at 18:24
  • @Camil: It's also pointless for other reasons. 4 is the interrupt vector location, but interrupts were not used in this code, so there is no reason the program couldn't have started at 0 and just kept going. Even so, explicitly proceeding to 5 from 4 is pointless as whatever code is at 5 could have just as well been put at 4. This was written by someone that didn't bother to read the datasheet and understand the architecture, and as a result is programming by myth and superstition and stuff he saw on the internet (they can't put anything on the 'net that's not true, right?). – Olin Lathrop Mar 27 '13 at 18:34