Calculating the Checksum

Scott Schaaf SSchaaf at ERINet.com
Sat Sep 12 04:07:59 GMT 1998


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
> > >
> >
> 



More information about the Diy_efi mailing list