C4 Tech/Performance L98 Corvette and LT1 Corvette Technical Info, Internal Engine, External Engine

MEMCAL problems part II

Thread Tools
 
Search this Thread
 
Old 09-10-2005, 11:03 AM
  #1  
RocketSled
Burning Brakes
Thread Starter
 
RocketSled's Avatar
 
Member Since: Feb 2000
Location: Parker, Colorado, USofA
Posts: 1,247
Received 2 Likes on 2 Posts

Default MEMCAL problems part II

the details: 383, Superram, 89 ECU, Ed Wright custom PROM, TunerPro RT

I'd been making some pretty good headway with polishing up Ed's code and hit a snag.

-I'd noticed the chips I burnt wouldn't lock up the torque converter, but the romulator would. I've since verified with another programmer that the chips I'm burning DO have the information I THINK I'm programming them with.

-I was changing the speeds the TC locked up until I could get the Speedo calibrated for the new gears.

-During the test, the engine got rough and wouldn't hold an idle. The Auto Xray wouldn't talk to the ECU, and the primary fan turns on with the Key in Run and the engine stopped. (Like when you jumper the diagnostic pins)

-I swapped out the ECU thinking I may have zapped it. (The new ECU didn't change things.)

-Grabbed the factory service manual and troubleshot 'no communication between ECM and scantool. IT'S assessment was a bad memcal.

-Ordered a memcal from GM for a stock 89 Fbody. Inserted memcal. Fan did NOT turn on. Engine idled roughly, but better than with other memcal installed. Engine was clearly being controlled by the PROM, rather than limphome.

-Desoldered PROM, Inserted known good burnt chip, problem returned. Returned new prom to memcal, problem still there. (!)

-Soldered in a ZIF socket and triplechecked continuity. Problem is still there.

So. I've got good PROMS (I think), a Good ECU, two 'bad' memcals - neither of which will talk to the AutoXray...and I'm absolutely baffled.

(Anybody in Denver want to see if their ECU will talk to my AutoXray in my car? )
Old 09-10-2005, 01:46 PM
  #2  
-js-
Racer
 
-js-'s Avatar
 
Member Since: Apr 2003
Location: Detroit MI
Posts: 426
Likes: 0
Received 0 Likes on 0 Posts

Default

I suspect your problem lies in the memcal resoldering.
You said it worked with the new stock memcal however you didn't say if you were able to communicate with it.

A alternative to soldering is to buy an adapter like the moates G1 http://www.moates.net/product_info.p...products_id=32
Old 09-10-2005, 01:58 PM
  #3  
RocketSled
Burning Brakes
Thread Starter
 
RocketSled's Avatar
 
Member Since: Feb 2000
Location: Parker, Colorado, USofA
Posts: 1,247
Received 2 Likes on 2 Posts

Default

Stupid me didn't CHECK the communication. I heard no fan, got a better idle, then pulled it and went to town with the soldering iron.

Spent a good 90 minutes last night pulling the contacts out with a dental pic and soldering them to a ZIF socket. reseated everything, checked continuity using a multi-meter (alligator clip holding a pin), all pins appear well connected and there doesn't seem to be any cross connections.

You're right tho, I think Craig's my next best course of action...Good thing Katrina missed him! :O
Old 09-10-2005, 02:26 PM
  #4  
DOCTOR J
Burning Brakes
 
DOCTOR J's Avatar
 
Member Since: May 1999
Location: Greenwich, CT
Posts: 760
Likes: 0
Received 0 Likes on 0 Posts

Default

FWIW, I've found that it's miserably difficult to get good solder joints
between a GM memcal and a ZIF socket. I now use the Moates' Memory
Adapters exclusively.

You can look up his current pricing - an adapter board with an Aries ZIF
make a stable and easy way to change chips with little chance of a failed
connection.


Re the other problems, it's possible that your PROM programmer/editor
is not doing a check-sum after you change the bin; or there is a flaky
pin connection somewhere. Either situation will give a 'failed' memcal
result at the ECM POST diagnostics. Seems to me the ECM is also sensitive
to having a chip ID number that was in range of the original GM value.

Also, are you using a 16K chip? If not, are you using the correct offset on
a larger chip? The ECM only looks for the program data at one address -
if you miss that it won't find the proper data, even if it's readable in the
editor.

HTH
Old 09-10-2005, 02:45 PM
  #5  
RocketSled
Burning Brakes
Thread Starter
 
RocketSled's Avatar
 
Member Since: Feb 2000
Location: Parker, Colorado, USofA
Posts: 1,247
Received 2 Likes on 2 Posts

Default

Hmm, I'm using 27c256's almost exclusively...and in going back to some of the chips, I AM getting compare errors vs. the .bin files I was creating.

I'm not exactly NEW to programming, but I AM new to the whole hardware side of it. are the 256 chips 256k, or are they soem different bit representation? (8 bits * 32000 rows)

I also ordered two 28c256 chips thinking they were EEPROMS...but the programmer can't clear OR program them (a willem programmer)

It's frustrating because I don't know what I don't know. I've read a lot on the subject, but if you only have one of something, you can't really rule it out as bad.
Old 09-10-2005, 03:07 PM
  #6  
DOCTOR J
Burning Brakes
 
DOCTOR J's Avatar
 
Member Since: May 1999
Location: Greenwich, CT
Posts: 760
Likes: 0
Received 0 Likes on 0 Posts

Default

Seems to me the 165 ECMs use a 16K bin; 256 chips have 32K of space.
It's necessary to stack the 165 program, or pay attention to the starting
address in the bin. Moates' site has info on this, or do a search here
or on the TGO PROM board for instructions.

27x and 29x chips are flashable IIRC. Look up the 28x series on DigiKey
to see what you bought.

128 series chips are 8 X 16 = 16KBytes
256 serues are 8 X 32 = 32KBytes

There is lots of introductory info on the TGO board.
http://www.thirdgen.org/techbb2/show...hreadid=305250

Good luck.
Old 09-10-2005, 03:11 PM
  #7  
DOCTOR J
Burning Brakes
 
DOCTOR J's Avatar
 
Member Since: May 1999
Location: Greenwich, CT
Posts: 760
Likes: 0
Received 0 Likes on 0 Posts

Default

Seems to me the 165 ECMs use a 16K bin; 256 chips have 32K of space.
It's necessary to stack the 165 program, or pay attention to the starting
address in the bin. Moates' site has info on this, or do a search here
or on the TGO PROM board for instructions.

27x and 29x chips are flashable IIRC. Look up the 28x series on DigiKey
to see what you bought.

128 series chips are 8 X 16 = 16KBytes
256 series are 8 X 32 = 32KBytes

There is lots of introductory info on the TGO board.
http://www.thirdgen.org/techbb2/show...hreadid=305250

Good luck.
Old 09-10-2005, 03:36 PM
  #8  
DOCTOR J
Burning Brakes
 
DOCTOR J's Avatar
 
Member Since: May 1999
Location: Greenwich, CT
Posts: 760
Likes: 0
Received 0 Likes on 0 Posts

Default

Seems to me the 165 ECMs use a 16K bin; 256 chips have 32K of space.
It's necessary to stack the 165 program, or pay attention to the starting
address in the bin. Moates' site has info on this, or do a search here
or on the TGO PROM board for instructions.

29x chips are flashable IIRC. Look up the 28x series on DigiKey
to see what you bought.

128 series chips are 8 X 16 = 16KBytes
256 series are 8 X 32 = 32KBytes

There is lots of introductory info on the TGO board.
http://www.thirdgen.org/techbb2/show...hreadid=305250

Good luck.
Old 09-11-2005, 11:46 AM
  #9  
gbody5
Pro
 
gbody5's Avatar
 
Member Since: Sep 2001
Location: Stuck in the 80's
Posts: 542
Likes: 0
Received 1 Like on 1 Post

Default

Just a note, one of the sweet things about the Moates BURN1 reader/programmer is it automatically sets the proper starting point on the memory chip when you select the chip type. No more having to figure out what size, hence where to start, or stack. I use his SF512's just because they are the cheapest, have never had a problem, plus the BURN1 uses your USB port for power so no AC adapter needed.

With a fully charged laptop battery (or two) I can scan and then do a burn right there in the car, for hours.

Get notified of new replies

To MEMCAL problems part II




Quick Reply: MEMCAL problems part II



All times are GMT -4. The time now is 07:15 AM.