Getting the ECU to quickly learn idle stability after a reflash

[Compelica]

Figured that it would be applicable to post this here in the Software Tuning section as we deal with these issues more often.

After a reflash the ECU takes some time to relearn fuel trims, and those trims learn completely after a consistent amount of driving. But idle stability was one thing I could never predict - it would take a varied amount of time to get the idle to stop hunting with the AC on, and the RPMs would do engine shuddering dips after rising upon a slight tap on the throttle.

So I came across this Toyota specific PID called 'Deposit Loss Flow'. As a background - the throttle body has carbon deposits caked onto the walls or onto the butterfly valve which impedes air flow. As a result, the TB must compensate with a larger opening to maintain the target idle speed. It is solely my guess here but the throttle body can easily adapt its opening during extended idle but it has to learn this position on where to 'settle' during rapid movements of the throttle.

Upon a reflash, this PID value would always be 0 grams per sec, indicating there is no compensation (subsequently opening of TB) done. 500 kilometers of driving and it still showed 0. Which then I found this particular bit in another Toyota service manual:



And it works. Followed the procedure to the dot, and right after the last step after starting the engine the learned values finally came up and my idle smoothened out. I'm happy once again

Also, be sure to do this procedure without the AC on. Also you would want the idle to be as stable as possible during the warm up period so turning off lights and head unit may probably help. Hope this works for you guys trying to fix your idle

[FR-S2GT86]

Originally Posted by Compelica

Figured that it would be applicable to post this here in the Software Tuning section as we deal with these issues more often.

After a reflash the ECU takes some time to relearn fuel trims, and those trims learn completely after a consistent amount of driving. But idle stability was one thing I could never predict - it would take a varied amount of time to get the idle to stop hunting with the AC on, and the RPMs would do engine shuddering dips after rising upon a slight tap on the throttle.

So I came across this extended OBD2 PID called 'Deposit Loss Flow'. As a background - the throttle body has carbon deposits caked onto the walls or onto the butterfly valve which impedes air flow. As a result, the TB must compensate with a larger opening to maintain the target idle speed. It is solely my guess here but the throttle body can easily adapt its opening during extended idle but it has to learn this position on where to 'settle' during rapid movements of the throttle.

Upon a reflash, this PID value would always be 0 grams per sec, indicating there is no compensation (subsequently opening of TB) done. 500 kilometers of driving and it still showed 0. Which then I found this particular bit in another Toyota service manual:



And it works. Followed the procedure to the dot, and right after the last step after starting the engine the learned values finally came up and my idle smoothened out. I'm happy once again

Also, be sure to do this procedure without the AC on. Also you would want the idle to be as stable as possible during the warm up period so turning off lights and head unit may probably help. Hope this works for you guys trying to fix your idle

Interesting, so this procedure is like a band aid if you have a dirty throttle valve.

If you have to go through this procedure, and it actually works, you now know your throttle valve is probably dirty, wouldn't it be a good idea at this point to just disassemble and clean the throttle body and valve, then reset the ECU?

[Compelica]

Originally Posted by FR-S2GT86

Interesting, so this procedure is like a band aid if you have a dirty throttle valve.

If you have to go through this procedure, and it actually works, you now know your throttle valve is probably dirty, wouldn't it be a good idea at this point to just disassemble and clean the throttle body and valve, then reset the ECU?

Good observation - I was thinking of this as well, so I pulled out the intake tubing and inspected TB before doing the procedure. It was reporting around 2.3gram/sec loss the last time, and I wanted to see if cleaning the TB would further reduce the flow loss.

However my TB was basically spotless apart from the dye markings and a very light layer of dust, though I suppose there would always be some form of compensation made out for differences/variations.

There probably isn't any perceptible performance loss either - given that at around WOT the engine is taking in 143g/s, a 2.3g/s loss is slightly less than 2% which is negligible when calculated by the ECU as a load.

[FR-S2GT86]

Originally Posted by Compelica

Good observation - I was thinking of this as well, so I pulled out the intake tubing and inspected TB before doing the procedure. It was reporting around 2.3gram/sec loss the last time, and I wanted to see if cleaning the TB would further reduce the flow loss.

However my TB was basically spotless apart from the dye markings and a very light layer of dust, though I suppose there would always be some form of compensation made out for differences/variations.

There probably isn't any perceptible performance loss either - given that at around WOT the engine is taking in 143g/s, a 2.3g/s loss is slightly less than 2% which is negligible when calculated by the ECU as a load.

So what was your g/s loss that the PID was finally reporting as after you cleaned the TB and then after you performed the re-learn once again?

[Compelica]

Originally Posted by FR-S2GT86

So what was your g/s loss that the PID was finally reporting as after you cleaned the TB and then after you performed the re-learn once again?

Left it alone as there was nothing to clean

Was surprised myself as I was coming to about 100k KM and I expected some dirt there but clean as a whistle.

[tomm.brz]

something tells me it's some closed loop calculation similar to the various LTFT it learns
Like, maybe it's something calibrated against the original maf scaling, and that % calculation is probably just added up after a while to try correct some wild fuel trim that the ecu wants not to see
I don't think the ecu really knows how much debrees is present in the wall of the throttle body.

Whatever it is we haven't control of it in romraider or ecutek, so it's definitly something annoying in custom tuning

[callisto]

I've been reading the code for P1109 THROTTLE DEPOSIT MALFUNCTION and I think I know how to disable this now. (I don't endorse doing so, but I set out to learn how, all the same!)


https://gt86stuff.onrender.com/t3Por...00000XFH2.html

P1109 is logged when the learned value exceeds some threshold, so I've been tracing P1109 back and I think there's a single float that can be altered in K00G to disable learning. It runs a series of checks that are logged as a boolean T/F at FFF8C2F1; if true, then learning is permitted; if false, then learning is not permitted. Among the variety of things that need to be true, the engine speed needs to be at least 30.0, and the ECT needs to be less than 98.0. That float is stored in this block of three floats used in the limits-check function:

00124924 - 41 f0 00 00 - float: 30.0
00124928 - 42 c4 00 00 - float: 98.0
0012492c - 44 21 dd 50 - float: 647.458

So, adding a Romraider def for 124928 float and/or just hex editing it to c3 48 00 00 - float: -200.0 and resetting your ECU should unlearn everything and prevent anything new from being learned; logging on FFF8C2F1 would then switch from "Sometimes true, sometimes false" to "always false", and so learning should stop.

I'm still working through where the learnings are stored, but I believe it's somewhere in these two-byte shorts at FFF8C2EC, C2EE, and C2F2; those should have something non-zero right now, and should be zeroed out and remained zeroed once the patch above is in place.

I haven't tried this since my vehicle is busy with U01A fuel trim learning for the next while, but the memory addresses above are valid for K00G / OFT / Wayne, and I provided the third value for verification that you're in the right place (it's not used anywhere else in the entire ECU, in any version). Hope this helps!

EDIT: For curiosity's sake, it's taking the IAT and looking it up in a previously-undocumented table of "correction in degrees" percentages (below), then applying that result as a MAF correction, then testing some RAM values that I don't recognize yet (FFF8BBBC and FFF8179C) to see if their sum is greater than either 0.37 times, or 0.52 times, that correction; if so, then the short at C4D0, or C4D2, is incremented - unless learning is disabled above. (The table lookup result is always logged at C4CC as a float, whether or not learning is enabled.)

K00G - 00128fec float[9]: -40, -20, 0, 20, 25, 40, 60, 80, 100; 00129010 word[9]: 6400h, 6CA8h, 7552h, 7DDCh, 8000h, 8674h, 8F04h, 97A8h, A033h; multiply by 3.0518044E-5

[Compelica]

Originally Posted by callisto

I've been reading the code for P1109 THROTTLE DEPOSIT MALFUNCTION and I think I know how to disable this now. (I don't endorse doing so, but I set out to learn how, all the same!)


https://gt86stuff.onrender.com/t3Por...00000XFH2.html

P1109 is logged when the learned value exceeds some threshold, so I've been tracing P1109 back and I think there's a single float that can be altered in K00G to disable learning. It runs a series of checks that are logged as a boolean T/F at FFF8C2F1; if true, then learning is permitted; if false, then learning is not permitted. Among the variety of things that need to be true, the engine speed needs to be at least 30.0, and the ECT needs to be less than 98.0. That float is stored in this block of three floats used in the limits-check function:

00124924 - 41 f0 00 00 - float: 30.0
00124928 - 42 c4 00 00 - float: 98.0
0012492c - 44 21 dd 50 - float: 647.458

So, adding a Romraider def for 124928 float and/or just hex editing it to c3 48 00 00 - float: -200.0 and resetting your ECU should unlearn everything and prevent anything new from being learned; logging on FFF8C2F1 would then switch from "Sometimes true, sometimes false" to "always false", and so learning should stop.

I'm still working through where the learnings are stored, but I believe it's somewhere in these two-byte shorts at FFF8C2EC, C2EE, and C2F2; those should have something non-zero right now, and should be zeroed out and remained zeroed once the patch above is in place.

I haven't tried this since my vehicle is busy with U01A fuel trim learning for the next while, but the memory addresses above are valid for K00G / OFT / Wayne, and I provided the third value for verification that you're in the right place (it's not used anywhere else in the entire ECU, in any version). Hope this helps!

EDIT: For curiosity's sake, it's taking the IAT and looking it up in a previously-undocumented table of "correction in degrees" percentages (below), then applying that result as a MAF correction, then testing some RAM values that I don't recognize yet (FFF8BBBC and FFF8179C) to see if their sum is greater than either 0.37 times, or 0.52 times, that correction; if so, then the short at C4D0, or C4D2, is incremented - unless learning is disabled above. (The table lookup result is always logged at C4CC as a float, whether or not learning is enabled.)

K00G - 00128fec float[9]: -40, -20, 0, 20, 25, 40, 60, 80, 100; 00129010 word[9]: 6400h, 6CA8h, 7552h, 7DDCh, 8000h, 8674h, 8F04h, 97A8h, A033h; multiply by 3.0518044E-5

Would love to have that memory address for the learned value for A01G, unfortunately still don't have enough time to pick up Ghidra

[callisto]

Originally Posted by Compelica

Would love to have that memory address for the learned value for A01G, unfortunately still don't have enough time to pick up Ghidra

Sure, it only took a few minutes; the function is unchanged from A01G to K00G. Let me know if you get any useful results?

It runs a series of checks that are logged as a boolean T/F at FFF8C2F1; if true, then learning is permitted; if false, then learning is not permitted.

In A01G, this boolean is at FFF8BE75.
In U01A, this boolean is at FFF8BE91.

Among the variety of things that need to be true, the engine speed needs to be at least 30.0, and the ECT needs to be less than 98.0. That float is stored in this block of three floats used in the limits-check function:

00124924 - 41 f0 00 00 - float: 30.0
00124928 - 42 c4 00 00 - float: 98.0
0012492c - 44 21 dd 50 - float: 647.458

In A01G, these three values are (unchanged) at 0012072c, 00120730, 00120734.
In U01A, these three values are at 0012585c, 00125860, 00125864.

I'm still working through where the learnings are stored, but I believe it's somewhere in these two-byte shorts at FFF8C2EC, C2EE, and C2F2; those should have something non-zero right now, and should be zeroed out and remained zeroed once the patch above is in place.

In A10G, these are FFF8BE70, BE72, and BE76.
In U01A, these are FFF8BE8C, BE8E, and BE92.

EDIT: For curiosity's sake, it's taking the IAT and looking it up in a previously-undocumented table of "correction in degrees" percentages (below), then applying that result as a MAF correction, then testing some RAM values that I don't recognize yet (FFF8BBBC and FFF8179C)

In A10G, FFF8B70C and 1368.
In U01A, FFF8B6E8 and 11B0.

to see if their sum is greater than either 0.37 times, or 0.52 times, that correction; if so, then the short at C4D0, or C4D2, is incremented - unless learning is disabled above. (The table lookup result is always logged at C4CC as a float, whether or not learning is enabled.)

In A10G, (short) BE70, BE72, and (float) BE6C.
In U01A, (short) BE8C, BE8E, and (float) BE92.

K00G - 00128fec float[9]: -40, -20, 0, 20, 25, 40, 60, 80, 100; 00129010 word[9]: 6400h, 6CA8h, 7552h, 7DDCh, 8000h, 8674h, 8F04h, 97A8h, A033h; multiply by 3.0518044E-5

In A10G, 00120758 float[9], 0012077c word[9], same values.
In U01A, 00125888 float[9], 001258ac word[9], same values.

[Compelica]

Originally Posted by callisto

Sure, it only took a few minutes; the function is unchanged from A01G to K00G. Let me know if you get any useful results?

Will do, however I won't have the car for some time; I'll get back once I can get around testing - my concern is knowing when the ECU has some learned value which I can cross-check with the Mode 21 PIDs (probably FFF8BE70, BE72, and BE76 as you had mentioned).

[Compelica]

Originally Posted by callisto

Sure, it only took a few minutes; the function is unchanged from A01G to K00G. Let me know if you get any useful results?

In A01G, this boolean is at FFF8BE75.
In U01A, this boolean is at FFF8BE91.

In A01G, these three values are (unchanged) at 0012072c, 00120730, 00120734.
In U01A, these three values are at 0012585c, 00125860, 00125864.

In A10G, these are FFF8BE70, BE72, and BE76.
In U01A, these are FFF8BE8C, BE8E, and BE92.

In A10G, FFF8B70C and 1368.
In U01A, FFF8B6E8 and 11B0.

In A10G, (short) BE70, BE72, and (float) BE6C.
In U01A, (short) BE8C, BE8E, and (float) BE92.

In A10G, 00120758 float[9], 0012077c word[9], same values.
In U01A, 00125888 float[9], 001258ac word[9], same values.

Coming back to this after so long.

in A01G, queried FFF8BE70, BE72, and BE76 in floats, should be 16bit INT. Will try this later, as I also missed out BE6C.

B70C is ISC Learning Value, where ISC stands for Idle Speed Control. Not really sure what it does, I recall (but could be wrong) that this value is zero upon a battery pull, but quickly has a value after a drive.

1368 is Deposit Loss Flow, as per the PID aforementioned in the opening post.