No sumcheck code in a '95 MEMCAL

[Roger Heflin]

On Thu, 5 Nov 1998, Ludis Langens wrote:

> Roger Heflin  <rah at horizon.hit.net> wrote:
> > Do we know if the actual checksum program is on the prom (the one
> > that sets the code) is actually in the prom?  I would think the that
> > code that actually verifies the prom is good would need to be
> > elsewhere.
> 
> The ECMs with an EPROM bigger than 4K bytes don't have any other ROM in
> the system.  There's no place else for it to be.  So, if there is a
> checksumming function, it is in the EPROM.
> 

There is not other rom on the board, Motorola has one in the CPU's
themselves, and there is the possibility that the car comes up with
the other rom, checks the socketed rom and resets into that rom with
the CPU rom disabled.  That is something I could see them doing.  My
car will run with a bad rom (read bad checksum, SES light) which would
imply that it may run without a rom (it runs really really bad), which
would imply that there is code someplace else running things.  Does
anyone know if the vehicles will run without a rom in it?
 
>
> I was also under the impressions that the checksum code
> > was really just a do nothing loop of sorts, maybe they decided to do
> > something else there.
> 
> It is part of the reset vector function.  The checksum is computed quite
> early in the initialization code.  It is easy to spot the checksum loop
> because it tickles the watchdog every n bytes.
> 

I will have to see if I can find that code.  I have not found any
loops that run through all of the rom (or a large part of it) yet.
I wonder why they check the rom on reset?  Do they think it is that
likely that it could have went bad? or are they just covering all of
the bases and finally decided that they had not had any of the type of
problems so quit doing it?

 > "John Hess" <johnhess at cris.com> wrote:
> > Did you checksum only the data _after_ the checksum in the PROM or check it
> > against the PROM checksum.  I don't know about this particular prom;  but,
> > bytes 0 through 8 are disregarded in the checksum on the earlier models.
> 
> Yup, I computed it without the first 8 bytes.  It doesn't match.  The
> checksum field in the 7th and 8th bytes appears to have a placeholder
> value: $3535.  The PROM does not self checksum itself, nor does it
> invoke any external code that might do a checksum.  The PROM also has no
> references to the checksum field, and in fact has no references to any
> of the 3rd through 9th bytes.
> 

I guess you might try putting a bad checksum in there and see if it
notices.  If it does, it would seem to be taking care of it somewhere.
My thought is there is a built in rom that starts things first and is
later disabled.  I am not really sure how they would implement that.  
 
> -- 

> Ludis Langens                               ludis (at) cruzers (dot) com
> Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/
> 
>