Calculating the Checksum

[TBK]

In the GM roms, the CHECKSUM is just the sum of all of the bytes over a
particular range. Generally from just after the PROMID, VIN (P4), and
CHECKSUM VALUE. The results is a double byte.

It just don't get any simpler than that.

TK
-----Original Message-----
From: Scott Schaaf <SSchaaf at ERINet.com>
To: diy_efi at efi332.eng.ohio-state.edu <diy_efi at efi332.eng.ohio-state.edu>
Date: Friday, September 11, 1998 9:23 PM
Subject: Re: Calculating the Checksum


>Usually,   a block of addresses is added up,   then a 'checksum' is placed
>IN that block to make the sum add up to hex zero.   Such as sum = FFFD,,,,
>checksum value = 3,,,,,   FFFD+0003=0000.
> Scott...
>
>----------
>> From: David A. Cooley <n5xmt at bellsouth.net>
>> To: diy_efi at efi332.eng.ohio-state.edu
>> Subject: Re: Calculating the Checksum
>> Date: Friday, September 11, 1998 10:18 PM
>>
>> Hi Don,
>> The checksum is a hex number that is arrived at from the data in the
>> eprom... Changing a bit changes the checksum.  The data is checksummed,
>and
>> the checksum value is also burnt into the chip... The ECM verifies that
>the
>> data checksum and the stored checksums match to ensure the data is
>"good".
>> Not sure what the calc is to arrive at the checksum though.
>> Later,
>> DAve
>>
>> -----Original Message-----
>> From: Don.F.Broadus at ucm.com <Don.F.Broadus at ucm.com>
>> To: diy_efi at efi332.eng.ohio-state.edu <diy_efi at efi332.eng.ohio-state.edu>
>> Date: Friday, September 11, 1998 3:40 PM
>> Subject: RE: Calculating the Checksum
>>
>>
>> > Could you please explain  checksum for me.  I thought checksum was a
>> >hex value
>> > That was used to verify if an EPROM had the correct program  data.
>> >
>> >
>> >Thanks  Don
>> >
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Roger Heflin [SMTP:rah at horizon.hit.net]
>> > Sent: Friday, September 11, 1998 12:55 PM
>> > To: diy_efi at efi332.eng.ohio-state.edu
>> > Subject: Re: Calculating the Checksum
>> >
>> >
>> >
>> > A couple of questions.  I have a 93 Z28  (32kb) eprom.  I am working
>> >on the
>> > disassembly.   I have put the eprom in memory at several locations,
>> >the
>> > location that seems to work is $8000, with it there, the code seems
>> >to
>> > be writing to things listed as ram in my databooks, any only reading
>> >from
>> > things that are known to be rom.   Is this a resonable method to
>> >use?
>> >
>> > Another thing, I assume the checksum code is in the build in rom,
>> >and not
>> > in the rom I have, since you really can't validate a checksum with
>> >code
>> > you don't even know if works.
>> >
>> > Mostly right now I am just decoding what looks like initialization
>> >stuff.
>> > I assume that probably the block learns/integrators would be
>> >initialized to
>> > 128. I also would guess that alot of the other things would be
>> >initialized to
>> > 0.  So far things look pretty simple, but I am only into the simple
>> >stuff.
>> >
>> > I have a 68hc11 disassembler program, a detailed 6809 instruction
>> >book and
>> > decoder card, and a 1988 vintage motorola single chip microcomputer
>> >data
>> > book that lists quite a few variants that all use pretty much the
>> >same
>> > instruction set with a few additions, and extra ram/rom/portio/ad
>> >varing
>> > depending on what was specified.    I would guess that GM is using a
>> >
>> > custom one of these chips, probably with a burned into the chip rom,
>> >for
>> > default operation.
>> >
>> > Roger
>> >
>> > On Fri, 11 Sep 1998, Georg Faustmann wrote:
>> >
>> > > If the system is a Delco unit, then the Checksum on/off byte may
>> >be at
>> > > $0008, set this to $AA, the checksum (stored at $0006,$0007)
>> >should be the
>> > > total of all the bytes from $0008 to then end of the chip.
>> > >
>> > > In some cases the address of the checksum switch could be offset,
>> >eg $3008,
>> > > $8008.
>> > >
>> > > Notes on how to find checksums:-
>> > >
>> > > If you had access to an emulator with a Romwatch (real time trace)
>> >type
>> > > function where the actual bytes being read at that moment in time
>> >are
>> > > highlighted, then you can sit there and watch where the bytes
>> >start to be
>> > > sequentially accessed by the CPU (usually every 10 seconds or so),
>> >you can
>> > > then scroll down until you find out where they stop being
>> >accessed, and
>> > > will give you the start and end point of the checksum. Then add
>> >these range
>> > > of numbers up, and look for a 16 bit value that is the last 16
>> >bits of this
>> > > sum, and search for this number outside of the checksum range,
>> >because it
>> > > can't be in the checksum area.
>> > >
>> > > Georg
>> > >
>> >
>>
>