help needed CA18DET
Moderator: Matt
help needed CA18DET
ok i have a CA18DET engine and a Z32 MAF, as you may know the MAF translation map must be truncated in order to fit in the standard location,
can someone teach me how to relocate it in order to be able to fit all the MAF map ?
i believe the map should be written in an empty space, after that the map location should be changed also in the software and also the map size, and after that the nistune address file should be changed also.....
but this is theory i need some advices from someone who already did that.
can someone teach me how to relocate it in order to be able to fit all the MAF map ?
i believe the map should be written in an empty space, after that the map location should be changed also in the software and also the map size, and after that the nistune address file should be changed also.....
but this is theory i need some advices from someone who already did that.
* Got CA18DET Love
-
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
I have heard of some so-called 64 point VQ conversions for the CA18, but I highly doubt this has been accomplished properly.
The location of the 64 point, 16 bit table/map within the ROM is not the problem, rather, the code routine that uses the table values would have to be modified to step through a full set of 64 voltage points.
The original routine will only access a table of the original size, no matter where you point it to.
So, the VQ table routine would need to be analyzed and perhaps compared to a known 64 point routine (from another ecu), and rewritten similarly.
This is a large routine to rewrite, and more than likely there is not enough room in the original location to do it.
The location of the 64 point, 16 bit table/map within the ROM is not the problem, rather, the code routine that uses the table values would have to be modified to step through a full set of 64 voltage points.
The original routine will only access a table of the original size, no matter where you point it to.
So, the VQ table routine would need to be analyzed and perhaps compared to a known 64 point routine (from another ecu), and rewritten similarly.
This is a large routine to rewrite, and more than likely there is not enough room in the original location to do it.
-
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
Here is the CA18 VQ 16bit routine in its entirety. Starts at L802C.
Code: Select all
L8001:
std X0060
ldaa X005C
mul
std X005D
ldaa X0060
ldab X005C
mul
clr X005C
addd X005C
std X005C
ldaa X0061
ldab X005B
mul
addd X005C
std X005C
ldaa X005B
ldab #$00
rolb
stab X005B
ldab X0060
mul
addd X005B
std X005B
rts
;
L802C:
asld
cmpa #$3F
bcs L8034
ldd $7E,x
rts
;
L8034:
clr X005C
stab X005B
asla
tab
abx
ldd $02,x
subd $00,x
bcs L804A
jsr L8001
ldd $00,x
addd X005B
rts
;
L804A:
coma
comb
addd #$0001
jsr L8001
ldd $00,x
subd X005B
rts
Last edited by GZ@hybridka on Tue Oct 09, 2007 4:04 pm, edited 1 time in total.
-
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
Here is the VQ 16bit table routine from the ka24e, which uses the same MCU (hitachi 6303) , and uses full 64 point. Starts from top.
Code: Select all
clr X0048
cmpa #$3F
bcs LE0CC
ldd $7E,x
rts
;
LE0CC:
stab X0047
asla
tab
abx
ldd $02,x
subd $00,x
bcs LE0DE
bsr LE0EC
ldd $00,x
addd X004C
rts
;
LE0DE:
coma
comb
addd #$0001
bsr LE0EC
ldd $00,x
subd X004C
rts
;
LE0EA:
stx X0047
LE0EC:
std X004C
ldaa X0048
mul
std X004E
ldab X0047
ldaa X004D
mul
clr X004D
addd X004D
std X004D
ldaa X004C
ldab X0048
mul
addd X004D
bra LE10E
;
LE108:
staa X004C
ldab X0048
mul
clc
LE10E:
std X004D
ldaa X004C
ldab #$00
adcb #$00
stab X004C
ldab X0047
mul
addd X004C
std X004C
rts
-
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
I looked into this code a bit, and it would seem that the CA18 does indeed utilize a full set of 64 points (word wide), at least in some way.
Forgive me but I am not really familar with this ecu, I have never messed with VQ swaps and running cars anyways.
I see an anomaly in the first few data points beginning at 3E00 with the oem VQ table.
What happens when you paste over these values, using a complete 64 point table from another MAF? Firstly I can see there shouldnt be any immediate code function issues in doing this, but , that only goes as far as the table function itself.
Provided the car seems to run ok with a swapped, full size VQ table, there would only be one more test required before deeming the "modification" acceptable.
Someone would need to rig up a CA18 bench rig including voltage simulation for the MAF (potentiometer circuit). The voltage would need to be swept from 0-5v using the potentiometer while at the same time monitoring the VQ table output value (Q), and comparing to the actual VQ table itself. The Q output should match the current positions value on the VQ table, but specifically you would want to check the Q value at low MAF voltages where the oem VQ table has the odd values.
Just to summarize, from the original code I can see the VQ table starts at 3E00 and is 128 bytes long. Stepping through 2 bytes at a time , the final value is the 64th and not the 52nd.
Forgive me but I am not really familar with this ecu, I have never messed with VQ swaps and running cars anyways.
I see an anomaly in the first few data points beginning at 3E00 with the oem VQ table.
What happens when you paste over these values, using a complete 64 point table from another MAF? Firstly I can see there shouldnt be any immediate code function issues in doing this, but , that only goes as far as the table function itself.
Provided the car seems to run ok with a swapped, full size VQ table, there would only be one more test required before deeming the "modification" acceptable.
Someone would need to rig up a CA18 bench rig including voltage simulation for the MAF (potentiometer circuit). The voltage would need to be swept from 0-5v using the potentiometer while at the same time monitoring the VQ table output value (Q), and comparing to the actual VQ table itself. The Q output should match the current positions value on the VQ table, but specifically you would want to check the Q value at low MAF voltages where the oem VQ table has the odd values.
Just to summarize, from the original code I can see the VQ table starts at 3E00 and is 128 bytes long. Stepping through 2 bytes at a time , the final value is the 64th and not the 52nd.
Guys,
This truncation 64-point conversion routine stuff reads like chinese to me
Can I use the "Change Mass Airflow Meter" function in Nistune when I want to replace my stock CA18DET MAF by a Z32 MAF?
It seems to load the Z32 "MAF translation table" in a 52 point map. On the laptop it looks OK...
Regards,
Jean
This truncation 64-point conversion routine stuff reads like chinese to me
Can I use the "Change Mass Airflow Meter" function in Nistune when I want to replace my stock CA18DET MAF by a Z32 MAF?
It seems to load the Z32 "MAF translation table" in a 52 point map. On the laptop it looks OK...
Regards,
Jean