I wish I had this much time. You guys have got heaps done
I managed to hook up the ECU last night on the bench (soldering wires to the back of the PCB with all the sensors hooked up) and got it running with the NIStune Type 1 board installed.
I had to change the memory map address on the CPLD from F700 to FA00 because there was code in the first location
It connects to NIStune and gets some of the data but then drops out. I'll have to find out later when I get more time why that is happening
Things left to find are ignition timing, switch position register (neutral, A/C, start etc) and battery voltage
Idiots guide to disassembly and reading opcode...
Moderator: Matt
Matt you input is great, I'm probably going on a bit, but its a shame you guys are so far a way, you deserve a drink haha! (and I goto admit I'm still wayyyy out of my depth 
and no chance of doing it alone.
ECU stuff again: Matt, does your bit if kit take up the free ram area? If I am to change to MAP based (oh wow I so can't wait) I obviously may run short since there only appears to be a small free area near the end of the map.
I don't mind dropping the idle control as GZ mentioned, it doesn't seem to help much anyway.
GZ, I have looked at the 16x1 table @ 08D0, and i can see the drop, however , can you explain why you think this is the table that cuts of the SC?
and no chance of doing it alone.ECU stuff again: Matt, does your bit if kit take up the free ram area? If I am to change to MAP based (oh wow I so can't wait) I obviously may run short since there only appears to be a small free area near the end of the map.
I don't mind dropping the idle control as GZ mentioned, it doesn't seem to help much anyway.
GZ, I have looked at the 16x1 table @ 08D0, and i can see the drop, however , can you explain why you think this is the table that cuts of the SC?
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
Well, I see 3 rpm based 16 point scales in what seems to be in a nested or modularized routine. These 3 scales do not seem to be associated with the switching output control of the port 6 outputs which also occur in this modular routine.
There are actually 5, but the first three seem to be different boost control profiles for the supercharger. The drop in the scale that I mentioned looks to line up around 4000 or so rpm.
I can only guess though as I cant really test it here. What it potentially doing is modifying a ram variable that is shared with companion processor.
Ill look into it a little further, and I will be working on map-based support, this code is nearly identical to ka24e.
You have your own dyno facility, correct? Try snag up a motorola 2.5bar or gm 3.0 bar map sensor and I can make it happen.
HTH,
Gabe Z.
There are actually 5, but the first three seem to be different boost control profiles for the supercharger. The drop in the scale that I mentioned looks to line up around 4000 or so rpm.
I can only guess though as I cant really test it here. What it potentially doing is modifying a ram variable that is shared with companion processor.
Ill look into it a little further, and I will be working on map-based support, this code is nearly identical to ka24e.
You have your own dyno facility, correct? Try snag up a motorola 2.5bar or gm 3.0 bar map sensor and I can make it happen.
HTH,
Gabe Z.
I had to get NIStune working in a 1984 Z31... these have stuff all RAM so NIStune takes about 20 bytes of RAM.
I have started using RAM from 0x0400 - 0x0420 from what I recall but that is configurable
Your ROM is 16K and the boards have 32K ROM space. Your code is located 0xc000-0xffff and my NIStune code and consult table is positioned at 0x8000 - 0x8300 or so
So you have lots of free ROM space for other stuff, I only require two bytes 0xFA00 and 0xFA01 which are used for memory mapping data byte and R/W status with the FTDI USB chip. That can be changed if need be, but I kept this position near the end of the code area in the ROM
I have started using RAM from 0x0400 - 0x0420 from what I recall but that is configurable
Your ROM is 16K and the boards have 32K ROM space. Your code is located 0xc000-0xffff and my NIStune code and consult table is positioned at 0x8000 - 0x8300 or so
So you have lots of free ROM space for other stuff, I only require two bytes 0xFA00 and 0xFA01 which are used for memory mapping data byte and R/W status with the FTDI USB chip. That can be changed if need be, but I kept this position near the end of the code area in the ROM
Its not my own dyno, but its on the site of my new unit (of which I should get the keys this weekend!!! another thing I cannot WAIT for) and I'm friendly with its owner so there is no problem there!!
I also have a 3 bar GM sensor sitting in my tool box... I can wire that in no problem The only difficulty is tuning, with no map trace, which will really have to wait till Matts modifications add that for me 
One thing that just occoured to me.. Matt, assuming with the help of GZ I get go MAP based, is it possible to add this as a boost scale rather than map voltage? Also thanks for the info on the memory sounds great
(I still cannot believe I'm talking about this relating to my ecu!)
Also I have just had a go at reading some of the code for the first time this look ok?
I also have a 3 bar GM sensor sitting in my tool box... I can wire that in no problem
The only difficulty is tuning, with no map trace, which will really have to wait till Matts modifications add that for me One thing that just occoured to me.. Matt, assuming with the help of GZ I get go MAP based, is it possible to add this as a boost scale rather than map voltage? Also thanks for the info on the memory sounds great
(I still cannot believe I'm talking about this relating to my ecu!)
Also I have just had a go at reading some of the code for the first time this look ok?
D42D SuperCharger.Routine:
D42D : DC D4 " " ldd RPM_MSB ;get current RPM
D42F : 04 " " lsrd ;double bit shift right
D430 : 04 " " lsrd ;double bit shift right
D431 : 4D "M" tsta ;test if zero or minus
D432 : 27 02 "' " beq LD436 ;branch if zero to LD436
D434 : C6 FF " " ldab #$FF ;else load double accumulator with FF
D436 LD436:
D436 : F7 01 76 " v" stab X0176 ;store accumulator B with current RPM
D439 : B6 01 29 " )" ldaa RPM_8bit ;load accumulator A with RPM 8 bit
D43C : CE C8 B0 " " ldx #$C8B0 ;load index reg c8B0 = (sc_c1)
D43F : BD F9 4E " N" jsr LF94E ;jump sub routien LF94E
D442 : B7 01 96 " " staa SuperCharger_Contr_1_Var
D445 : B0 C8 97 " " suba SuperCharger_Control_Constant1
D448 : 24 01 "$ " bcc LD44B
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
Yep that interpretation looks good.
The names I provided for the supercharger stuff is vague and I just went over it quick, once you get more feedback (running car or sim) you cant start naming stuff more appropriately.
The Gm 3.0 bar map sensor requires a conversion from the raw 8 or 10 bit adc count to display in pressure, but, one sensor that doesnt is a motorola mpx4250 2.5bar. With a linear range of 20-250 kpa, the 8 bit adc count of this sensor will match to the corresponding kpa value within a small margin of error. What that means is that a conversion would not be necessarily for raw load scales (if you wanted to view in Kpa).
For the GM 3.0 bar, the conversion for 8 bit adc count to kPa is ADC*1.28 + 3 , but this would only be to translate the values for viewing as the axis is still going to be based on the ADC count.
Matt, I think I am going to need that extra space and NVSRAM for this one, first time I have done something like that outside the scope of the original resources, should be fun
The names I provided for the supercharger stuff is vague and I just went over it quick, once you get more feedback (running car or sim) you cant start naming stuff more appropriately.
The Gm 3.0 bar map sensor requires a conversion from the raw 8 or 10 bit adc count to display in pressure, but, one sensor that doesnt is a motorola mpx4250 2.5bar. With a linear range of 20-250 kpa, the 8 bit adc count of this sensor will match to the corresponding kpa value within a small margin of error. What that means is that a conversion would not be necessarily for raw load scales (if you wanted to view in Kpa).
For the GM 3.0 bar, the conversion for 8 bit adc count to kPa is ADC*1.28 + 3 , but this would only be to translate the values for viewing as the axis is still going to be based on the ADC count.
Matt, I think I am going to need that extra space and NVSRAM for this one, first time I have done something like that outside the scope of the original resources, should be fun
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
Matt, so would it be possible for example for me to position a routine at B000-BFFF and be able to jump to it from the original program and return?
I could also use that rom as ram, correct, how would I address it (like ROM?)
I think I asked you the exact same thing once before, but just making sure.
I could also use that rom as ram, correct, how would I address it (like ROM?)
I think I asked you the exact same thing once before, but just making sure.
Should be fun - your telling me! I am aiming for 250bhp@8500rpm + nitrous on this little baby later... (ok with a slightly over bored engine) Its already crazy as it is...
How do you go about looking for TTPMIN,TTPMAX, and the fuel/airflow cut? It definitely has a cut somewhere. It used to drive me up the wall in the early days of my ownership, (before maf and TP rescale)
The pressure translation can be done in software perhaps, or later from the datalogs in excell or whatever. I'm, not overly that fussed to be honest, just a nice touch. How is IAT accomplished? Obviously the map voltage is replaces the MAF voltage, but do we need another analogue input for a IAT correction?
GZ you were talking about needing more space in the NV ram. Presumably it will still be possible to keep this within the confines of a normal Eprom, so that the code can operate on an ECU outside of nistune?
Its nearly 4am here, so I really should get some zzz.
However before I go check this out
http://www.youtube.com/watch?v=1F43fNZUVB8
How do you go about looking for TTPMIN,TTPMAX, and the fuel/airflow cut? It definitely has a cut somewhere. It used to drive me up the wall in the early days of my ownership, (before maf and TP rescale)
The pressure translation can be done in software perhaps, or later from the datalogs in excell or whatever. I'm, not overly that fussed to be honest, just a nice touch. How is IAT accomplished? Obviously the map voltage is replaces the MAF voltage, but do we need another analogue input for a IAT correction?
GZ you were talking about needing more space in the NV ram. Presumably it will still be possible to keep this within the confines of a normal Eprom, so that the code can operate on an ECU outside of nistune?
Its nearly 4am here, so I really should get some zzz.
However before I go check this out
http://www.youtube.com/watch?v=1F43fNZUVB8
You can use that area of NVRAM as you like... ROM or RAM doesn't matter
However if you do a 'STORE' then the RAM contents will be permanently put in the EEPROM part of the chip
Ed has a NIStune programmer board so he can reprogram the NVRAM as he pleases.
Currently NTProg only takes an 64K ENT (Encoded NIStne) file, but I can change it to take a normal BIN so you can program that into the board for testing
When you have your final BIN sorted, I can run it through my autopatcher to include the NIStune USB firmware
You need to change your file size to 32K by padding out with FF and adjust your symbol table origin to 0x8000 if doing the above
However if you do a 'STORE' then the RAM contents will be permanently put in the EEPROM part of the chip
Ed has a NIStune programmer board so he can reprogram the NVRAM as he pleases.
Currently NTProg only takes an 64K ENT (Encoded NIStne) file, but I can change it to take a normal BIN so you can program that into the board for testing
When you have your final BIN sorted, I can run it through my autopatcher to include the NIStune USB firmware
You need to change your file size to 32K by padding out with FF and adjust your symbol table origin to 0x8000 if doing the above
I always look through code which has those tables known (in another ECU) and then look at the routine it uses
Then I go hunting through for that routine in the code where I'm looking for the new table. For those I couldn't find a similar routine yet from the KA24E code to match the MA09ERT code
I can test these on the bench here since AFM and RPM are simulated now on that ECU once found... wont be until sunday night though since the weekend is booked out
Then I go hunting through for that routine in the code where I'm looking for the new table. For those I couldn't find a similar routine yet from the KA24E code to match the MA09ERT code
I can test these on the bench here since AFM and RPM are simulated now on that ECU once found... wont be until sunday night though since the weekend is booked out
To answer an earlier question... no you cant just add new variables. You can reuse other ones, but new entries mean new scalings and display methods. I have an internal table which I update for new entries
Just let me know what they are, and what the scalings (conversion) are
Anyway I've attached a screenshot of NIStune with your ECU. I have one big problem however, the streaming of consult registers is very slow...
I dont know why either. I've changed the RAM area used to 0x0400 which is not used by anything else
StreamInitFlag is an uninitialised variable. When streaming consult registers is enabled by command, it gets set to 1
Now the streaming counter and output bytes in the MA09 ECU are going very slowly compared to other ECUs.... so slow that it only runs at a good speed about 8000rpm to trigger enough interrupts to get the code out at a decent rate
My code gets injected at the start off the interrupt handler for any ecu
Appears this interrupt isn't getting called as often as it should.
Now I was using IRQ1 for the KA24E, A31, CA18 so I thought it should work for this. However I've noted that Maxima uses IRQ2 entry... perhaps try that out??
Just let me know what they are, and what the scalings (conversion) are
Anyway I've attached a screenshot of NIStune with your ECU. I have one big problem however, the streaming of consult registers is very slow...
I dont know why either. I've changed the RAM area used to 0x0400 which is not used by anything else
StreamInitFlag is an uninitialised variable. When streaming consult registers is enabled by command, it gets set to 1
There is a stream register counter which runs through the total number of consult registers to stream and decrements until it hits zerostart: ldab streaminitflag (0x0403)
cmpb #streaminit (0x01)
bne constart ; check streaminitflag = 1
If above zero then will output a consult register value to the bus, otherwise it will look for the next consult command in 'constart'streamregcheck: ldab streamregidx (0x0402)
cmpb #$00
beq constart
jmp streamregnext
Now the streaming counter and output bytes in the MA09 ECU are going very slowly compared to other ECUs.... so slow that it only runs at a good speed about 8000rpm to trigger enough interrupts to get the code out at a decent rate
My code gets injected at the start off the interrupt handler for any ecu
Any commands removed and replaced (see bold above) are called by my consult routine so nothing is affectedDCA4 IRQ1_entry:
DCA4 : BD 80 58 " X" jsr L8058
DCA7 : 01 " " nop
DCA8 : 27 18 "' " beq LDCC2
DCAA : D6 76 " v" ldab X0076
DCAC : C5 40 " @" bitb #$40
DCAE : 27 12 "' " beq LDCC2
DCB0 : 96 75 " u" ldaa X0075
DCB2 : 84 FE " " anda #$FE
DCB4 : 97 31 " 1" staa X0031
DCB6 : C4 BF " " andb #$BF
DCB8 : D7 30 " 0" stab X0030
DCBA : D7 76 " v" stab X0076
DCBC : DC 36 " 6" ldd X0036
DCBE : BD F5 05 " " jsr LF505
DCC1 : 3B ";" rti
Appears this interrupt isn't getting called as often as it should.
Now I was using IRQ1 for the KA24E, A31, CA18 so I thought it should work for this. However I've noted that Maxima uses IRQ2 entry... perhaps try that out??
- Attachments
-
- ma09ert.JPG
- MA09ERT
- (191.7 KiB) Downloaded 7055 times
-
GZ@hybridka
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
This is an extremely interesting ecu, I just found a picture and I was very surprised. What sort of harness connector is that? Is it like other nissans? It almost looks denso style.
Here is my .sym file with more things added. Got it fairly well sorted now. Ignition timing and battery voltage are found as well as most other consult related stuff.
Ive found final injection Ti, but a bit of code will need to be added to convert it to pulsewidth figure for consult, or it could be done in software I guess.
Ed, map conversion can be done using only the original ecu resources, ill set something up and if you want you can do some testing when you get the emu set up.
Your going to need the Nistune board on it to have the serial comms though, its not really tunable without it.
Here is my .sym file with more things added. Got it fairly well sorted now. Ignition timing and battery voltage are found as well as most other consult related stuff.
Ive found final injection Ti, but a bit of code will need to be added to convert it to pulsewidth figure for consult, or it could be done in software I guess.
Ed, map conversion can be done using only the original ecu resources, ill set something up and if you want you can do some testing when you get the emu set up.
Your going to need the Nistune board on it to have the serial comms though, its not really tunable without it.