Memory dump of ECU

[b3lha]

Joe (SVXistentialist) has kindly lent me a UK TCU. I have extracted the code with a view to finding out what the "Economy Mode" button does on the European cars.

It turns out that Joe was exactly right when he hypothesised that the Economy switch locks out power mode. With the Economy switch on, power mode will not engage when you floor the throttle. This seems pointless to me. If I floor the throttle it's because I want some speed and I want it now. So I decided to have a go at changing the program to make this switch a little more useful - like the power switch on JDM cars.

Here is the part of the program that decides whether to use normal or power mode on a UK TCU:

e5f7 12 8a 02 18 brset (0x008A), 0x02, [0xE613]
e5fb 12 3a 80 14 brset (0x003A), 0x80, [0xE613]
e5ff 12 11 20 10 brset (0x0011), 0x20, [0xE613]
e603 12 12 40 0c brset (0x0012), 0x40, [0xE613]		; Manual Switch
e607 12 11 40 08 brset (0x0011), 0x40, [0xE613]		; Economy Switch
e60b 96 4d       ldaa (0x004D)
e60d 84 07       anda 0x07
e60f 81 03       cmpa 0x03				; Stick in position D,3 or 2
e611 25 03       bcs [0xE616]
e613 5f          clrb		Branch Target from e5f7, e5fb, e5ff, e603, e607
e614 20 47       bra [0xE65D]
e616 5f          clrb		Branch Target from e611
e617 ce c8 fe    ldx 0xC8FE
e61a 96 18       ldaa (0x0018)
e61c 5f          clrb
e61d a1 00       cmpa (X+0x00)
.....
e65d d7 5a       stab (0x005A)		Branch Target from e614, e656, e65a
e65f 39          rts

The relevant line of code is at location e607. It says if the Economy switch is on, goto location e613. The command at location e613 says set the B register to zero and go to location e65d. At e65d it stores the value of the B register at location 005a. This is the variable that indicates which shift map to use. Compare this with the JDM program that was discussed way back in this thread.

e76f 12 8a 02 20 brset (0x008A), 0x02, [0xE793]
e773 12 3a 80 1c brset (0x003A), 0x80, [0xE793]
e777 12 11 20 18 brset (0x0011), 0x20, [0xE793]
e77b 12 12 40 14 brset (0x0012), 0x40, [0xE793] 	; Manual Switch
e77f 13 11 40 04 brclr (0x0011), 0x40, [0xE787]		; Power Switch
e783 c6 02       ldab 0x02
e785 20 55       bra [0xE7DC]
e787 12 5a 02 08 brset (0x005A), 0x02, [0xE793]
e78b 96 4d       ldaa (0x004D)
e78d 84 07       anda 0x07
e78f 81 03       cmpa 0x03				; Stick in position D,3 or 2
e791 25 03       bcs [0xE796]
e793 5f          clrb		
e794 20 46       bra [0xE7DC]
e796 ce c9 04    ldx 0xC904
e799 96 18       ldaa (0x0018)
e79b 5f          clrb
e79c a1 00       cmpa (X+0x00)
.....
e7dc d7 5a       stab (0x005A)
e7de 39          rts

In the JDM code, the command at location e77f says if the Power switch is off, goto e787. If not (ie. Power Switch is on), set the B register to 2 and go to e7dc. At e7dc it stores the value of the B register at location 005a, which is the variable that indicates which shift map to use. We previously determined that 005a is 0 for "power mode not engaged", 1 for "power mode engaged due to throttle" and 2 for "power mode engaged by switch"

As a first attempt, I have modified the UK TCU code as follows:

e5f7 5f          clrb
e5f8 12 8a 02 61 brset (0x008A), 0x02, [0xE65D]
e5fc 12 3a 80 5d brset (0x003A), 0x80, [0xE65D]
e600 12 11 20 59 brset (0x0011), 0x20, [0xE65D]
e604 12 12 40 55 brset (0x0012), 0x20, [0xE65D]		; Manual Switch
e608 12 11 40 04 brset (0x0011), 0x40, [0xE610]		; Economy Switch
e60c c6 02       ldab 0x02
e60e 20 4d       bra [0xE65D]
e610 96 4d       lda (0x004D)
e612 84 07       anda 0x07
e614 81 03       cmpa 0x03				; Stick in position D,3 or 2
e616 24 45       bcc [0xE65D]
e618 ce c8 fe    ldx 0xC8FE
e61b 96 18       ldaa (0x0018)
e61d a1 00       cmpa (X+0x00)
.....
e65d d7 5a       stab (0x005A)		Branch Target from e5f8, e5fc, e600, e604, e60e, e616, e656, e65a
e65f 39          rts

Rather than having a separate "clrb" for each possible execution path, I have put a single one at the start, and I have changed the destination of the "brset" instruction to go directly to e65d. This creates a few bytes of space where I can insert the extra code. The instruction at e608 says, if the economy switch is on, goto e610, which carries out the normal processing - power mode on kickdown. However, if the ecomony switch is off, the instruction at e60c will set the B register to 2 and go to e65d, which stores the value of the B register at location 005a. Power mode engaged.

In summary, the modified program enables "power mode on demand" when the economy switch is on and "permanent power mode" when the economy switch is off.

I think this is potentially a cool mod for the UK and Euro SVXes. However, one problem remains: How do we get the modified program into the TCU. If anybody has any bright ideas about that then I would like to hear them. There is a space laid out on the circuit board to add an EPROM socket. But what type of EPROM? Maybe the same 27C1028 type used by the ECU? And how do you tell the TCU to use the new one rather than the original one? There doesn't seem to be any obvious resistor to cut like on the ECU. Anybody know the answer to this? Or how to go about figuring it out? I really want to test this out.

[Hocrest]

Originally Posted by b3lha

Did UpNorth ever sort out the problems people were having with his adapters?

No, he didn't even ship the adapters to a number of people that paid for them

[mbtoloczko]

Originally Posted by b3lha

I'm making progress on figuring out the ECU, but there is still a lot of work to do. So far there's not really much worth posting about. If you can read assembler then you can see the latest progress at http://www.alcyone.org.uk/ssm/analys...-JDM-SVX-EG33/

I was talking to a tuner a while back and he said that we could do some tuning with what we already know about the ECU. He suggested setting the entire AFR map to 14.7:1 then hooking up a wide band and tweaking the MAF voltage to airflow map until the wideband is actually reading 14.7 all the way across the rev range. Having calibrated the ECU in this way, you can start tweaking the AFR map to make it leaner or richer as you require.

I didn't understood everything he was saying, but it sounded like a reasonable way to do it.

Did UpNorth ever sort out the problems people were having with his adapters?

Its not necessary to make the AFR map match the actual AFR. It sounds like a nifty idea, but in practice, it would be very hard to accomplish. No one does this in the Evo and STi tuning circles. Everyone just tunes AFR with a wideband hooked up, and makes incremental changes to the AFR map until the actual AFR reaches the desired value.

For basic tuning, all that's needed to get started is access to the AFR and timing maps. Subaru's are a bit difficult to tune timing because the ECU activily searches for the optimum timing. The best way to tune the timing is to zero out the correction table before tuning the timing, and then adding the correction values back after the tuning is complete.

[Dessertrunner]

I have failed to get onto UpNorth either. As regards the adapter he sent me I have not been able to get it to work so far. I have been busy with the 6 speed install so its delayed any progress so far. I hope to get back to it in a couple of days.
Not sure exactly how the ECU operates with the Air/Fuel, is it that the ECU reads the ratio then looks up a table and adjusts fuel based on that number?

[mbtoloczko]

Tony,

During low power cruise, the ECU operates in closed loop. It checks the afr using the O2 sensors, and adjust the fuel trims to keep the afr at 14.7:1. During "aggresive" driving, (anything more than 20 or 25% throttle on an SVX), the ECU flips into open loop mode. In open loop, it no longer tries to monitor the afr. It just adds fuel according to the fuel map. Fuel maps are typically presented as a table of afr values. These values really just represent injector pulse lengths.

[Dessertrunner]

Okay that all make sense, but when I have had a bad O2 sensor I have noted that the car doesn't accelerate smoothly. There for the ECU must be checking the sensor for some reason or have I total got it wrong.
Tony

[mbtoloczko]

Originally Posted by Dessertrunner

Okay that all make sense, but when I have had a bad O2 sensor I have noted that the car doesn't accelerate smoothly. There for the ECU must be checking the sensor for some reason or have I total got it wrong.
Tony

As long the car is less than 20-25% throttle, it will want to run in closed loop. If the car has a bad O2 sensor, then it will likely run in limp mode in that throttle range because it can't get a proper O2 reading. It might also run in limp mode at higher throttle positions. I'd have to look at the ROM code to see what its doing.

[Dessertrunner]

Have we made anymore progress or is it that everyone is just going to change the ECS to something like the Hydra that is being worked on.
Tony

[Nomake Wan]

Originally Posted by Dessertrunner

Have we made anymore progress or is it that everyone is just going to change the ECS to something like the Hydra that is being worked on.
Tony

Not everyone has that sort of cash, or the necessity. I'd say this project is probably still alive.

[b3lha]

Originally Posted by Dessertrunner

Have we made anymore progress or is it that everyone is just going to change the ECS to something like the Hydra that is being worked on.
Tony

I'm still working on it Tony. But I just haven't had much to report lately.

The current state of play is that for diagnostics we have the VWRX software working but it is not ideal. The JDash software is not far from working. The JDash guy kindly wrote some code for the SVX but I haven't had a chance to test it yet. From looking at it, I think it needs a few small tweaks.

As far as tuning goes, we know where the fuel, base timing, and advance maps are and maf scaling, and rev and speed limiters. So anyone with a suitable eprom programmer could probably start tuning their engine.

However once the ECU has taken the base values from it's maps, it tweaks them based on sensor inputs and learned values. I am currently trying to figure out this process so that we know what exactly what the ECU is doing and why. Otherwise there is no easy way to diagnose the problem if a modified map isn't working as expected.

[fooblahblah]

Originally Posted by b3lha

The current state of play is that for diagnostics we have the VWRX software working but it is not ideal. The JDash software is not far from working. The JDash guy kindly wrote some code for the SVX but I haven't had a chance to test it yet. From looking at it, I think it needs a few small tweaks.

I just discovered this thread a couple days ago and read through it start to current. Today I've been messing around with a trunk copy of JDash with my 92 USDM N/A SVX (in a Vanagon). I've been successful using Kevin Frank's SelectMonitor on Windows, but have not gotten JDash to work on my Linux laptop. I was trying to use a Keyspan USB->Serial converter. I'm gonna get rid of that and try using this cable I've used with Kevin's program in a couple minutes.

Are those SVX changes to JDash on the trunk?

Cheers,
-Jeff

[Calum]

If there was interest I could roll a version of my 'Realtime' board for the early Subbie ecus, but I don't think there is really a market. The Nissan and Subaru ECUs are so similar it really wouldn't require too many changes. It would let you do SSM and realtime memory changes all over the same USB connection, implemented with an FTDI chipset, so existing SSM programs (not that there are that many, lol) should work just fine. On the editing side it supports TunerProRT (and the emulator protocol is open if you want to roll your own software), so all you'd need is to build b3lha's discoveries into an XDF file.

But at $350-400 I just don't see many early 90s Subbie owners that interested.

[Dessertrunner]

Phil,
I have been flat out changing the gearbox in my car and fixing a head gasket in my wifes so I haven't got back to the reader. I have been thinking may be we need to build a SVX engine simulator. Suggesting we could use a PLC with different cards then drive the outputs and imputs to the ECU. That way we could get a more accurate start on the data.
What do you think would it be worth it? With out sounding stupid are we clear on what we don't know? And are we sure the tables are all correct?
Having some involvement with putting a different ECU on to a SVX I am inclined to stick to this one.
Calum are you saying the hardwere will cost $350-400?
Tony

[Calum]

Originally Posted by Dessertrunner

Phil,
I have been flat out changing the gearbox in my car and fixing a head gasket in my wifes so I haven't got back to the reader. I have been thinking may be we need to build a SVX engine simulator. Suggesting we could use a PLC with different cards then drive the outputs and imputs to the ECU. That way we could get a more accurate start on the data.
What do you think would it be worth it? With out sounding stupid are we clear on what we don't know? And are we sure the tables are all correct?
Having some involvement with putting a different ECU on to a SVX I am inclined to stick to this one.
Calum are you saying the hardwere will cost $350-400?
Tony

If your really interested in a bench simulator I've got a board for doing just that. Most of the sensors are dead easy (either resistance or voltage), but the tough part is getting the correct pulse train for the crank/cam etc senor(s). Those have to be 100% correct or the ecu won't operate properly. So you've got to either have a good set of o'scope shots from a running engine, or have the sensors on bench wired up. If your engine has a single sensor going the bench route is best. If your engine has two or more sensors that are physically timed together by the cam belt/chain/whatever then you pretty much have to do this on a running car. I do the actual pulse generation with a little mcu, so it gets programmed for each type of engine I'm simulating. Nissan didn't use Hall sensors for the cam/crank sensing (they did it all optically) so I didn't roll a front end for that, but if your engine uses Hall sensors you would need to concoct a little circuit to deal with that.

Building an engine simulator from scratch is beyond 99% of the people out there because you need the pulse patterns. Once you've got that worked out putting together a kit that most people can assemble is easy. If there happens to be an SVX near Lubbock TX (aka the middle of nowhere) I'd be happy to document the pulse patterns and post them up here.

Anywho, here's mine for doing Nissan B13/S13/RNN14/HP10s-





The little chip with the silver marking is what I actually program to set the correct pulse train. Its just a pic12F629 banging out the correct pattern in a constant loop, then I vary its clock to change the pattern speed (and so adjust the RPM of the 'engine'). The cheesy little multimeter on the side measures the current draw of the ecu. Thats a handy quick and dirty diagnostic for seeing if an ecu has problems. I know from memory what roughly all of the ECUs I work on should draw, so when I bench test a customers ecu I can tell withing a couple of seconds if the core is good or it has problems. The early 90s Nissan ecus in FWD vehicles were located right under the floor heater vent (what a great design, lol), so they tend to suffer water damage from condensation, especially from northern cars.

Yea, Realtimes run between $350-400. Exact pricing depends board size, etc. I install for free (and return shipping is free), and encourage people to let me do that. I would need to sell 5 to break even. I suspect that would be tough.

Here's what a Realtime board looks like. Lots of itty bitty surface mount stuff. I hand assemble each one. The cable you see at the top is a 6ft USB cable. fun stuff.

[svxistentialist]

Originally Posted by Calum

If there was interest I could roll a version of my 'Realtime' board for the early Subbie ecus, but I don't think there is really a market. The Nissan and Subaru ECUs are so similar it really wouldn't require too many changes. It would let you do SSM and realtime memory changes all over the same USB connection, implemented with an FTDI chipset, so existing SSM programs (not that there are that many, lol) should work just fine. On the editing side it supports TunerProRT (and the emulator protocol is open if you want to roll your own software), so all you'd need is to build b3lha's discoveries into an XDF file.

But at $350-400 I just don't see many early 90s Subbie owners that interested.

Originally Posted by Calum

Yea, Realtimes run between $350-400. Exact pricing depends board size, etc. I install for free (and return shipping is free), and encourage people to let me do that. I would need to sell 5 to break even. I suspect that would be tough.

Here's what a Realtime board looks like. Lots of itty bitty surface mount stuff. I hand assemble each one. The cable you see at the top is a 6ft USB cable. fun stuff.

Calum, I might be interested in this. Our tuner in England [Zen] can already address the ECU using software he has on a laptop, but explain what can be achieved using this board please. It might be beneficial for Phil's research, and I would like to see if it is a help with the TCU as I plan to keep the 4EAT in a modified form. I'm not a programmer or an engine tuner, so please tailor your description of its capabilities for a non-geek

Joe