QR25DE Tuning

[fenugrec]

I've found a piece of code that controls the throttle actuator. It drives a PWM on either of two pins connected to the MC33186 H bridge. It's at code 0x1e36c (here http://pastebin.com/raw.php?i=DN2i2Pv9 ), and I'm close to understanding how it works. It depends on ram FFFF8648(16bit) (checks for <=0x50), rams ab84, ab8d, and abcf (3x 8bit) for flags, and FFFFA538(16bit) for the duty cycle. This value is between 0 and 500, rescaled to 0..320 for the timer register. I think the flags decide which direction to drive the H bridge; ram A538 appears to be always >0.
In other cases the duty cycle is set to a fixed 0x40 (20%). Maybe while at idle, that's sufficient to regulate RPM ? It would be obvious if you could wire an oscilloscope to one of the throttle actuator wires. In fact I might do just that, as soon as it gets warmer outside...

I would presume ram A538 is controlled by a feedback loop that includes either pedal input or cruise control setting. I can't find any refs to A538 elsewhere in the code, I'll have to check more thoroughly tomorrow. It might lead to one big PID loop, or maybe yet another dead end...

I may have a few more ram locations for you to check out. When can you do another addr-watch session ? I'll make a list

[jaf]

I am working away from home during the week so weekends only for messing with cars.
A fixed duty cycle on the throttle controller is not for idle - the throttle and ign timing are manipulated constantly to hold idle.
There are 2 levels of limp mode that will limit the throttle opening to 5% or 10% which may equate to the fixed 20% duty cycle (might be a max of 20%?).
Remember also that the throttle is held open more than idle only while the vehicle is in motion (above around 2kph) so there is speed sensor involvement in the decision to hold the throttle open as well as rpm and load. 86F2 seems to be 0 on coast or decel and FF on accel so that might be one part of the puzzle.

[fenugrec]

Not sure I understand what you mean; the 20% duty cycle only means the the actuator will move slowly, it doesn't equate to a determined opening (i.e. it could be 90% open and be commanded to open even more at a 5% duty cycle)... and from what I see in the code, either the the actuator position is held (0% duty cycle), or it's moved in either direction at a speed approximately proportional to a duty cycle.
I still haven't found where ram A538 is set. I even checked for references that would look like [FFFFA536+2] and similar in case A538 is part of a structure... no luck so far. I would sure be curious to see the original source code !

On another subject : is it possible your ECUID is at 0x7c80 and is "1EQ910" instead of 0x7c81 ("EQ910") as is listed in your romdefs ? I've reversed some Nissan J2534 software and it seems to want 6-character ECUIDs when reflashing...

[jaf]

I think that duty cycle determines throttle opening. You can hear the throttle motor being driven at a few kHz PWM at any static opening (engine off). You can also push the throttle plate open against a spring tension which you could not do if the throttle motor drove the throttle to the desired position and then just stopped. I have a spare throttle body that has been pulled apart. Think of a (geared down) electric motor continuously fighting against a closing spring tension to hold a throttle position. At different airflows, the overall closing pressure varies so the maps look a bit odd and can't be resolved to a % opening because of this.
The mechanism you have described sound exactly like the CAM advance solenoid operation which is however, not driven by the MC33186.
I am pretty sure the ECUID is only 5 chars. See also Tom's 350GT ROM address 8163 ECUID. May be a difference in JDM vs USDM ROMs or maybe the same error has occurred in defining both ROMs? That Nissan J2534 software is localized for the USA market by the way - can't flash non-USA factory ROMs.

[fenugrec]

Aah, I see. I had assumed the throttle plate was rigidly connected to the actuator motor and that it would hold its place without power applied. That pretty much destroys my theory then. But, I'm still certain the particular piece of code I described does apply a duty cycle (fixed 0%, 20% or 0-100%) to either side of the H bridge.

I spent a lot of time looking for references to the relevant RAM locations but it's getty a bit out of hand. Every time I find a place that writes a particular location (say, 86b2 or 8688 which are my personal favorites at the moment), their value always depend on a bunch of flags and 2-3 more ram variables. I never find something straightforward like "copy ADC13 to 8688".
And I've recently noticed that some of those stupid ram variables are accessed in an obtuse way : usually about 100 lines up from an interesting part, you get something like "mov 0xFFFF9D48, r11" and then all the following ram accesses are done through an offset added to r11 like "mov @(r11+0x18), r0" or even better :
mov 0x1A4, r0
mov @(r0+r11),r0 ; seriously? like r11 points to a >420 byte array of crap and we need to access its elements in the dumbest way possible ? It's not faster and takes more space than the proper way.
making it basically impossible to do an automated search of references. It's almost funny; I see some pieces of code which look like hand-written, nicely optimized assembly, and other parts like those make me wonder why they even bothered tweaking any code by hand.


For the table-reads, I finally finished analyzing a few interpolation and table-read subroutines (there seems to be some redundance; there are always 2 or 3 almost exact copies of each type of table read and interpolation subrout). That allowed me to find exactly which variables are involved in any particular table read. Maybe these could be added to your romdefs :

table 9940; ram8688 =>axis 9dd4; ram 84b2 or 8530 =>axis 9df4; interpolated result - 0x8000 =>ram9124;
table 9740: same vals&axes; (result-0x8000)=>ram9126;

table 7090; ram8688=ax 8b86; ram 84b2 or 8530=ax 8b66; result-0x8000=>ram8DDE;
table 7290; same vals&axes; result-0x8000=>ram8DE0;

table 7490: ram86b2/ram85f8=ax7e5f; ram 86c8 or fixed value(0xffff/0x0)=ax8c0a. result=>ram8ec2/8eb6?/9748/8de8/8e78/, this is a mess
table 7910: axeless?? code@35eba+. val1:ram85f8, val2=ram8a48

Of course I tried following the input / output ram variables for those, but I ran in to some problems as described above...

To connect the code "dots" between pedal potentiometer ADC input and actuator PWM output, I think I would need to know which ADC channels are used. Although with the DMA controller working its magic in background, it might be yet another dead end. It's turning out to be a lot of work just to find the place where the bloody rev hang happens !

I'm taking a break from the software side of this for a while, I'm running out of ideas. Besides we're still getting -15, -20C regularly ; I'm not in a hurry to go freeze my fingers probing around the ECU.
I attached my current disassembly of your rom. It's not easy to browse as-is, but if you're looking for something specific everything is there.

On the J2534 front, I looked in some of that Nissan software that used to be freely available on their website. I didn't find as much info as I hoped... I reversed part of the ROM file format, but that might not even be very useful if the data is encrypted in there and only gets decrypted by the ECU during self-write. If you have one of those Nissan .DAT files, does the header look a bit like this:
0x86 0x?? 0x?? ECUID 0x??

[jaf]

Early on in the quest to crack the ECU I went down the disassembly path but got frustrated very quickly with the diabolical Nissan coding. I would have thought that the code would be very tight considering all it has to do in real time on a miserly 40MHz processor but the opposite applies.
Next (fallback) strategy was to find out how to change the main tuning maps which has achieved 90% of what I set out to do. It has, over time, resolved down to just Ign timing, Cam timing and AFR. Throttle hang would be a great one to defeat - I have tried manipulating the throttle map so the throttle can't open on decel from 3600 to 2000rpm but something else comes into play to open it up plus I get limp mode randomly so I gave up.
I have deleted all USA factory ROMs that I found after not been able to decrypt them. They came with some dodgy Consult III software.
I think the J2534 software would be doing the decrypting and outputting the binary in something like an srec format.

[waynesa]

Hello Jaf, I read your article and so.hope you can help me, I have a 2002 qr25 x trail, have had the motor redone in June 13, still have not been able.to start car, I am only getting ignition signal to number 4 cylinder, is it possible that you can tell me what inputs are requierd for ignition signal. I have scoped the cam and crank sensor signals, all seem.ok, Nissan sa can't.help me, I have had my ecu tested by two indepenant companies, all ok , please any info will be greatly appreciated, thanks Wayne

[jaf]

Hi Wayne,

To generate the ign signal for each cylinder requires both a crank and cam sensor signal to be present (see attached image showing the relationship)
If you loose the cam signal, only one cylinder's ign signal can be generated. I am assuming you have found out that this is cylinder 4?
Switch your sensors around to see if the fault remains unchanged or not (both sensors are the same). It would help if you could interrogate the ECU and find the reported error codes - NDSII is invaluable for doing exactly that and taking the guess work out of the diagnosis.

Regards,

John

[waynesa]

John, thanks for the reply, I know its unrelated to what you are doing.
I have used an oscilloscope and checked both the cam and crank sensor signals, both are there, DC voltage also corresponds to factory service manual. The nissan approved test showed an error code for the cam sensor, this was replaced by Nissan, but still the same problem. I have swopped the sensors, but the the problem remains. The service centre tells me that that the car will start , but run poorly even if the cam sensor is faulty?
With the engine being overhauled, if the signal plate on the crank is out of alignment, could this cause a problem of no spark?
Nissan said that the timing was out, but my repair guy, Steves auto clinic, says all ok?

Should I insist on removing motor and stripping to check?

Will ignition signals be present from input from cam and crank sensors, or are there other factors, safety measures that could cut the signal?

Regards
Wayne

[jaf]

Hi Wayne,
I know from experience that the engine will stop dead in its tracks if it looses the crank sensor signal but not sure what happens if only the cam signal is missing.
One common mistake is to stuff up the cam timing because of the VVT cog - it must be fully home at 0 degrees advance when putting the chain back on. If the oil has drained out of the cog, it can be sitting at any advance angle when installed. You will get a Cam Position Sensor error code. Check the cam timing before doing anything more drastic.