Hello all
I had a Maf ECm and it ran dataloged etc just fine, I have modded the harness to run a 7730 and have it running etc, everything seems fine but I can't seem to get it to datalog. I can't get tuner pro rt to talk to the ECM I set up the software and have the cable recognized, have the switch on the cable set to the middle as per the moates site, just can't get the ecm to talk to the laptop.
ANY Suggestions? I have triple and quadruple checked the wiring and all wires are pinned out correctly, any tricks or things I may be missing, I had he exact same car and setup dataloging fine with the 165, but now am trying to tune out the 730 to get my car on the road.

You are all great and have been very helpful and "patient" with us newbs.

 

I just completed the same swap from a 165 to the 730 and have no problem connecting to the 730. If your sure you have the pins correct it should work. You say TP recognizes your cable so the preferences should be set correctly. The only other thing i can think of is the ADS file the correct one for the 730.

 

got the ads file from the tuner pro download site, will recheck for continuity on the data stream wire going to the aldl, maybe something got messed up when installing new ecu?
AlDl has same pin config correct?

 

"AlDl has same pin config correct?"
Yes,ALDL terminal A should go to pin D1 amd terminal B should go to pin E12.

 

Just took a look at the wiring diagram for an 86 corvette and it seems they use terminal E for the data stream. The 730 is looking for data on terminal M. If your wiring harness is out of something other than an f body try moving e to the m location and see if that works.

 

still fighting with this thing, ALDLis as follows and all are tested good to ecu
ALDL ECM
M A8
A Ground
B E12

Am I missing something>? I even tried a Matco Scan tool for ALDL and it doesn't connect to the ecm either? Very confused. 165 worked great, only ditched it as the MAf met an untimely demise and rather than shell out another $200 and have to find a better routing for it Ichose to go to the 7730. Have all the hardware to do either, have a hot cam, head work etc this will be enough fun to get running right as it is. It runs currently, but can't get a datalog, and under any load pops and craps out and just kinda runs. idles lumpy but well.
Just need my dataloging to work otherwise I may have to go back to the MAF setup, really easy, just frustrating. As I know all the wires are correct and are connected to the ECm.
Could the ECm be faulty? what actually is talking to the datastream? is it something off of the chip?, or off of theboard itself? Maybe I got a bum Used 7730 ECU? I mean it runs, but I can't get a datalog or a servie engine light stuff to work correctly...
Any help is appreciated.

 

Well maybe its time to look for another ecm. Here in southeast pa we can get used ecms for ten bucks no warrenty or fifteen with a 30 day exchange warrenty. See if you can borrow a buddies ecm for testing.

 

What memcal are you using?
That could be part of your problem. 730 should connect right up with no problem. The wiring is right from what you've listed.
What is the problem with the SES? On solid? Blinks?

 

Memcal is a 7730 AXXC memcal new from Tpi Parts
SES is on solid, daig/grd shorted stays lit solid.

Have tried AXXC and AXXD bins with stock settings other than the inj constants and the spark base changed to my setup.
If I can get another ECM I will, generally picked through here, but I will call around and check the Ebay etc... I bought this as a "garaunteed" good unit from an internet vendor. You never know though.
I'll look into that, and also into the
808 165 MAP setup. We'll see, depending on what fruits develop here, I may ditch the 7730 stuff? I liked the 165 I just had two issues, car probably outflows the MAF and I have no room to safely run the MAF under the hood.
7730 was mostly a function of getting rid of the MAF plumbing and eliminating the MAF restriction in the intake tract. Any info helps,
I will supply pics, info or anything needed to help me get this working though.

 

If your burning chips to test with are you using the correct offset on the chip? Are your modifications to the memcal done properly? Are you inserting the chip in the zif correctly. Like JP86SS said all those things could cause the computer to run in limp mode preventing you from datalogging.

 

Can you datlog with just the memcal on the ECM?
(Without any adapters etc)
That will narrow it down.

If you are reprogramming the chip in the memcal, it will be more difficult to nail down the problem.
Put $AA in the id byte to be sure the checksum is not causing it.
Unless you are using a 29C256, recheck the starting address you are using for the burns.
BTW, I still put chips in backwards if I don't mark an arrow location of the chip in the adapter and a dot on the ECM.

 

I am using all the moates stuff, 27sf512
flash n burn from moates which does the offset automatically (well at least it did for the MAF bins)
notch on chip faces away from the ZIF lever.
When you say ID Byte what in the software would that be, the Prom ID?
I have ye little faith in the genuine ness of the base Bin I have
Prom ID 3071
Checksum 63000
CodeMask 8D

Using TunerproRT
AxxD Bin
8D xdf
Going to try and crack the fuel pressure down low enough to try and get it to run with the stock memcal, then I will report back....

 

motor wayyyyyy too far off to run long enough to test the stock memcal

theory ?? though with a huge cam on a 305 your idle is say 8-11invacuum
so in theory part of me VE table will be useless? So I should tune the VE initially ignoringthe unused portions of the tables?
Also is aq fueling problem, too ich at idle, minute you crack the throttle the af gauge drops to no bars. Very bad
anyone have a sample ACel enrich table so I can compare to my base?

 

so shorted diag and grd and it did the proper dealio where the timing reverts to base etc, problem won't run long enough on that to verify my base timing, at idle
1000rpm
12 inches of vacuum
full temp,
is running at about 30deg total
so based off my spark tables I would say teh base is around 14deg.
I need to get that squared so I have a solid base o work from.
But in the mean time the lean drop anytime the paedal is blipped is my concern,
really wish I could figure out the datalogging, is there a way to test the serial data line? I will post my base bin and pics of my chip install and see if anyone can help, have to go to work will finish this tonight.
Thanks everyone

 

Did the stock memcal make the SES on constant?
May not run well with it but it will inform you that your chip is the problem and not the ECM.

Disable the checksum to see if that is the problem.
At location "08" where the 8D is shown. Make that AA to disable the checksum.
That will allow the code to run and not throw a "Bad Prom" code 51.

For the 32K bin on a 27SF512 the settings should be:
buffer = 000000 -> 007FFFF
chip = 008000 -> 00FFFFF
Triple check on Moates site for the correct orientation of the chip in the adapter you have. (placement and notch direction are two different things)
Try again

 

For now that is true.
Those cells will be used when decellerating or coasting. You won't have to be as concerned with them yet. This will also limit the amount of BLM cells you will be using for corrections but once it is running halfway good you can adjust the cell boundaries to make them available in the range that your motor operates in.
Be sure your TPS and IAC are properly adjusted at this point or you'll be chasing your tail.

 

thank you for all the help, I will try again in the morning to run it off the memcal long enough to check the ses.
On the adapter ZIF socket you can only put it in one way or the other so as long as the notch is on the right side your good. Burning it on the programmer is aq different story. I will triple and quadruple check the moates site and make sure I didn't goof somewhere. I might have I put my project on hold for at least 4 months as I had to move so all my tools and car were in storage, just started working on my projects again last week or so.

 

Bin I was trying to start with.

 

OK so I am positive that I have the chip oriented correctly both in the burner and in the adapter.
Rules that out, I have 6 chips and have burned bins on many of them and they all act the same so it can't be a bad chip,
Still working at it....we will figure this out at some point..

 

so car not running I can search out codes etc with the stock memcal
adapter and burnt chip in place no such luck,
what would cause this? any ideas? do I have a bogus Bin file, improper entry etc?
Maybe someone could send me a known good bin? 7730 5spd ?
I am going to try thechecksum dealio right now.
Thanks again for all of your help.
----------
checked the offset and are exactly as you stated, except in flash and burn there are only 6 digits it drops the last digit off of what you posted still sound right?
007FFF

 

low down is handheld talks to stock memcal
however if I jumper diag and grd with the adapter and chip in place I do get the flashing deal and it spits out codes 51 and 46 but will still not talk to the handheld, so I assume that the issue is limited to the serial data stream and further limited to only the adapter chip combo, stock memcal seems to work as per design.
anyone have any ideas? I checked offsets, orientations everything, chips and adapters worked on 165, should I try another adapter to rule that out?
Could it be the bin I am using?
Kinda helpless and stuck right now, any ideas greatly appreciated.

 

Left extra 0 doesn't matter. That's just the way it was listed on Craig's site.
The bin you posted is a stock AXXC with the inj constant changed.
Error 46 is the VATS error code. Disabling it is good the way you did it but the error code should be turned off too. 824B, bit 1 (not set) will cure that.

It should communicate although the code 51 indicates it will not because of a bad prom. I don't see how the bin you posted would be bad so...
Must be something with the adapter not seated or something like that mechanically.
Just to recheck the basics, you do have the memcal on the adapter as well as the new chip?
Memcal placed with the "old" chip end off the end of the adapter?
Check for a bent pin or other issues like that while your in there.

Wait!
That's not the memcal from the 165 is it???

 

definitely not the 165 memcal.
It is a memcal with AXXC on the chip bought new.
I will check the ecm and adapter for pin issues and continuity.
Maybe that will narrow it down. would the code 51 pop from the code mask being changed to AA instead of 8D as you suggested? I really don't get what that does as far as the function of it all. I do have the memcal on the adapter correctly. The limp home mode etc "gummy" :-) side is connected to the ECM through the adapter and the old "chip" hangs off. I wil check continuity through the adapter and make sure it does not have some type of bad solder point or something? I am soooo thankful that you have been helping me,
I have a vast knowledge of cars, engine and whatnot but this is my first time ever tuning with software, Excuse my ignorance on some of the items.
I will check the continuity etc and post, I know the ECM is good as it only pops 46 when the stock memcal is in place.
Does the 51 code mean it is running on limp home? What exactly is Limp home mode do in that case? as it seems to run decent when it starts on the burned chip. ??

 

No, the code 51 means the program is FUBAR and will not attempt to run it.
Usually a 51 indicates the checksum of the program doesn't = what it should indicating something wasn't read right or was a just a bad/faulty burn.
Changing the $8D to $AA will ONLY bypass the checksum confirmation, thus not allowing the code 51. Its not the right way to solve it but it proves the problem was in the chip/burn (software side of things)
The bytes of the program are all added together and should match the programmed value at L806 & L8007. That confirms the program is "intact"
As an informative note, When doing "on-the-fly" emulating it is necessary to keep the checksum disabled so a change in the bin doesn't throw the error.
Because obviously when making a change the total value will not equal the starting point. You don't need to worry about keeping it disabled because you want to confirm the bin is good when buring single chips.
Yep, as a simple explaination,
The fuel and spark are "hardware" driven for the most part by resistor settings in the memcal itself. The motor will run somewhat but it is operating under presets, not the program parameters on your bin. The closer your engine is to stock, the better it will be.
Mine floods immediatly and usually fouls the plugs due to larger injectors installed. someday going to haveto figure out what resistor needs changed to make that better.

 

Definitely look for a bent pin (or one outside of the socket) on your chip or something not right with either the adapter board's connector to the ECM or where the memcal plugs onto the adapter board. John mentioned this earlier, but I don't see where you checked that. I've done that before and gotten similiar results to what you're seeing.....

 

you guys are awesome I get the checksum now and what the meaning was to do that. I am the type that if I don't understand "why" i am doing something I can't understand it altogether.
I am resistance chacking the adapter tonight and already verified all pins are not bent and everything is mechanically ok. Maybe the zif socket or somthing
is bunk, am checking now.
Thanks again I will post results.

 

I saw this in another post and thought you could benefit from the knowledge as well since you're having PROM issues.

 

great thanks, I will keep that in mind,
so I have a ???
All the bins I have have three fuel tables, the low end the normal upper and the extended upper.
0-1600
1600-5600
1600-6400
is there a reason to have all three? could this be the problem as it has double up values for 1600-5600? anyone have knowledge on these and if they are menat to be there?

 

this makes more sense than I do I think

 

They are not all necessarily in the bin but are shown in your definition file.
The third table isn't used with the stock bin. Should be noted somewhere in there. The higher range upper table can only be used with either a "patched" bin or the S_AUJP bin.
You will only need the two for the stock bin.

 

think I found the problem but don't know how to fix it?
I ambeing **** about burning the chips now, but every time I try and verify a bin against the verified blank chip I get the failure notification?
Any ideas?? Bin is 32K nothing special or different about it, in fact I tried unmodified bins and several chips and get the same thing.
NEED HELP, GETTING FRUSTRATED>

 

Just checked my Flash'n'Burn settings for ya, and they do NOT match yours!

For the 512 chip, my addresses are 00000 and 00FFFF for bothe the addressing and the buffering (yours differ). Try these settings and see how it works.

FYI - for the 256 chip both sets of addresses are set to 000000 and 007FFF. Your addresses look to be a combination of the two.....

Hope this helps!

 

I did'nt notice I typed the extra "F" in there. You even asked about it and my brain flipped right over it. Sorry bout that.
These are the buffer and chip setting from Craig's site but try what Vern has, his was working. I'm still using the 29C256's and don't have any 512's yet.
I'm confused, The 512 is a larger chip and there should be some offset so that the bin is at the end of the chip.

Anyway, try them both, see if it works.
Maybe you got lucky and scored one of the last 256 chips.
I hope that solves problem one way or another.

Edit: for the 512 chips you MUST do the erase before reprogramming.

 

I'm still using the 29c256 as well. Well, I would be I guess since those are all I have. Except I've been running exclusively on the Ostrich for a year or so now...

 

Super frustrated But oh well I'll figure this out sooner or later.
SOOOOOO
The verify chip/buffer dealio says failure no matter what I do!
But when I burn chips, it says a success and I read the chip back into the buffer and it seems to be exactly the same so would that not mean that it should be ok? Not sure why the verify chip/buffer returns a failure every time. Tried all the different ofsets etc. No luck.
So If I burn this chip and still get a code 51 where do I go next? I just want this to work.
Another interesting thing, even though I was getting a code 51 it had to be running on the chip as my injectors are 26lb/hr and I don't think failsafe would idle the way it does, however if I can't datalog or read the ECM then it really ain't worth much.I'll keep persisting,
If all else fails there is always the Aussie code for the 165???? he has any ideas/
I'll email Craig and see if

 

i did a tpi swap from a 91 Firebird to a 91 Caprice. Used ecm out of the Firebird. 7730 ecm repinned as per another thread in here. I have everything working except I can’t get a scanner to communicate. So reading this I investigated wires at the aldl. Orange at terminal E and a tan at M. So if I move e to m what do I do with tan from m??