Question about verifying with AVRISP MkII

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm getting ready.to make some changes to an ATMega128 project I haven't touched in several years. I want to make sure I can restore the code to its current state if I screw things up. If I compare the most recent hex file on my PC to what's in the chip using the AVRISP MkII's Verify function, it passes. If I do the same with an unrelated hex file, it fails, so the latest hex file seems to be what's in the chip. However, if I use the Read function to read out what's on the chip, save it to disk, and then Verify that against the chip, it fails. Why? Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you do a "Read whole chip" that is exactly what it does.
When you "Verify a HEX file" it just compares memory with the HEX records.

Most AVRs are erased before programming. So if your app lives from 0x0000 to 0x5678, 0x5679 - 0xFFFF is full of word 0xFFFF.

If you think in bytes, this is 0x00000 to 0x0ACF1 and 0x0ACF2 - 0x1FFFF is full of byte 0xFF

If you don't believe me, look at the HEX file from the READ operation in an editor. Compare it with the HEX file from your app.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also are you actually diffing the .hex files? That often won't work. Say the original build generated 16 bytes per line iHex records but the readback generated 20 byte per line iHex records. They may contain the same binary information but the ASCII data in the file will be entirely different.

It's actually a better idea to convert the .hex files to binary and then use a binary compare tool (vbindiff in Linux is good!) to compare the tool. If you find you have different lengths only compare as far as the end of the shorter one (or perhaps pad it with 0xFFs to the length of the longer one - you should find that all the extra bit in the long one is 0xFF anyway).