Check Sum issue

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

After programming a Mega162 in assembly via Studio 4 and STK500 I sent the Hex file to a production programmer along with a programmed chip to compare the 2 check sums.
He is using a BP Micro 1700 to flash the chips.

The check sums dont seem to be the same in the programmed chip I sent and the chips he flashes at his end however both chips perform as they should when tested.

(The fuse and lock bit settings are the same).

Could this be comething to do with the different hardwares/softwares used?

At the start of my program I am transferring values from EEPROM to SRAM locations, if the EEPROM values were different in the 2 chips would this result in a different check sum?
I would expect that 2 new chips programmed at the same time on the 2 differnt programmers with the same Hex file would result in the same check sum in each chip..?

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

I don't know for sure. Are you and he using the same algorythm to do the checksum?

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

When he generates and checksum on the BP-micro, is he doing a checksum of the entire device memory? Or just the portion used by the hex file?

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

And if the entire is it assumed/confirmed that unprogrammed bytes are 0xFF?

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

clawson wrote:
And if the entire is it assumed/confirmed that unprogrammed bytes are 0xFF?

Could you expand on that Cliff please. Do you mean the configuration bytes?
Do I need to configure all memory space that I am not accessing e.g. if Im not using USART 0 do I need to make all registers for this configuration (like UDR0) = 0xff?

The configuration bytes in both chips are comming back the same so I presume it is only the Hex file check sum of both chips that he is comparing.

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

In the good old days when you sent code off to a manufacturer for a ROM code you actually sent a full 8KB or 16KB or whatever the device size was even if your program was just 6.5K or 11K or whatever. Almost every PROM programmer in the world pre-filled the buffer with 0xFF's so that for the 8K device the .hex held 6.5K of code and 1.5K of 0xFFs. For the 16K is was 11K of code and 5K of 0xFF. That way when your PROM programmer showed a checksum for the full 8K or 16K and when his programmer showed a checksum for the full 8K or 16K it was guaranteed that the numbers agreed.

In this day and age (certainly if you use WinAVR that includes screc_cat) you can use tools to pad out .hex files to the device size with 0xFF's in the unused space (even in "holes" within the early parts of the code) so that a complete checksum should always agree.

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

Cliff

In my head I think I am comparing what you describe to the following:

If I have 2 identical jigsaws of a map of the world.
I build one with only the places I am interested in while my programmer builds the entire map.

If I then fill in the gaps and complete the jigsaw and send that to him I can see that he will have 2 completly filled jigsaws and they will equal each other but how can he know from this what the original jigsaw I was interested in equals in terms of pieces used?

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

I don't follow your analogy and anyway jigsaw's (unlike ROMs) do not have "unused bits". Here's a slightly contrived example:

#include 

// Makefile has LDFLAGS += -Wl,-section-start=.mysect=0x300
uint8_t string[] __attribute__((section(".mysect"))) = "Hello world" ;

int main(void) {
  while(1) {
  }
}

which leads to .hex file:

:1000000009C00EC00DC00CC00BC00AC009C008C09A
:1000100007C006C011241FBECFE9CDBF02D002C069
:08002000EFCFFFCFF894FFCFF2
:0C03000048656C6C6F20776F726C6400B5
:00000001FF

which is really (two halves):

:1000000009C00EC00DC00CC00BC00AC009C008C09A
:1000100007C006C011241FBECFE9CDBF02D002C069
:08002000EFCFFFCFF894FFCFF2

:0C03000048656C6C6F20776F726C6400B5
:00000001FF

but the safest thing would be to ship (for this 1K tiny13):

:2000000009C00EC00DC00CC00BC00AC009C008C007C006C011241FBECFE9CDBF02D002C013
:20002000EFCFFFCFF894FFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF2
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:20006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:20008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:2000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:2000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40
:2000E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF20
:20010000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
:20012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF
:20014000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF
:20016000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9F
:20018000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7F
:2001A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5F
:2001C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3F
:2001E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
:20020000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
:20022000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDE
:20024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE
:20026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E
:20028000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7E
:2002A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5E
:2002C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3E
:2002E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1E
:2003000048656C6C6F20776F726C6400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB5
:20032000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDD
:20034000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBD
:20036000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9D
:20038000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF7D
:2003A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D
:2003C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3D
:2003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
:00000001FF

where it's been padded so all unused areas are 0xFF. I can tell you that for this 1K:

LRC: 0003E123h
CRC16: 09DFh
CRC32: 95AAD25Dh
CCITT: 1993h
SumCheck: 22E8h
XOR: 9Bh

If I send this to someone they should be able to program it into a device, read it back then verify on or more of those same checksums.