Idiots guide to disassembly and reading opcode...

Fusion Ed · Post by **Fusion Ed** » Mon Oct 15, 2007 9:59 pm

I shall take a look there is definitely unused components on the board leading to other pins on the main plug.

Fusion Ed · Post by **Fusion Ed** » Tue Oct 16, 2007 2:00 am

Right I spent the last 2-3 hours looking over the ECU PCB. I dont seem to have any clear A/D channels. But I have found a little more about the ECU.

The sensor input connector has unused pins 1-2-11-16-17.

Pin 1 goes to the HD6303 - RX
Pin 2 goes to the HD6303 - TX
Pin 11 goes to the HD6303 - SCLK

Seems like it has a serial data port or something? Early consult? no idea.

Anyway, pins 16-17 do nothing, and appear to connect to nothing.

Pin37 on the AD chip goes to Pin15 on the main connector which is "Idle MAF CO". Now I don't really get that as there are only three wires to the MAF power signal and ground. So I have no idea where this goes, or what it does.
Pin38 on the AD chip goes to Pin12 on the connector which is for "ECU check signal"
Pin39 on the AD chip goes to Pin25 on the connector which seems to be the ignition signal.
Pin40 on the AD chip goes to O2 sensor (pin 6 main connector)
Pin41 on the AD chip goes to Coolant sensor (pin 5 main connector)

That's all I looked at so far.

Matt · Post by **Matt** » Tue Oct 16, 2007 1:59 pm

Yes the 6303 CPUs have SCI (Serial Communications Interface) but they only started getting used from Z32/R32 onwards when Nissan implemented CONSULT

You also will notice that the ROM chips went from 16K to 32K to fit the new code.

NIStune uses the USB consult for these ECUs since it is a lot easier that trying to reimplement NISSAN consult in the earlier ECUs and then add the hardware to support the voltage level conversion from TTL to 12V

GZ@hybridka · Post by **GZ@hybridka** » Wed Oct 17, 2007 1:37 pm

Hmm, well, what did the circuit for that "MAF idle CO" look like leading to the ADC? Any sort of bias resistors included for a thermistor perhaps?

I have never heard of that, I wouldnt know what it does.

Did you get a chance to stick an emulator on it yet? I setup a VE routine with room for future IAT correction /additional accel compensation and what not, if you can get rid of the need for the idle routine I can show you how to patch in the VE routine yourself.

I just realized though that a 32kb memory size is going to be needed for a working VE table, this ecu only has a single 256byte table for both fuel and ignition. So just stick to using NIStune on it with the larger NVRAM, it will be much easier.

With 32kb memory , the VE , fuel coef, and ignition tables can be expanded to 32x16 size as well.

Btw, an easy way to skip the idle routine is to simply change the first byte of the routine to RTS (39). Try it out and let me know how it works.

Fusion Ed · Post by **Fusion Ed** » Wed Oct 17, 2007 8:56 pm

The circuit for the "idle maf co" is exactly the same as the water temp but with different value resistors.

GZ@hybridka · Post by **GZ@hybridka** » Thu Oct 18, 2007 6:01 am

That sounds promising.

The idleMAFco pin should have around 3 volts on it without a thermistor connected.

You will need to put a potentiometer between sensor ground and the idleMAFco pin, then once you get the Nistune board on it I can give you a handful of RAM locations to trace in order to find it.

You mentioned that this pin did have a wire leading to it from the harness, what color was this wire? You might want to root it out and find out exactly what it is doing in the original harness, it may lead to a thermistor somewhere.

Fusion Ed · Post by **Fusion Ed** » Thu Oct 18, 2007 10:21 am

No problem, I shall look into this possibly tomorrow.

Ed

Fusion Ed · Post by **Fusion Ed** » Sat Nov 17, 2007 1:50 pm

The ECU is here now. I shall take it to the workshop next week and start playing to see what results I get. It should be interesting. Oh GZ, also wanted to thank you for your help with this project so far, as I have already said to Matt, its appreciated.

Fusion Ed · Post by **Fusion Ed** » Mon Nov 19, 2007 6:30 am

ECU is fitted USB drivers installed, however I am getting other errors. Matt what ntlookupid should the ECU be? I think thats causing my issues:

Cannot Connect!
Consult Checksum Invalid
-Check Ecu image not corrupt
-Check Correct address file
-Check matching consult value in the address file

Fusion Ed · Post by **Fusion Ed** » Mon Nov 19, 2007 6:48 am

ok now dont think its anything to do with ntlookupid as i tried from 1-40 and then Matts adr file and still no luck:

#
#
# NISSAN EK10 MA09ERT MAP ADDRESS (E)
#
# (C)2006 NISTUNE DEVELOPMENTS
#
# Variable,Start-Address [X,Y,Map size,value,Map-name] <= OPTIONAL

#UNIT NAME
TYPE_UNIT,EK10(MA09ERT),*,*,*

#ECU has 8000+4000 offset

#ENGINE SPECIFIC PARAMETERS
CYLINDER=4
ENGINECC=930
INJECTORCC=255

#ECU SPECIFIC PARAMETERS
NTLOOKUPID=38

#HIGH/LOW octane Fuel map.
HIGH_FUEL,&H00F0,16,16,256,1,High octane Fuel map
TP_SCALE_FUEL,&H00E0,16,1,16,1,TP scale (Fuel)
RPM_SCALE_FUEL,&H00D0,16,1,16,50,RPM scale (Fuel)

#HIGH/LOW octane Ignition time map.
HIGH_FIRE,&H0690,16,16,256,1,High octane Ignition time
TP_SCALE_FIRE,&H0460,16,1,16,1,TP scale (Ignition time)
RPM_SCALE_FIRE,&H0450,16,1,16,50,RPM scale (Ignition time)

#K required number
K_DATA,&H000A,2,1,2,1,K required number

#Void blast-off time
IGN_TIME,&H001B,1,1,1,1,Void blast-off time

#Feedback control
#FB_SWITCH,&H0038,1,1,1,1,Feedback control

#VQ map
VQ_MAP,&H05C0,16,1,128,1,VQ map

#TTP MAX/MIN
TTP_MAX,&H02E0,16,1,16,1,TTP MAX
TTP_MIN,&H02F0,16,1,16,1,TTP MIN

#TP Limit
#AF_LIMIT,&H02F0,16,1,16,1,TP Limit

#Rev.Limit
REV1_LIMIT,&H0550,2,1,2,12.5,Rev. Limit 1

#Speed Limit
SPEED1_LIMIT,&H0559,2,1,1,2,Speed Limit 1

#Additional maps
TEMP_CONV,&H05A0,16,2,32,1,Temperature of the water revision

DWELL_TIME,&H04A0,16,1,16,1,Dwell Time
DWELL_DUTY,&H04B0,16,1,16,1,Dwell duty

#Super charger
SUPERCHARGER_CONTROL_CONSTANT1,&H0196,1,1,1,1,Control1
SUPERCHARGER_CONTROL_CONSTANT2,&H019F,1,1,1,1,Control2
SUPERCHARGER_CONTROL_CONSTANT3,&H019B,1,1,1,1,Control3
SUPERCHARGER_CONTROL_CONSTANT3,&H01A9,1,1,1,1,Control4
SUPERCHARGER_CONTROL_CONSTANT5,&H01A8,1,1,1,1,Control5

SUPERCHARGER_CONTROL_TABLE1,&H08B0,16,1,16,1,Table1
SUPERCHARGER_CONTROL_TABLE2,&H08C0,16,1,16,1,Table2
SUPERCHARGER_CONTROL_TABLE3,&H08D0,16,1,16,1,Table3
SUPERCHARGER_CONTROL_TABLE4,&H08E0,16,1,16,1,Table4
SUPERCHARGER_CONTROL_TABLE5,&H08F0,16,1,16,1,Table5

see anything wrong with the above?

Matt · Post by **Matt** » Mon Nov 19, 2007 11:32 am

Okay I was getting this problem on the bench.

I dont know what the exact problem is here, but when I used my Rev3 board with emualtor plugged in no problems whatsoever.

But when I plugged in a Rev3A NVRAM board it would get this error all the time

What I did was ensure that I had a similar hardware grounding setup to Rev3. So I grounded the ECU to the bench ground and same with the USB connection

Once it was all grounded okay then retried connection a few times then it would connect. The ECUID didn't always read okay but otherwise it uploaded/downloaded and displayed consult data fine

Try out the gronuding and retry connections a few times and see if that works

Fusion Ed · Post by **Fusion Ed** » Mon Nov 19, 2007 11:39 am

Ok, strange. I'll try that when I'm back in the workshop tomorrow.

Matt · Post by **Matt** » Mon Nov 19, 2007 12:09 pm

No probs. The last address file that you received (one above) is the correct one

Worst case is to get the software to ignore the checksum error. But try getting everything grounded firstly.

Other situation is I send through a Rev3 board and you use an emulator with that. Because I never had a problem at all on the bench using that setup... only once I moved to the NVRAM setup was there an issue... so immediately I thought some grounding issue with this ECU

Improving grounding reduced probability of error. I tried several NVRAM boards out etc when I had this issue

Fusion Ed · Post by **Fusion Ed** » Mon Nov 19, 2007 1:32 pm

Ok, I shall solder in wire in a nice solid ground from the USB to the ecu and see how I do.

Fusion Ed · Post by **Fusion Ed** » Wed Nov 21, 2007 8:00 am

No luck Matt. It wouldn't get pass the checksum error.

Here is the log file: