Good idea Tom. I'll give that a go next weekend and report back on what I find. Any thing else discovered on the 350gt front that may help here?
I wonder if there a similar address in the X-Trail code that is read to decide on which ign table to use?
QR25DE Tuning
Re: QR25DE Tuning
Hmm, I didn't know you could watch a RAM location live. This opens up a lot of possibilities. There are many RAM locations I encountered that I didn't really try to analyze because it would be hopeless without a live debugger ... Could you also check RAM FFFF8488 ? it has to do with the IGN tables, and is accessed from at least a dozen places in the code.
Also FFFF86F2, which may have an important effect on ignition. I still don't know precisely how the table reads and interpolations work, I don't have enough mental RAM to keep track of all the registers through the 3 or 4 function calls that happen for every table read.
And a last request if you don't mind, RAM FFFF86B2 which is related to throttle maps. I'm hoping very hard it's turns out to be accel_P, then we can get started on fixing that rev hang!
(if someone cares to take a look here's some code related to the IGN mapping :
loc_24514: section of code that reads IGN tables 2 and 3. http://pastebin.com/raw.php?i=MdtV23Cw
it calls "rd_table2" twice. http://pastebin.com/raw.php?i=WTf2fRFm
rd_table2 calls a few things:
"interpol1a" and "interpol1b" which are confusing, similar, and not interpolators but possibly "nearest cell finders" ? http://pastebin.com/raw.php?i=zwH0x2Dm
"mult_f1" which, if I'm reading it correctly, returns r0=r0+{r3(r2-r0) >>16} ? (suggesting linear interpolation). http://pastebin.com/raw.php?i=umpnHEJm
and "div32" that looks like a 32bit division with no visible side-effects.
unrelated note:
While marking the throttle tables around 7490, I happened on another throttle-related map at 7890; 8x8 16bit. It's uniniteresting in that it contains only 0x8000, but the associated axes (8E7A, 8E8A, both 8x16bit) might give some insight on what it does? It might not be worth wasting time on, but I figure it should be added to your list for the sake of completeness.
[EDIT: correct description of mult_f1]
Also FFFF86F2, which may have an important effect on ignition. I still don't know precisely how the table reads and interpolations work, I don't have enough mental RAM to keep track of all the registers through the 3 or 4 function calls that happen for every table read.
And a last request if you don't mind, RAM FFFF86B2 which is related to throttle maps. I'm hoping very hard it's turns out to be accel_P, then we can get started on fixing that rev hang!
(if someone cares to take a look here's some code related to the IGN mapping :
loc_24514: section of code that reads IGN tables 2 and 3. http://pastebin.com/raw.php?i=MdtV23Cw
it calls "rd_table2" twice. http://pastebin.com/raw.php?i=WTf2fRFm
rd_table2 calls a few things:
"interpol1a" and "interpol1b" which are confusing, similar, and not interpolators but possibly "nearest cell finders" ? http://pastebin.com/raw.php?i=zwH0x2Dm
"mult_f1" which, if I'm reading it correctly, returns r0=r0+{r3(r2-r0) >>16} ? (suggesting linear interpolation). http://pastebin.com/raw.php?i=umpnHEJm
and "div32" that looks like a 32bit division with no visible side-effects.
unrelated note:
While marking the throttle tables around 7490, I happened on another throttle-related map at 7890; 8x8 16bit. It's uniniteresting in that it contains only 0x8000, but the associated axes (8E7A, 8E8A, both 8x16bit) might give some insight on what it does? It might not be worth wasting time on, but I figure it should be added to your list for the sake of completeness.
[EDIT: correct description of mult_f1]
Last edited by fenugrec on 20 Jan 2014, 07:26, edited 1 time in total.
Re: QR25DE Tuning
Keep the requests coming..... I will test what I can on the coming weekend.
I'll update the definition text file as new discoveries are made and repost it from time to time. I left out a bunch of structures that are unknowns at present. Is it useful to add them in as unknowns?
Any guesses on the 7090 map and its clones? The axis are load 8B66 and rpm 8B86 as far as I can tell. Any link to ign timing in code?
I'll update the definition text file as new discoveries are made and repost it from time to time. I left out a bunch of structures that are unknowns at present. Is it useful to add them in as unknowns?
Any guesses on the 7090 map and its clones? The axis are load 8B66 and rpm 8B86 as far as I can tell. Any link to ign timing in code?
Re: QR25DE Tuning
re adding unknown structures in the list of definitions : not very useful for now, you're right. But maybe they should still be noted somewhere in case they turn out to be interesting, or if we eventually have insight on their use.
Concerning 7890 in particular, I think it's related to the throttle maps because it's read just after 7490 (throt map C), both refering to ram FFFF86B2 just before the table read.
re 7090 map : Sorry, I don't have a clue based only on the code. Did I mention there's a lot of code p-) . 7090 is read along with 7290 (maybe some interpol between the two). I can confirm the axes you found (8b66 and 8b86), but the only related element I could suggest checking out is ram FFFF8688.
re 64f5 ign map: I may be wrong about the "unused" code portion that reads the 64f5 ign table. I thought it was never called from anywhere, but I recently found large "call tables", from 2470 to 27b4, that reference over 200 subfunctions including the one that reads 64f5. That's a lot of code.
Fun fact : I keep forgetting that the "jsr XX" instruction is a delayed branch instruction. Meaning the opcode right after jsr is actually executed just before the jump is taken !! Man that had me scratching my head a couple of times.
Concerning 7890 in particular, I think it's related to the throttle maps because it's read just after 7490 (throt map C), both refering to ram FFFF86B2 just before the table read.
re 7090 map : Sorry, I don't have a clue based only on the code. Did I mention there's a lot of code p-) . 7090 is read along with 7290 (maybe some interpol between the two). I can confirm the axes you found (8b66 and 8b86), but the only related element I could suggest checking out is ram FFFF8688.
re 64f5 ign map: I may be wrong about the "unused" code portion that reads the 64f5 ign table. I thought it was never called from anywhere, but I recently found large "call tables", from 2470 to 27b4, that reference over 200 subfunctions including the one that reads 64f5. That's a lot of code.
Fun fact : I keep forgetting that the "jsr XX" instruction is a delayed branch instruction. Meaning the opcode right after jsr is actually executed just before the jump is taken !! Man that had me scratching my head a couple of times.
Re: QR25DE Tuning
Here are the outcomes for Address Watch:
FFFF8488:
Continuously updating values. Min D, Max 6A. Behaves like load value.
FFFF86F2:
Not continuously updating. 0 on decel or cruise, FF or thereabouts on accelerating.
FFFF86B2:
Activity only on throttle tip in. Min 0, max 4. Normally 0 on steady state. No activity motor off.
FFFF8688:
Registers from 0 to 2 dependent on accel position. Activity motor on or motor off.
FFFF8689:
Registers from 0-FF dependent on accel position. Activity motor on or motor off.
FFFFAB8A:
No activity detected.
FFFF8488:
Continuously updating values. Min D, Max 6A. Behaves like load value.
FFFF86F2:
Not continuously updating. 0 on decel or cruise, FF or thereabouts on accelerating.
FFFF86B2:
Activity only on throttle tip in. Min 0, max 4. Normally 0 on steady state. No activity motor off.
FFFF8688:
Registers from 0 to 2 dependent on accel position. Activity motor on or motor off.
FFFF8689:
Registers from 0-FF dependent on accel position. Activity motor on or motor off.
FFFFAB8A:
No activity detected.
Re: QR25DE Tuning
Hi,
thanks for that additional info. I'll try to see if I can make anything out of it...
Did you see if 8689 wrapped around once or twice when pressing the pedal ? i.e. FFFF8688 + 8689 could belong together and form a the TPS / AccelP1 value from 0 to 2FF ? that would fit with the 10bit ADCs, but I'll admit it's a bit of a stretch.
86B2 sounds like some kind of derivative, I'll try to find where it gets calculated.
AB8A : if the value was >=0x80, then table 6E25 is used. If <0x80, then 6D25 is used. (table 6F25 is always read first)
thanks for that additional info. I'll try to see if I can make anything out of it...
Did you see if 8689 wrapped around once or twice when pressing the pedal ? i.e. FFFF8688 + 8689 could belong together and form a the TPS / AccelP1 value from 0 to 2FF ? that would fit with the 10bit ADCs, but I'll admit it's a bit of a stretch.
86B2 sounds like some kind of derivative, I'll try to find where it gets calculated.
AB8A : if the value was >=0x80, then table 6E25 is used. If <0x80, then 6D25 is used. (table 6F25 is always read first)
Re: QR25DE Tuning
I probably wasn't too clear on that point: 8688 and 8689 are indeed the 10 bit output of the throttle or pedal sensor - which one, I can't say for sure but I have a feeling it is throttle since the numbers are different when the engine is running.
AB8A could be a low temperature set point - can't test below 30 degrees C here for some months to come.
I could have wrongly guessed one of the maps as being a throttle map. One could be a torque delivery map or similar?
86B2 could have some bearing on what I think could be throttle enrichment scales at 8416, 8426, 8436 and 8446. Any support for this in code?
The logic controlling which of the Ign timing maps (64F5, 65F5 or 66F5) is something I would really like to get sorted.(6975 is the cold ign map). Nissan had run with a simple lo det map switching to a hi det map on knock approach up until this generation ECU. I wonder if any Altima / Sentra ROMs are posted with a difference between the maps to help identify function?
AB8A could be a low temperature set point - can't test below 30 degrees C here for some months to come.
I could have wrongly guessed one of the maps as being a throttle map. One could be a torque delivery map or similar?
86B2 could have some bearing on what I think could be throttle enrichment scales at 8416, 8426, 8436 and 8446. Any support for this in code?
The logic controlling which of the Ign timing maps (64F5, 65F5 or 66F5) is something I would really like to get sorted.(6975 is the cold ign map). Nissan had run with a simple lo det map switching to a hi det map on knock approach up until this generation ECU. I wonder if any Altima / Sentra ROMs are posted with a difference between the maps to help identify function?
Re: QR25DE Tuning
Updated defs attached... many more axis attached to the maps.
Anyone wanting a simple disassembler? The attached one does a remarkably good job with minimal errors compared to other similar packages.
Usage from command prompt: shdis [ROM filename] > [output filename]
Anyone wanting a simple disassembler? The attached one does a remarkably good job with minimal errors compared to other similar packages.
Usage from command prompt: shdis [ROM filename] > [output filename]
- Attachments
-
- shdis_19991206.zip
- Disassembler for SH7055 and SH7058
- (9.61 KiB) Downloaded 207 times
-
- ROM definitions.txt
- (3.08 KiB) Downloaded 214 times
Re: QR25DE Tuning
Hi, sorry for this huge wall of text... I tried being brief but I'd rather have all the info here as a reference.
ram 8688 is even more interesting... I'll take another look.
ram AB8A is still a mystery. I can see where it gets cleared and tested, but never written !
I haven't seen any other QR25DE roms online except yours, I think few people managed to dump those ECUs yet... I look forward to looking at mine.
****************
-table 6975: I'm not sure if you've worked out all its details, here's some extra info just in case :
I can find two places where it's read:
1) @0xFA76 : only 6975 is used. This is part of subf 0xB7E0 that is called twice on reset (once at 0xB8D0 and once as part of calltable 0x31AC, used just a few lines below)
2) @0x1c118 : 6975 is conditionally read just before 6865 gets read. (note : there seems to be no interaction between those two tables, they just happen to be read one after the other)
But the condition is hardcoded as (0xE0 & 0x20) so unless the ROM re-writes itself, 6975 is always used in that part of the code.
****************
-Some other ram locations that could be interesting:
FFFF8480, rpm ?? 16bit. Perhaps related to FFFF8484,16bit. 8480 is read in a lot of places so it has to be important !
FFFF85EA, 8bit. No clue. used to index in tables 8416,8426,8436,8446 (see below)
FFFF84DD, 8bit. no clue. used to index in tables 8484,84a8,84c0,8880 (see below)
FFFF8648: related to table 6975 (maybe not so interesting)
FFFF85A6: related to table 6975 (maybe not so interesting)
FFFF85FC: also related to ign tables 65 and 66F5.
****************
-tables 8416,26,36,46 : 1Dx16 ,8bit, read from code 0x47924 and following.
They work together like a kind of big reverse-lookup table. I'll try to explain what I understood...
r1= ram FFFF85EA(8bit);
r1= r1 -8,
if r1<0 then r1=0; (make sure no negative value is used next)
r1=r1*2;
if r1>0xFF then r1=0xFF;
r5=r3=r1;
A value is then interpolated from each of the four 1D tables with the same input (r5), and each result stored on the stack;
then, supposing ram FFFF8480 is a 16bit RPM, the following happens:
RPM is divided by 256 to give an 8bit RPM8;
if RPM8 >= value read from tab8416, then ram FFFF9EB7 is set to 0;
if RPM8 < value from t8416 and RPM8 >= value from t8426, then ram 9EB7 =1,
if RPM8 < value from t8426 && RPM8>= value from t8436, then ram 9EB7=2,
if RPM8 < value from t8436 && RPM8>= val from t8446, then ram 9EB7=3,
if RPM8 < value from t8446 then ram 9EB7=4.
But then I can find no other code that refers to 9EB7, so I can't explain why all of that just happened !
And unfortunately ram 86B2 doesn't visibly enter the picture here.
****************
-1D tables 8484, 84A8, 84C0, 8880: no separate axis that I can find. They're all interpolated using ( RAM FFFF84DD(8bit)) as the look-up value.
-1D tables : I found tons of small 1x8, 1x16, 1x32 look-up tables. I didn't list them... but if needed I can easily find out which RAM variable is used to index a particular table.
And here's another unknown map 6845 : also 4x4x8bit, axes 7C60 and 7C64.
ram 8688 is even more interesting... I'll take another look.
ram AB8A is still a mystery. I can see where it gets cleared and tested, but never written !
I haven't seen any other QR25DE roms online except yours, I think few people managed to dump those ECUs yet... I look forward to looking at mine.
****************
-table 6975: I'm not sure if you've worked out all its details, here's some extra info just in case :
I can find two places where it's read:
1) @0xFA76 : only 6975 is used. This is part of subf 0xB7E0 that is called twice on reset (once at 0xB8D0 and once as part of calltable 0x31AC, used just a few lines below)
2) @0x1c118 : 6975 is conditionally read just before 6865 gets read. (note : there seems to be no interaction between those two tables, they just happen to be read one after the other)
But the condition is hardcoded as (0xE0 & 0x20) so unless the ROM re-writes itself, 6975 is always used in that part of the code.
****************
-Some other ram locations that could be interesting:
FFFF8480, rpm ?? 16bit. Perhaps related to FFFF8484,16bit. 8480 is read in a lot of places so it has to be important !
FFFF85EA, 8bit. No clue. used to index in tables 8416,8426,8436,8446 (see below)
FFFF84DD, 8bit. no clue. used to index in tables 8484,84a8,84c0,8880 (see below)
FFFF8648: related to table 6975 (maybe not so interesting)
FFFF85A6: related to table 6975 (maybe not so interesting)
FFFF85FC: also related to ign tables 65 and 66F5.
****************
-tables 8416,26,36,46 : 1Dx16 ,8bit, read from code 0x47924 and following.
They work together like a kind of big reverse-lookup table. I'll try to explain what I understood...
r1= ram FFFF85EA(8bit);
r1= r1 -8,
if r1<0 then r1=0; (make sure no negative value is used next)
r1=r1*2;
if r1>0xFF then r1=0xFF;
r5=r3=r1;
A value is then interpolated from each of the four 1D tables with the same input (r5), and each result stored on the stack;
then, supposing ram FFFF8480 is a 16bit RPM, the following happens:
RPM is divided by 256 to give an 8bit RPM8;
if RPM8 >= value read from tab8416, then ram FFFF9EB7 is set to 0;
if RPM8 < value from t8416 and RPM8 >= value from t8426, then ram 9EB7 =1,
if RPM8 < value from t8426 && RPM8>= value from t8436, then ram 9EB7=2,
if RPM8 < value from t8436 && RPM8>= val from t8446, then ram 9EB7=3,
if RPM8 < value from t8446 then ram 9EB7=4.
But then I can find no other code that refers to 9EB7, so I can't explain why all of that just happened !
And unfortunately ram 86B2 doesn't visibly enter the picture here.
****************
-1D tables 8484, 84A8, 84C0, 8880: no separate axis that I can find. They're all interpolated using ( RAM FFFF84DD(8bit)) as the look-up value.
-1D tables : I found tons of small 1x8, 1x16, 1x32 look-up tables. I didn't list them... but if needed I can easily find out which RAM variable is used to index a particular table.
And here's another unknown map 6845 : also 4x4x8bit, axes 7C60 and 7C64.
Re: QR25DE Tuning
Get that ROM dumped and uploaded here!
I have seen a couple of Sentra /Altima ROMs but in their factory encrypted state so nothing usable.
Keep the dissection going and I will run address watch again next weekend to verify some more interesting unknowns.
On the tuning front, I've had to loose a bit of ign timing since moving back to the tropics. I thought a MAF inherently took into account humidity but somehow the motor can't take as much advance on humid days. Anyone know why this is so?
I have seen a couple of Sentra /Altima ROMs but in their factory encrypted state so nothing usable.
Keep the dissection going and I will run address watch again next weekend to verify some more interesting unknowns.
On the tuning front, I've had to loose a bit of ign timing since moving back to the tropics. I thought a MAF inherently took into account humidity but somehow the motor can't take as much advance on humid days. Anyone know why this is so?