Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB

Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB (https://www.ft86club.com/forums/index.php)
-   Software Tuning (https://www.ft86club.com/forums/forumdisplay.php?f=88)
-   -   Which DTC do you turn off to remove the rear o2 without limp mode (https://www.ft86club.com/forums/showthread.php?t=81925)

mad_sb 02-11-2015 03:00 PM

Alright, I think I know what is going on here. On my E85 rom, I have had the long term fuel trims disabled for a long while now (by setting the closed loop target addative table to zero). I believe this is the reason I have not seen the "limp mode" rich fueling before.

Everything I have read on romraider indicates that the ecu only really cares about the sensor signal to the ecu, and if that is missing or out of range, it will go into limp mode with the rich closed loop targets. 02 can be unplugged, so long as the heater dtc's are turned off and you are feeding a narrow band signal to the ecu in place of the secondary 02 signal.

What I don't understand though, is why zeroing the AF3 tables does not remove the rich target as it normally does on the other subaru ecu's that have this limp mode issue.

I think the only real "fix" for removing the rear 02 on this platform is to feed a narrow band signal to the ecu.

dave- 02-16-2015 12:28 AM

So can we successfully disable the secondary O2 and replace it with an aftermarket wideband for external logging? Or is it better to just have another bung welded in on the factory header or front pipe (not sure where the LC-1 will fit) and avoid having to muck around with disabling codes and zeroing tables (I can't see one the one ztan mentioned either on A01G RR defs).

I just want to be able to have wideband AFR logging on the laptop for street tuning.

mad_sb 02-16-2015 08:32 PM

Quote:

Originally Posted by dave- (Post 2133813)
So can we successfully disable the secondary O2 and replace it with an aftermarket wideband for external logging? Or is it better to just have another bung welded in on the factory header or front pipe (not sure where the LC-1 will fit) and avoid having to muck around with disabling codes and zeroing tables (I can't see one the one ztan mentioned either on A01G RR defs).

I just want to be able to have wideband AFR logging on the laptop for street tuning.

If you plan on removing the rear 02 to install a wideband in it's place, you will need to run the widebands narrow band emulation signal to the ecu rear o2 signal input. Otherwise you will get limp mode (rich closed loop afr target of about 13.7 rather than 14.7). I have tried every combination of dtc's, AFR 3 settings etc and none of them make any difference when the rear 02 is out of the pipe, plugged in or not. The only thing that does stop the rich target is dissabling long term trims completely by zeroing the closed loop load compensation map. That will eliminate the rich target and you will target 14.7 all the time in closed loop.


===================================

As my final test, I put the rear 02 back in the pipe with no other changes, my rich closed loop target went away, the previous config was with the sensor plugged in but not in the pipe. This matches all the info on romraider about the newer 32bit ecu's.

What does not match, is that zeroing all 3 (or any combination of) of the AF3 maps has zero effect on the rich target when the rear 02 is either unplugged or in free air and the long term trims are enabled (closed loop target comp table is non zero). At least for my ZA1JA00C ecu. Mine is one of the freaks that likes to reset IAM to the rom's default if it sits for more than a couple of hours.

For What it's worth, mine never obeyed the AF learning limits regardless of how they were set when i tested them a long while ago. That is true for both brzedit and the open source tools. Same is true for AF3. No clue why but I'm starting to think there may be multiple hardware version ecu's out there or i just got bad ecu from the factory.

It's either that, or brzedit changed a piece of code or a register in the ecu that the other flashing tools does not overwrite.

Now that I am on my second tank of pump gas (and fuel trims are very low again) I can test turning off the long term trims and running with the rear 02 unplugged again, but I am positive it will work fine that way, just without any long term trims. I may just bite the bullet and run the narrow band signal to the eco to keep it happy since I will absolutely want my wideband connected if I add a supercharger latter this year.

dave- 02-17-2015 08:07 PM

Quote:

Originally Posted by mad_sb (Post 2134930)
If you plan on removing the rear 02 to install a wideband in it's place, you will need to run the widebands narrow band emulation signal to the ecu rear o2 signal input. Otherwise you will get limp mode (rich closed loop afr target of about 13.7 rather than 14.7). I have tried every combination of dtc's, AFR 3 settings etc and none of them make any difference when the rear 02 is out of the pipe, plugged in or not. The only thing that does stop the rich target is dissabling long term trims completely by zeroing the closed loop load compensation map. That will eliminate the rich target and you will target 14.7 all the time in closed loop.

Sounds too hard, may as well leave factory o2 alone. I'll either get a bung put in on the over or front pipes to connect the LC-1 or make up a clamp that can stick it in the tailpipe like we would on the dyno. I don't need it there 24/7, just while tuning.

mad_sb 02-17-2015 08:51 PM

Quote:

Originally Posted by dave- (Post 2136486)
Sounds too hard, may as well leave factory o2 alone. I'll either get a bung put in on the over or front pipes to connect the LC-1 or make up a clamp that can stick it in the tailpipe like we would on the dyno. I don't need it there 24/7, just while tuning.

For a temporary solution you could just make up a socket or pin (not sure which you need since I'm not looking at the connector) connected to the lc-1 analogue output wire, unplug the factory 02, insert your lc-1 connector on or in ping 3 of the ecu side connector and use the secondary 02 bung for the lc.

ztan 04-29-2015 03:57 AM

Quote:

Originally Posted by mad_sb (Post 2128320)
Alright, I think I know what is going on here. On my E85 rom, I have had the long term fuel trims disabled for a long while now (by setting the closed loop target addative table to zero). I believe this is the reason I have not seen the "limp mode" rich fueling before.

Everything I have read on romraider indicates that the ecu only really cares about the sensor signal to the ecu, and if that is missing or out of range, it will go into limp mode with the rich closed loop targets. 02 can be unplugged, so long as the heater dtc's are turned off and you are feeding a narrow band signal to the ecu in place of the secondary 02 signal.

What I don't understand though, is why zeroing the AF3 tables does not remove the rich target as it normally does on the other subaru ecu's that have this limp mode issue.

I think the only real "fix" for removing the rear 02 on this platform is to feed a narrow band signal to the ecu.


I've had a look at the disassembly to see what happens to the rear O2 sensor input.

A01G ROM logging for Rear O2 sensor input:
Code:

paramname = O2S2_V
paramid = 0xFFF842FA
databits = 16
scalingrpn = x,0.000076293945,*

paramname = O2S2
paramid = 0xFFF8D274
isfloat = 1

An example of where the Rear O2 sensor data is pulled:
Code:

ROM:000AFE12 sub_AFE12:                              ; CODE XREF: Q_OBD_Mode_01+3Ep
ROM:000AFE12                sts.l  pr, @-r15      ; Store System Register Long
ROM:000AFE14                mov.l  #Pull_16_bit_sensor, r2 ; 12F24
ROM:000AFE16                jsr    @R2 ; Pull_16_bit_sensor ; Jump to Subroutine
ROM:000AFE18                mov    #h'2C, r4 ; ',' ; Move Immediate Byte Data
ROM:000AFE1A                extu.w  r0, r6          ; Extend as Unsigned (Word)
ROM:000AFE1C                lds    r6, fpul        ; Load to System Register
ROM:000AFE1E                float  fpul, fr8      ; Floating-point convert from integer
ROM:000AFE20                mova    h'AFFFC, r0    ; Move Effective Address
ROM:000AFE22                fmov.s  @r0, fr9        ; Floating-point move single precision
ROM:000AFE24                fmul    fr9, fr8        ; Floating-point multiply
ROM:000AFE26                movi20  #RAM_AF_SENS_2, r2 ; FFF8D274
ROM:000AFE2A                lds.l  @r15+, pr      ; Load to System Register Long
ROM:000AFE2C                rts                    ; Return from Subroutine
ROM:000AFE2E                fmov.s  fr8, @R2        ; Floating-point move single precision
ROM:000AFE2E ; End of function sub_AFE12

The Rear O2 sensor data is pulled when the Pull_16_bit_sensor subroutine (12F24 in A01G and 12FCC in A01C) is called with the value 0x2C in r4. If you have a look for references to the subroutine for pulling 16 bit sensor data with 0x2C in r4, there are a lot of them.

It should be possible to put a hook into the sensor pull subroutine and feed it narrowband data (based off the front O2 sensor) if r4 = 0x2C, whilst using the sensor input for something else without giving the ECU too much illogical information and sending it into some kind of limp home mode.

phrosty 04-29-2015 11:41 AM

Quote:

Originally Posted by ztan (Post 2231028)
I've had a look at the disassembly to see what happens to the rear O2 sensor input.

How are people disassembling the roms? I'd love to get my hands on this.

Kodename47 04-29-2015 02:44 PM

Quote:

Originally Posted by phrosty (Post 2231230)
How are people disassembling the roms? I'd love to get my hands on this.

IDA: http://www.romraider.com/forum/viewtopic.php?t=6303

mad_sb 05-01-2015 12:10 AM

Great info man!
Quote:

Originally Posted by ztan (Post 2231028)
I've had a look at the disassembly to see what happens to the rear O2 sensor input.

A01G ROM logging for Rear O2 sensor input:
Code:

paramname = O2S2_V
paramid = 0xFFF842FA
databits = 16
scalingrpn = x,0.000076293945,*

paramname = O2S2
paramid = 0xFFF8D274
isfloat = 1

An example of where the Rear O2 sensor data is pulled:
Code:

ROM:000AFE12 sub_AFE12:                              ; CODE XREF: Q_OBD_Mode_01+3Ep
ROM:000AFE12                sts.l  pr, @-r15      ; Store System Register Long
ROM:000AFE14                mov.l  #Pull_16_bit_sensor, r2 ; 12F24
ROM:000AFE16                jsr    @R2 ; Pull_16_bit_sensor ; Jump to Subroutine
ROM:000AFE18                mov    #h'2C, r4 ; ',' ; Move Immediate Byte Data
ROM:000AFE1A                extu.w  r0, r6          ; Extend as Unsigned (Word)
ROM:000AFE1C                lds    r6, fpul        ; Load to System Register
ROM:000AFE1E                float  fpul, fr8      ; Floating-point convert from integer
ROM:000AFE20                mova    h'AFFFC, r0    ; Move Effective Address
ROM:000AFE22                fmov.s  @r0, fr9        ; Floating-point move single precision
ROM:000AFE24                fmul    fr9, fr8        ; Floating-point multiply
ROM:000AFE26                movi20  #RAM_AF_SENS_2, r2 ; FFF8D274
ROM:000AFE2A                lds.l  @r15+, pr      ; Load to System Register Long
ROM:000AFE2C                rts                    ; Return from Subroutine
ROM:000AFE2E                fmov.s  fr8, @R2        ; Floating-point move single precision
ROM:000AFE2E ; End of function sub_AFE12

The Rear O2 sensor data is pulled when the Pull_16_bit_sensor subroutine (12F24 in A01G and 12FCC in A01C) is called with the value 0x2C in r4. If you have a look for references to the subroutine for pulling 16 bit sensor data with 0x2C in r4, there are a lot of them.

It should be possible to put a hook into the sensor pull subroutine and feed it narrowband data (based off the front O2 sensor) if r4 = 0x2C, whilst using the sensor input for something else without giving the ECU too much illogical information and sending it into some kind of limp home mode.



All times are GMT -4. The time now is 07:34 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.
User Alert System provided by Advanced User Tagging v3.3.0 (Lite) - vBulletin Mods & Addons Copyright © 2024 DragonByte Technologies Ltd.


Garage vBulletin Plugins by Drive Thru Online, Inc.