Calculating the Checksum

[David A. Cooley]

Not a prob... Glad to have helped!
-----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: Monday, September 21, 1998 11:38 AM
Subject: RE: Calculating the Checksum


>Thanks for the info David, sorry it took so long to get back to you.
>                           
> 
>Don
>
> -----Original Message-----
> From: David A. Cooley [SMTP:n5xmt at bellsouth.net]
> Sent: Friday, September 11, 1998 9:19 PM
> To: diy_efi at efi332.eng.ohio-state.edu
> Subject: Re: Calculating the Checksum
>
> 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
> > >
> >
>