When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
So there's a table in 8D, labeled the following in S_AUJP v7...
AE-MAP, AE-MAP PW Limiting Factor .vs. Coolant if AE-TPS Active
Location 0x563
So what's weird about this table is that when you modify it, sometimes the car starts having ridiculous hesitation and stumbling issues. Leaner or richer, doesn't matter. The engine almost shuts off for a 1/4-1/2 second or so during throttle transitions and then recovers. Doesn't throw any codes or anything.
Then other times it behaves normally.
Once I understood what it actually does with AE fueling, I really wanted to modify it, so I stayed at it until it took my changes and then I didn't touch it after that.
What I'm curious about is what's in the code that's associated with this table that could potentially be causing this kind of inconsistent and quirky behavior.
That table at 0x563 isn’t a normal AE adder. GM tied that table into a part of the AE routine that only runs when the TPS jumps but the MAP hasn’t caught up yet. When that happens, the limiter can chop the AE pulse width harder than you’d expect. That’s why the stumble only shows up sometimes... it depends on how fast the MAP responds during the throttle move.
The only thing is the inconsistent nature of how the ECM applies this...
I've had it where one of three scenarios plays out...
1.) Modifying the table even by the smallest amount causes the severe hesitation response immediately and all the time
2.) Modifying the table significantly doesn't elicit that kind of response, at least not immediately. After driving for about 10-15 minutes, all of a sudden it'll start into the severe hesitation, and when that starts it does that indefinitely.
3.) Modifying the table significantly never elicits that kind of response.
It's the randomness of the response that's baffling...
My current bin came out of scenario 3 and it's run normally for the last few weeks with never once a hesitation incident. But that's after having experienced scenario 1 and 2 numerous times before the ECM finally "accepted the change" and delivered scenario 3.
The other thing is S_AUJP v7 has a scalar that seems to be related to this table...
AE-TPS, For AE-MAP PW Limit Test if AE-TPS Active
Location: 0x52F
Description: This item appears to only be used by GM in testing to possibly limit AE-MAP PW if AE-TPS is active.
DO NOT CHANGE UNLESS YOU KNOW WHAT YOU ARE DOING!
Factory Default = 1
I've played around with this scalar a bit too... I seem to have better luck with this set to 0 (i.e., I can actually get to scenario 3), whereas before with it set to 1, I can never get there.
Not sure if any of this additional info helps in the diagnosis...
It actually isn't random, the ECM has two different AE paths, and it switches between them depending on how the TPS and the MAP deltas line up. The table at 0x563 only comes into play when the AE‑TPS is active and the MAP hasn’t caught up yet. When that happens, the ECM can clip AE‑TPS using that limiter, which is what causes the severe hesitation. The reason you feel like you are getting three different scenarios is because the conditions that trigger the limiter don’t always happen the same way. Sometimes the limiter kicks in immediately, and sometimes only after the engine warms up and the AE decay changes, and sometimes not at all. The scalar at 0x52F is basically the on/off switch for whether the limiter is even allowed to run. With it set to 1, the ECM can enter that limiter path, which is why you kept getting scenarios 1 and 2. Setting it to 0 prevents the limiter from activating, which is why it finally got to the 3rd scenario and the hesitation disappeared...
