1990 Throttle hesistation

[scottfab]

Originally Posted by Franke

...snip...
I have to say I had exactly the same LT condition that Schrade has in DM and when I replaced that bad injector it was gone. I watched as the BLM and fuel cell changes were better and so I figured that the bad injector was causing the ECM indigestion. Am I wrong on this?

Same here but there were two bad injectors on the same side.
Problem went away with new injectors but not before it toasted the CAT with all that raw fuel. Even with that I almost passed DEQ testing. After the new CAT passed easily.

[Schrade]

Originally Posted by XfireZ51

Based on what Marc has said, there's nothing to see here, move along.

Not quite here Dominic; he said if I WAS able to fix it, I'd be fixing all 7,000 LT5's.

So there IS a fix.

Problem is, most owners are concerned with 'hammer-down' tune / top end power, and less so with the 'perfect' tune.

That's one reason I've always preached against modifications, at LEAST without baseline specs measured in to START with...

Originally Posted by scottfab

Exactly right. It'd be hard enough diagnosing a stock set-up without that data but a modified one? Oh boy.

We need to see ECM's 'operating system'. I've done SOME coding - batch commands, VBS, in Windows environments; even with second and third order dependencies. But without basic operational sequencing...

And this control hand-off - is it a parallel function? Series function? Or compound function even??? I'm tearin' my hair out on this here!!!

[scottfab]

Originally Posted by Schrade

....snip...

We need to see ECM's 'operating system'. I've done SOME coding - batch commands, VBS, in Windows environments; even with second and third order dependencies. But without basic operational sequencing...

And this control hand-off - is it a parallel function? Series function? Or compound function even??? I'm tearin' my hair out on this here!!!

I don't know that it's ever been posted. (OS listing) I did some development work back in the late 80s using the same CPU as is used on the ECM. It's a motorola varient of the 68HC11. The development setup from Motorola for the 68HC11 came with an OS known as "Buffalo".
The idea was to add your own code to the outside of the OS. I remember it was "message based". Any task that was ready to run then ran and posted "messages" to the OS and/or other tasks.

In the instance of our ZR-1 ECM the only thing the "chip" is used for is for data tables. No executable code resides in it. The executable code is flashed to an eprom internal to the CPU.

Boy, if we could get hold of the internal code listing. It may be possible to optimize it. The internals can be erased and reprogrammed. Seems to me there was a power up mode where a few key pins are looked at as to where to boot from. And an external setting combo of those pins would turn over the first address read to be external. From there one could put some op codes together to read the internal code and push it out the serial line. hmmmm
I could work myself up into a froth of curiosity here. Thing I don't know is if those pins exist and are functional on the actual ZR-1 ECM CPU. It would make sense for them to be deleted or rendered in effective to prevent reverse engineering.

Anyone know anything or someone that may know something?
This needs it's own thread.

[tpepmeie]

Originally Posted by scottfab

In the instance of our ZR-1 ECM the only thing the "chip" is used for is for data tables. No executable code resides in it. The executable code is flashed to an eprom internal to the CPU.

That's actually not quite true. The EPROM "chip" contains both the operating instructions/program code as well as the lookup tables. Out of a 32kb EPROM memory, only a small portion of that is the data tables.

It is all able to be extracted and disassembled like any other 68HC11. Knowing what to do with it from that point is a whole different thing. There is the rare occasion to modify the program code. (default to full power mode on MY91+ for example).

I'm not a computer guy, so maybe I didn't get what you were trying to say.

[XfireZ51]

People hack GM ECMs frequently. Some replace code with their own for functionality they are interested in. JEP has disassembled the code from a 91.
The LT-5 code is based on the L-98 $8D Mask ID which is why the 90 Mask ID is an $8E. It explains why we have secondary injector relays and an Ignition Module that acts as a co-ECM controlling the dwell and overall ignition other than timing.
You can go to tunerpro.net and get the bin editor, download a definition file for the LT-5 along w a stock bin file and have a look. Just make sure the mask and bin file match up and are for the same model year.

Todd, you were also someone I was thinking of when writing the above. I agree that there is little need to modify the code if your dealing w basic modifications. Forced induction and things like NOS control is a different story.

[tpepmeie]

Originally Posted by XfireZ51

Todd, you were also someone I was thinking of when writing the above. I agree that there is little need to modify the code if your dealing w basic modifications. Forced induction and things like NOS control is a different story.

Basic works fine for >700 bhp normally aspirated. Seriously, though if you're looking for NOS control through the ECM, or boost, or traction control, or out of the ordinary things... just get an aftermarket controller. Patching 25-year old assembly code for a very limited application (read-not 4th gen F-body, or Turbo Buicks) is just not worth it.

All IMHO.

[XfireZ51]

Originally Posted by tpepmeie

Basic works fine for >700 bhp normally aspirated. Seriously, though if you're looking for NOS control through the ECM, or boost, or traction control, or out of the ordinary things... just get an aftermarket controller. Patching 25-year old assembly code for a very limited application (read-not 4th gen F-body, or Turbo Buicks) is just not worth it.

All IMHO.

Yep.

[Schrade]

Originally Posted by tpepmeie

Basic works fine for >700 bhp normally aspirated. Seriously, though if you're looking for NOS control through the ECM, or boost, or traction control, or out of the ordinary things... just get an aftermarket controller. Patching 25-year old assembly code for a very limited application (read-not 4th gen F-body, or Turbo Buicks) is just not worth it.

All IMHO.

Do you really think it's not worth it?

Aren't we hoping to see this YZ Series cars' value approach original sticker prices??? I would surely think that that WOULD make it worth it...

Would a hexadecimal editor allow reading of code? Never used one, but I'm marginally familiar with them. And for the car, I will GET familiar.

Originally Posted by scottfab

I don't know that it's ever been posted. (OS listing) I did some development work back in the late 80s using the same CPU as is used on the ECM. It's a motorola varient of the 68HC11. The development setup from Motorola for the 68HC11 came with an OS known as "Buffalo".

Looks like a BIOS version...

The idea was to add your own code to the outside of the OS. I remember it was "message based". Any task that was ready to run then ran and posted "messages" to the OS and/or other tasks.

In the instance of our ZR-1 ECM the only thing the "chip" is used for is for data tables. No executable code resides in it. The executable code is flashed to an eprom internal to the CPU.

Boy, if we could get hold of the internal code listing. It may be possible to optimize it. The internals can be erased and reprogrammed. Seems to me there was a power up mode where a few key pins are looked at as to where to boot from. And an external setting combo of those pins would turn over the first address read to be external. From there one could put some op codes together to read the internal code and push it out the serial line. hmmmm
I could work myself up into a froth of curiosity here. Thing I don't know is if those pins exist and are functional on the actual ZR-1 ECM CPU. It would make sense for them to be deleted or rendered in effective to prevent reverse engineering.

Anyone know anything or someone that may know something?
This needs it's own thread.

YES IT DOES NEED ITS' OWN THREAD.

I think there are a few here who do know it already, who won't post up since it will hamper their revenue source, or it will be an intellectual property issue (but as a TARP bailout funder - i. e.; taxpayer, I'm PART OWNER!!!).

[scottfab]

Originally Posted by tpepmeie

That's actually not quite true. The EPROM "chip" contains both the operating instructions/program code as well as the lookup tables. Out of a 32kb EPROM memory, only a small portion of that is the data tables.

...snip.....

Well obviously I've been misinformed by a fairly knowledgeable tuner. But then it's all based on threads I remember form the 90s. Thing is I may have been straitened out on this before but forgot AGAIN.

Having OS (not just bios) code available creates an opportunity to not only fully comment out the code but to share openly a control flow diagram.
As for "worth it" or not to make changes? That is in the mind of the doer. As hobbies go, "worth it" has a back seat to interest.
If GM wants to claim "proprietary" on the code. Let them.
I seriously doubt that would happen.
Yes, needs separate thread
Or dust off an old one.

[Schrade]

Alright - I just did another recording, from cold start Open Loop.

It DIDN'T lope between 1.6% TO, and 2.4% TO, as it usually does!!!

Rock steady idle, up to 1.6% TO, turning the throttle stop screw with the 8mm wrench, and it went from 1.6% - to 2.4% TO, withOUT a lope. RPM's bumped up quickly, and backing off with the screw, still couldn't get anything in between, but no big deal.

(it will not register any TO percentage between 1.6 - 2.4 under any circumstances, even tho' TPS voltage goes up smoothly - I don't think that's any issue)

Just then, it went CL, and as usual, it loped from 1.6 - 2.4 TO.

SOME parameter introduced in CL is causing the irregularity from 1.6% TO, to 2.4% TO.


ed.:
Yes - I'm aware that Open Loop readings don't mean much. All the other recordings are in CL. But something need a little closer scrutiny here...