Memory dump of ECU

[Nomake Wan]

hi all - just a note about the ECU communication - i have the same issue that nomake has reported where i read the ROM ID no problem, and the parameters start reading fine. however, it loses sync with the ECU and reads garbage (0's, -128's) for a few parameters, then regains sync, on and off.

here's what i hope is of use to you guys - yesterday i tried running a port monitor from sysinternals.com while running the vwrx software, and to my surprise whatever extra load (or buffering) on the port makes it stays sync'ed 80% of the time.

i have not tried building b3lha's "'92 problem" comparator yet. do you all think that is necessary even though the port monitor software seems to effect the problem?

The port monitor software is not a proper fix for the problem. All it does is adjust the output to what it "thinks" should be right and proper. As you yourself noticed, it's only 80% accurate. That's quite high, sure; I'm actually surprised. But the permanent and correct fix is to install the comparator. Do that and you will be 100% accurate 100% of the time without altering the output in software. :)

[b3lha]

The absolute best way to troubleshoot communications is with the Hex Com Tool.

Send a command eg. "78123400" and observe what the ECU sends back. It should be three bytes repeated over and over, the first two being the address and the last being the data. Something like "123400123400123400123400.....". If there is any corruption then you need the "92 problem" comparator board.

I haven't tried the port monitor software myself, so I can't comment on that.

The VWRX software is great, but it does have some bugs, which we can't fix without access to the source code. It does not seem to clear the input buffer when sending a new command, nor validate the data being returned. So if there is any data left in the buffer from the previous command then it assumes that is the reply from the current command.:rolleyes:

I also suspect that it polls the port rather than being interrupt driven. That means the program repeatedly asks the interface if there is any data available rather than the interface informing the program when data is received. Reading the data using polling can cause a loss of sync if the buffer overflows in between polls.

My linux software, while is isn't pretty or user-friendly, goes to a lot of trouble to ensure that the data returned is accurate.

[iiigoiii]

i actually got the idea for trying the port monitor from using hexcomm. i'd get back something like:
123400123400
1234
00123400
123400123400123400
so i thought it was just a formatting issue. then, while running something in the foreground, i saw a good pure:
12340012340012340012340012340012340012340012340012 3400123400
12340012340012340012340012340012340012340012340012 3400123400
coming out, leading me to thinking it was a CPU or buffering issue. that's when i tried portmon (a GREAT free tool btw: http://sysinternals.com) and saw the improvement.

i never saw corruption in the actual 123400 being returned, so thought the comparator might not be the issue....

[Nomake Wan]

i actually got the idea for trying the port monitor from using hexcomm. i'd get back something like:
123400123400
1234
00123400
123400123400123400
so i thought it was just a formatting issue. then, while running something in the foreground, i saw a good pure:
12340012340012340012340012340012340012340012340012 3400123400
12340012340012340012340012340012340012340012340012 3400123400
coming out, leading me to thinking it was a CPU or buffering issue. that's when i tried portmon (a GREAT free tool btw: http://sysinternals.com) and saw the improvement.

i never saw corruption in the actual 123400 being returned, so thought the comparator might not be the issue....

Ah, no no. Look back in this thread for the output I posted before and after the comparator. Or even the ones between idle and higher revs. If you have the 92 issue, you won't get that many "123400"s. ;)

[b3lha]

Yeah. Like Nomake said, you don't have the "92 problem" and you don't need the comparator. I reckon the issue you see is due to the serial input buffer overflowing in between being polled by the VWRX software. Presumably the portmon software is changing the port buffer settings in some way that helps. That's good to know.:)

You could also try messing with the registry values in HKLM\SYSTEM\CurrentControlSet\Services\Serial
technet reference page (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/33316.mspx?mfr=true)

[Calum]

Sorry if this is old hat, but I'm way behind on this thread and there's just too much to read. :P

Is there a windows tool for dumping the memory from a stock ecu yet? I'd rather not do the Linux stuff, just to save time.

[TomsSVX]

Sorry if this is old hat, but I'm way behind on this thread and there's just too much to read. :P

Is there a windows tool for dumping the memory from a stock ecu yet? I'd rather not do the Linux stuff, just to save time.

I have been waiting for it too, but nothing as far as I know

Tom

[Nomake Wan]

At the moment, there is no Windows application. However, there is a way to run Linux applications natively within Windows which you might want to check out.

http://www.ulteo.com/home/en/home?autolang=en

[b3lha]

I don't have any experience at writing software for Windows. Only DOS, Unix, IBM Mainframes and Telco equipment.

That ulteo thing looks interesting. Please let me know if it works. I tried to compile the ecudump software under cygwin once but it seemed to be missing some libraries.

[b3lha]

Hey Joe, did you get the chance to try out that TCU yet, or is it on hold until you fix the Jersery Girl?

[svxistentialist]

Phil, I may actually get a chance over the next few weeks, but the gearbox problem has to be a priority.

The main problem I face could be that all clutch friction material may have a tenuous grip on the metal parts, and more driving will remove more material.
[As a consequence of the water mixing with the ATF]

If it is the case that the brake band was out of tension and needed adjustment, and that the friction material still remains on the band, then my problem may only be one of adjustment. That's what I'm hoping. :rolleyes:

My initial plan is to replace the fluid this weekend, check the filter in the sump while doing so, and adjust the band. If that works and gives me all four gears, then I am good to go :).

As I'm sure you realise, testing the remapped TCU while having these physical problems with the transmission will not give us any kind of reliable comparison.

Fingers crossed.

Joe :)

[Calum]

I don't have any experience at writing software for Windows. Only DOS, Unix, IBM Mainframes and Telco equipment.

That ulteo thing looks interesting. Please let me know if it works. I tried to compile the ecudump software under cygwin once but it seemed to be missing some libraries.

I worked my way through undergrad as a IBM system/390 night operator.

I'll hack together a little vb.net utility. With MS Express its free and easy to do little stuff like this.

[b3lha]

Having read about Harvey's new gadget I started looking at how the solenoid A duty cycle gets generated by the TCU. The QC shift kit, as I understand it, generates a duty cycle that is proportional to the throttle opening.

I haven't managed to figure it all out yet, because there are still lots of unknown variables in the code. But it looks like the TCU also bases the sol A duty cycle on the throttle opening.

For a USDM TCU, the function in question starts at location EBAA in the TCU code.

At location EC49, it selects a map, based on the gear that the transmission is currently in. A different map is used depending on whether the car is in 1st, 2nd, 3rd or 4th. The maps describe a graph using the straight line formula y=mx+c and each map has up to 6 segments.

For example: The map for 2nd gear is stored at 0xCABE and it looks like this:

1F 3E 2580
3F 4B 23F0
5F 0C 3390
7F 0C 3390
BF 03 3840
FF 19 27D8

The first byte is X, the throttle signal as a proportion. 00 is closed, FF is full. The second byte is M, the gradient of the line. The third and 4th bytes are a 16 bit word representing C, the Y offset of the line. Converted from hex to decimal it looks like this:

012% 62 9600
025% 75 9200
037% 12 13200
075% 03 14400
100% 25 10200

This means from 0 to 12% throttle, the duty cycle is ( 62 x throttle ) + 9600. From 12% to 25% it is ( 75 x throttle ) + 9200. To convert the result Y to a percentage, you divide it by 200. I have plotted the duty cycle versus throttle opening graphs for each gear.

http://www.alcyone.org.uk/ssm/tcu/solAduty.jpg

But there is more to it that I haven't analysed yet. For vehicles fitted with an atmospheric pressure sensor (USDM and any others with the 2nd byte of the ROM ID less than 55), the TCU subtracts a correction value based on the atmospheric pressure and throttle opening. Then later it adds a correction based on the current gear and vehicle speed.

Then there is the question of how the TCU calculates the duty cycle to reduce the line pressure during gear changes. I don't know yet.

It seems to me that a similar effect to Harvey's QC could be achieved in software by simply modifying the data in these maps to change the shape of the graphs. Obviously a lot more analysis is required before any kind of TCU mod could be developed. When I'm a little less busy, I'm going to use my TCUSCAN program to log the duty cycle and throttle opening values on my car and try to reconcile them with the graph to make sure I'm on the right track.

[Trevor]

Having read about Harvey's new gadget I started looking at how the solenoid A duty cycle gets generated by the TCU. The QC shift kit, as I understand it, generates a duty cycle that is proportional to the throttle opening.


Unfortunately the "QC" does not alter the duty cycle. Throttle position is simply used as an on/off function. The circuitry simply drastically reduces or defeats the total duty cycle signal. There is no variable function involved.

There is also a gross misunderstanding recorded within the description of the gadget, regarding the effect of throttle position. This is in no way association with the signal delivered via the resistor. The TPS signal is normally processed and the duty cycle to solenoid A modified in accordance with total requirements, including gear shifting. (P.S. and throttle position.
Quote -- "But it looks like the TCU also bases the sol A duty cycle on the throttle opening.")

[b3lha]

Check this out! A guy from UKLegacy alerted me to it. A nice diagnostics and datalogging program for Windows that supposedly works with the SVX and other Subarus. :D Unfortunately it's not free, but it is cheap. I haven't tried it yet, but I certainly plan to have a look at it.

http://www.limitless.co.nz/

http://www.limitless.co.nz/EvoScan/images/CoolGaugeLayout.gif

I can't help wondering if they borrowed some of our research for this. I don't see how else they could find the memory locations for the SVX without having access to an SVX to experiment with.;)

[Dessertrunner]

Looks interesting are you going to buy a unit?

[mbtoloczko]

Check this out! A guy from UKLegacy alerted me to it. A nice diagnostics and datalogging program for Windows that supposedly works with the SVX and other Subarus. :D Unfortunately it's not free, but it is cheap. I haven't tried it yet, but I certainly plan to have a look at it.

http://www.limitless.co.nz/

I can't help wondering if they borrowed some of our research for this. I don't see how else they could find the memory locations for the SVX without having access to an SVX to experiment with.;)

I've been using EvoScan with my Evo for about 1.5 years. I had been watching to see when he would add support for the SVX. Since EvoScan simply follows the SSM protocol, I doubt Hamish (EvoScan author) needed to see the guts of the SVX ECU. SSM I'm sure has a standard set of addresses it uses to read key operating parameters so it can work for any SSM-enabled Subaru. He probably doesn't even know if it really works with an SVX. He's just assuming that since the SVX uses SSM, EvoScan will work. What I'm curious about is the cable he sells for the SVX. I see that he sells a cable with a 9-pin plug. Is there a 9-pin SSM plug somewhere on the SVX? Its been too long for me to remember. All I remember were some diagnostic wires that had to be pulled and inserted into specific plugs to read error codes.

If you want to make the disassembly and ROM modification process easier and more accessible, I'm pretty sure that ECUFlash (free) can be used to read and modify the maps in the SVX ROM. You'll need to create definition file (XML-based) that defines the location of each map and the scaling of the values for the maps. You'll also need to find the unique identifier in each type of SVX ROM so that ECUFlash can differentiate between the various SVX ROMs. Here a link to the ECUFlash download:

http://www.openecu.org/index.php?title=EcuFlash

[longassname]

Actually the memory locations are not standard. That's why the select monitor needs a different cartridge for each model or the mega cartridge that has the locations for all the models on it.

The hardware designs suggested in the thread so far aren't quite up to snuff so if that cable does work correctly it could be very useful for those trying to work on this project.

While I'm being helpful I would like to make a correction to something said earlier in this thread so that nobody thinks it's ok to steal my tuning--I'm not especially thrilled when people use it to find rom locations but I understand some temptations are too great the resist. Using my actual tuning is another thing entirely.

It's long stood that unless explicity aggreed to in a terms of use aggreement that a user/owner of software can modify it to expand it's abilities or change it's abilities. When someone buys say a stage 1 from me they are buying a piece of hardware that allows the modification of the software on the ecu, the use of two tunes that can switched between, and a new tuning which expands the abilities of Subaru's original software. The sale of my product does not cause econic harm to Subaru by competing against them. What I am doing has long stood as legal in both US and international copyright precedent.

Now, if someone reads a copy of my software and then sells it in competition against me, or copies my software and further modifies it and then sells it in competion with me, or copies my software and uses the information learned from it to develop a competing product with reduced development costs...those actions have long stood as lillegal in both US and international copyright law.

I do have a masters degree in information systems so I have more knowledge about these things than most. To greatly simplify it for others there is a simple rule you can use to determine if you are in copyright violation. If your use of something someone has written causes them economic harm you are violating their copyright.

[SVXRide]

Michael,
Nicely stated.
-Bill

[Dessertrunner]

The Select Monitor Cartiage is marked
- 97 Legacy Impreza SVX E12 ViVIO,

Does each of these cars have a different memory address for the engine parmentors?
Tony

[mbtoloczko]

Is there a copy of a stock ROM file around somewhere, preferably a USDM one?

[Speedklix]

The Select Monitor Cartiage is marked
- 97 Legacy Impreza SVX E12 ViVIO,

Does each of these cars have a different memory address for the engine parmentors?
Tony

wow, that is very strange.
Great for me! but still very confusing, i guess i'll learn why soon

[genzzel]

Well--I am going to get a cable seeing how never got the other one I paid for--Thank the Lord someone is making one.:D:D

[b3lha]

Looks interesting are you going to buy a unit?
I'm thinking of buying a copy of the software. But first I've emailed him asking for more information about it.

Since EvoScan simply follows the SSM protocol, I doubt Hamish (EvoScan author) needed to see the guts of the SVX ECU. SSM I'm sure has a standard set of addresses it uses to read key operating parameters so it can work for any SSM-enabled Subaru.

No. The locations are not standard. They are different for each type of ECU. Either he had access to an SVX ECU, or our research, or maybe the locations have to be configured by the user of the software.

What I'm curious about is the cable he sells for the SVX. I see that he sells a cable with a 9-pin plug. Is there a 9-pin SSM plug somewhere on the SVX?

Yes. The yellow SSM plug in the driver's kick panel. Our latest cable design works perfectly. I read somewhere that the cable he is selling is just an FTDI USB-TTL cable with a Legacy Radio Harness soldered on the end. Just like the one Nomake Wan was using. It will need the upgrade board in order to work on cars with the "92 problem".

If you want to make the disassembly and ROM modification process easier and more accessible, I'm pretty sure that ECUFlash (free) can be used to read and modify the maps in the SVX ROM.

The whole goal of this project is to make it more accessible. :) ECUflash doesn't work on the older JECS OBD1 ECU like ours. It would be interesting to see if it would work on the newer OBD2 ECU. I've never had the chance to examine an OBD2 ECU.
Is there a copy of a stock ROM file around somewhere, preferably a USDM one?
On my website. http://www.alcyone.org.uk/ssm/roms/ There is also an definition file for Enginuity/RomRaider that might help make sense of it. The website is long overdue for an update.

Does each of these cars have a different memory address for the engine parmentors?

Yes.
Well--I am going to get a cable seeing how never got the other one I paid for--Thank the Lord someone is making one.:D:D
If I knew there was a demand I would have made some. I had two units for sale before and people didn't exactly snap them up.

[b3lha]

While I'm being helpful I would like to make a correction to something said earlier in this thread so that nobody thinks it's ok to steal my tuning--I'm not especially thrilled when people use it to find rom locations but I understand some temptations are too great the resist. Using my actual tuning is another thing entirely.

It's long stood that unless explicity aggreed to in a terms of use aggreement that a user/owner of software can modify it to expand it's abilities or change it's abilities. When someone buys say a stage 1 from me they are buying a piece of hardware that allows the modification of the software on the ecu, the use of two tunes that can switched between, and a new tuning which expands the abilities of Subaru's original software. The sale of my product does not cause econic harm to Subaru by competing against them. What I am doing has long stood as legal in both US and international copyright precedent.

Now, if someone reads a copy of my software and then sells it in competition against me, or copies my software and further modifies it and then sells it in competion with me, or copies my software and uses the information learned from it to develop a competing product with reduced development costs...those actions have long stood as lillegal in both US and international copyright law.

I do have a masters degree in information systems so I have more knowledge about these things than most. To greatly simplify it for others there is a simple rule you can use to determine if you are in copyright violation. If your use of something someone has written causes them economic harm you are violating their copyright.

Micheal, you are the established guru in this area and your help and insight is always appreciated. I welcome any contribution you have to make. :)

As mentioned at least once in this thread. Nobody here has any intention of competing with you or stealing your hard work. I am not selling bootleg copies of your ECUtune chips and I have not heard of anybody else doing so. There was an unsubstantiated allegation about Budfreak wanting to do that, but I doubt that he has the expertise to do so on his own and I am certainly not going to help him. :rolleyes:

I resent your accusation that I may have looked at your work to find variable locations. I assure you this is absolutely not the case. As a professional computer geek, I am perfectly capable of finding them myself. To give credit where it is due, I have learned a lot from reading the various threads that you have posted here about your work. I always enjoy reading your technical discussions.:)

I am not an expert on US or International copyright law, but I disagree with your interpretation. The amount of "economic harm" does not change the legality. Although it may affect whether the copyright owner decides to sue the infringer and how much damages are claimed.

I also do not believe that it is "your software", unless you are claiming to have entirely rewritten it from scratch. We both know that would be very hard to do and therefore I believe that you are distributing Subaru's software, with a few changes. You cannot legally buy a book, change a couple of pages and then claim copyright over the whole book and sell it as your own work.

At best you can claim ownership over the bytes you have changed, but even that is tenuous because the fuel and timing maps are not a creative work. They are control parameters for the engine. The same values could be arrived at independantly by other tuners trying to acheive the same state of tune. If several tuners were asked to find the optimum tuning for an SVX engine, they would probably all come up with similar values.

If I decided to raise my rev limiter to 7400, would that mean that I copied part of your work? Or does it just mean that I think 7400 is an optimum value for the rev limit. Do you think that you should be the only person allowed to set the rev limit to 7400? Maybe I should stake a claim to values from 6800 through 7350?:lol: OK. I'm being silly now. But the point I am trying to make is that it is hard to claim valid ownership of control parameters.

Regardless, this discussion is pointless. As already stated, I have no intention of ripping off your work, and nor do any of the other contributors to this thread. My repeated advice to anyone wanting an off-the-shelf tuning product is to go and buy one from Longassname. The research we are doing in this thread is simply intended to make it easier for people who want to mod their own ECU and TCU to their own requirements.

Phil.

[longassname]

Hello Phil,

That's all I was trying to clear up. From everything I was taught in several graduate courses the view you had expressed earlier and just did again on software copyright is dead wrong. It's also contrary to the legal opinion that was given to me when incorporating ECUtune.


I am not selling the Subaru software. As the owners of SVX ecu's my customers already own the Subaru software. I am selling modifications to the software and hardware which enables those modifications and multiple tunes. If this was an OBDII engine management system then I would be selling a flash dongle which applied the changes without rewriting the Subaru software; however, since it is an OBDI system the base code and modifications must be packaged together. This isn't a problem since in order to use it you must actually already own an SVX ECU.

I very certainly can claim copyright on my modifications. That does not mean that if one were to figure out where the rev limit data is stored on their own and wanted to change that data to equal 7400 rpms and figure out how to do so on their own that they could not do so. It does mean that someone could not use my software to figure out the location, and or what to change the data to, and then do so.

So anyway..the rule of thumb I gave before isn't mine; it's not something I made up. It's an accepted rule of thumb. You may note that in the examples you gave that were supposed to sound rediculous they did not meet the rule of thumb because they did not involve the use of someone elses work. If your use of someone elses work causes them financial harm then you are violating their copyright. If your completely independent work produces the same results of someone else you haven't used their work and haven't met the rule of thumb.

The reason I am trying to make this clear is because while you may do your own work I am not as confident as you that nobody else will use your work to steal my work. They should know that if they do so...whether they sell my work or email it to people for free, or post it for others to have for free they will be liable for all financial losses I might ever suffer as a result.



Micheal, you are the established guru in this area and your help and insight is always appreciated. I welcome any contribution you have to make. :)

As mentioned at least once in this thread. Nobody here has any intention of competing with you or stealing your hard work. I am not selling bootleg copies of your ECUtune chips and I have not heard of anybody else doing so. There was an unsubstantiated allegation about Budfreak wanting to do that, but I doubt that he has the expertise to do so on his own and I am certainly not going to help him. :rolleyes:

I resent your accusation that I may have looked at your work to find variable locations. I assure you this is absolutely not the case. As a professional computer geek, I am perfectly capable of finding them myself. To give credit where it is due, I have learned a lot from reading the various threads that you have posted here about your work. I always enjoy reading your technical discussions.:)

I am not an expert on US or International copyright law, but I disagree with your interpretation. The amount of "economic harm" does not change the legality. Although it may affect whether the copyright owner decides to sue the infringer and how much damages are claimed.

I also do not believe that it is "your software", unless you are claiming to have entirely rewritten it from scratch. We both know that would be very hard to do and therefore I believe that you are distributing Subaru's software, with a few changes. You cannot legally buy a book, change a couple of pages and then claim copyright over the whole book and sell it as your own work.

At best you can claim ownership over the bytes you have changed, but even that is tenuous because the fuel and timing maps are not a creative work. They are control parameters for the engine. The same values could be arrived at independantly by other tuners trying to acheive the same state of tune. If several tuners were asked to find the optimum tuning for an SVX engine, they would probably all come up with similar values.

If I decided to raise my rev limiter to 7400, would that mean that I copied part of your work? Or does it just mean that I think 7400 is an optimum value for the rev limit. Do you think that you should be the only person allowed to set the rev limit to 7400? Maybe I should stake a claim to values from 6800 through 7350?:lol: OK. I'm being silly now. But the point I am trying to make is that it is hard to claim valid ownership of control parameters.

Regardless, this discussion is pointless. As already stated, I have no intention of ripping off your work, and nor do any of the other contributors to this thread. My repeated advice to anyone wanting an off-the-shelf tuning product is to go and buy one from Longassname. The research we are doing in this thread is simply intended to make it easier for people who want to mod their own ECU and TCU to their own requirements.

Phil.

[b3lha]

Hello Phil,

That's all I was trying to clear up. From everything I was taught in several graduate courses the view you had expressed earlier and just did again on software copyright is dead wrong. It's also contrary to the legal opinion that was given to me when incorporating ECUtune.


I am not selling the Subaru software. As the owners of SVX ecu's my customers already own the Subaru software. I am selling modifications to the software and hardware which enables those modifications and multiple tunes. If this was an OBDII engine management system then I would be selling a flash dongle which applied the changes without rewriting the Subaru software; however, since it is an OBDI system the base code and modifications must be packaged together. This isn't a problem since in order to use it you must actually already own an SVX ECU.

I very certainly can claim copyright on my modifications. That does not mean that if one were to figure out where the rev limit data is stored on their own and wanted to change that data to equal 7400 rpms and figure out how to do so on their own that they could not do so. It does mean that someone could not use my software to figure out the location, and or what to change the data to, and then do so.

So anyway..the rule of thumb I gave before isn't mine; it's not something I made up. It's an accepted rule of thumb. You may note that in the examples you gave that were supposed to sound rediculous they did not meet the rule of thumb because they did not involve the use of someone elses work. If your use of someone elses work causes them financial harm then you are violating their copyright. If your completely independent work produces the same results of someone else you haven't used their work and haven't met the rule of thumb.

The reason I am trying to make this clear is because while you may do your own work I am not as confident as you that nobody else will use your work to steal my work. They should know that if they do so...whether they sell my work or email it to people for free, or post it for others to have for free they will be liable for all financial losses I might ever suffer as a result.

OK Michael,

We agree that the modifications you make to Subaru's software belong to you. If I hear of anybody distributing copies or derivatives of your work then I will inform you and you can put your legal theory to the test. I really hope that the members of this community have enough integrity not to steal your work. :)

I am not in the tuning business and I have no commercial interest in this. It's just a hobby for me. Any information I uncover, or modified eproms that I make will be posted on my website for others to use as they please. But it is all strictly experimental and it comes with no warranty whatsoever. I am well aware that throughout the course of this thread I have already posted a certain amount of erroneous information but that is the nature of experimental work and I'm trying to correct it as I go along.

Phil.

[racerx9146]

Longassname

I purchased your product and think it is very good and reasonably priced.

But this complaint/protest sounds like sour grapes. Have you sold your product to anybody on this list and have you any evidence they have dumped the rom and used the info?

I cant see how this complaint will do anything but generate negative press for you. If you have a legit complaint file a claim.

[Mrdjc]

Hi all, I've been trying to get SSM to work on my 1996 Legacy Sedan.

I stumbled across Phil's page a number of times during my search, and have managed to piece together most of the hardware as well as trying to troubleshoot.

Currently I am using a FTDI USB-RS232 TTL 5.0V Adapter
Along with Phil's "92 Fix" Adapted for the FTDI Lead to try and sort out the problem of a dodgey connection.
Connected up to an Audioleads ISO plug.

I have tried using various bits of software but there aren't many out there that support SSM. At the moment I am using Evoscan, their latest release is the best yet (In terms of stability for me.) But its still far from perfect.
With the VWRX Monitor software, I get random results, and values seem to appear and dissapear when I run the SelectMonitor Dump software.
It will make a pass through an address, a value will come up, then it makes another pass (I.e. it polls it again) and the value is suddenly 0 until I close the program and restart it.

Anyhow, I've been in touch with Phil via email, trying to work out what is causing all this.
So he referred me to Nomake Wan's post about RS232 Hex Comm Tool. No matter how I adjust the Potentiometer on the "92 Fix" board.
I still cant get a clear run of 123400.
There are errors in the way the data comes back, which appear to follow a pattern.
At first I suspected something on my laptop was interfering, so I closed down the only other Com port (my modem), and got PortMon as suggested by someone earlier in this thread.
There is nothing else using the com port.

Can anyone please help me? :confused:
I'm on my second "92 fix" board, with the same results. I am about to send the first one to a friend who also uses the FTDI Lead, to see if he has any luck.

Please take a look at the schematic of the 92 fix for FTDI
And also enclosed is a small Dump from the RS232 Program to show you what data I get back.

Regards,
Daniel.

P.s. If I can get all of this to work properly, I have looked into producing these kits all tidied away in a little box with USB at one end and J35 Plug on the other end. It would be between £35-£40 per lead, if I get demand for more than 10.

[b3lha]

Hi all, I've been trying to get SSM to work on my 1996 Legacy Sedan.

I stumbled across Phil's page a number of times during my search, and have managed to piece together most of the hardware as well as trying to troubleshoot.

Currently I am using a FTDI USB-RS232 TTL 5.0V Adapter
Along with Phil's "92 Fix" Adapted for the FTDI Lead to try and sort out the problem of a dodgey connection.
Connected up to an Audioleads ISO plug.

I have tried using various bits of software but there aren't many out there that support SSM. At the moment I am using Evoscan, their latest release is the best yet (In terms of stability for me.) But its still far from perfect.
With the VWRX Monitor software, I get random results, and values seem to appear and dissapear when I run the SelectMonitor Dump software.
It will make a pass through an address, a value will come up, then it makes another pass (I.e. it polls it again) and the value is suddenly 0 until I close the program and restart it.

Anyhow, I've been in touch with Phil via email, trying to work out what is causing all this.
So he referred me to Nomake Wan's post about RS232 Hex Comm Tool. No matter how I adjust the Potentiometer on the "92 Fix" board.
I still cant get a clear run of 123400.
There are errors in the way the data comes back, which appear to follow a pattern.
At first I suspected something on my laptop was interfering, so I closed down the only other Com port (my modem), and got PortMon as suggested by someone earlier in this thread.
There is nothing else using the com port.

Can anyone please help me? :confused:
I'm on my second "92 fix" board, with the same results. I am about to send the first one to a friend who also uses the FTDI Lead, to see if he has any luck.

Please take a look at the schematic of the 92 fix for FTDI
And also enclosed is a small Dump from the RS232 Program to show you what data I get back.

Regards,
Daniel.

P.s. If I can get all of this to work properly, I have looked into producing these kits all tidied away in a little box with USB at one end and J35 Plug on the other end. It would be between £35-£40 per lead, if I get demand for more than 10.

Hi Daniel,
That dump file looks good to me. 123400 repeated over and over with no corruption. Am I missing something?
The one you sent me before showed a problem, but this one looks OK.
Phil.

[Mrdjc]

Isn't it meant to come back formatted perfectly?

Like...

123400123400
123400123400
123400123400
123400123400
123400123400


And not...


123400123400
12340012340012
340012340012
340012340012
340012340012
340012340012
34001234001234
0012340012
34001234001234
001234001234
001234001234
001234001234
001234001234
00123400123400
123400123400


I'm still having issues with VWRX Dump loosing values at random.

Cheers,
Daniel.

[b3lha]

No the formatting is just a side effect of the hex com tool. The numbers are all that is important.

As you seem to be getting good data back now, all the available software should work.

Just to double-check, try querying a non-zero value in the ROM and ensure that it comes back consistantly. Like location 8120 (enter 78812000). That's the first byte of the fuel map. On my Legacy the value is 8A.

The VWRX SelectMonitor software will only give you meaningfull values if the addresses in the SelectMonitor.ini file are correct for your ECU. Even then it can be a little bit buggy at times. I would expect the SelectMonitorDump program to work though. Does it read your ROM ID correctly?

[Mrdjc]

Right if I try that.. I get...

TX>78812000<TX
812081812081
81208181208181
208181208181
208181208181
208181208181
208181208181
20818120818120
8181208181


I don't get a ROM ID from VWRX at all. If I only select battery voltage to poll (1335) I'll get 0, 12.16, 0, 0, 0, 12.16, 0, 0, 12.16, 12.16 (it just flickers back and forth on/off)

Try it in RS232 Comm Tool (1335)


TX>78133500<TX
133598133598
13359813359813
359813359813
359813359813
359813359813
359813359813
35981335981335
981335981335


My ECU ID in Evoscan is...
ECU ID: 742FA1

Any other suggestions?

How do you go about figuring out the addresses? (Especially since the dump tool doesn't work!) Wish there was some magic program that would go through the entire range and figure it all out for me!

Phil, Do you have MSN/Yahoo or Skype messenger? Might be worthwhile sitting here and trying things. (I'm in my car right now.)

Cheers,
Daniel.

[b3lha]

Right if I try that.. I get...

TX>78812000<TX
812081812081
81208181208181
208181208181
208181208181
208181208181
208181208181
20818120818120
8181208181


Looks reasonable. I would say your hardware is working correctly.

I don't get a ROM ID from VWRX at all. If I only select battery voltage to poll (1335) I'll get 0, 12.16, 0, 0, 0, 12.16, 0, 0, 12.16, 12.16 (it just flickers back and forth on/off)

Try it in RS232 Comm Tool (1335)


TX>78133500<TX
133598133598
13359813359813
359813359813
359813359813
359813359813
359813359813
35981335981335
981335981335


The Hex Com Tool shows that the ECU is consistantly returning a value of 98 hex, which is 12.16 volts. Sounds about right. I don't know why the VWRX program would report anything else. It may be worth emailing Kevin or asking via the forum on his site.

My ECU ID in Evoscan is...
ECU ID: 742FA1

That ECU ID looks reasonable. It is similar to the one from my Legacy (7432A1). It looks like Evoscan is also reading good data.

How do you go about figuring out the addresses? (Especially since the dump tool doesn't work!) Wish there was some magic program that would go through the entire range and figure it all out for me!

Yeah. If only such a tool existed. The only way to accurately find the values is to reverse-engineer the program code. You need to be a computer geek with assembly language skills and a lot of spare time.
Some of the locations on my Legacy ECU match the ones for ROMID 7332xx in the VWRX SelectMonitor.ini file, so you could try those. It may be worth talking to Vikash (vrg3) on the LegacyCentral website. He has done a lot of work on decoding the Legacy ECU.

Phil, Do you have MSN/Yahoo or Skype messenger? Might be worthwhile sitting here and trying things. (I'm in my car right now.)

Sorry, I don't have any kind of Instant Messenger set up at work.

[b3lha]

I've been talking to Hamish, the Evoscan guy. He can extract the parameter addresses from his subaru select monitor. Given the ECU ID, he can pull out the correct parameter addresses.

[b3lha]

Daniel,

SVXed just pointed out to me that Kevin released a new version of the VWRX software in July 2008. He has added the useful ability to log data to a file. The older version that I was using can't do that.

But Ed is getting false data from it just like you are, there seems to be a problem with the VWRX software and the FTDI cables. I am going to try the new version on my car with my RS232 cable and see whether it works for me.


Note on Future Software Plans: Optimize use with the FTDI USB to Serial converter cable. As it is, there are reports of this converter working but the results from the ECU are somewhat inconsistent. The software most likely needs to be fine tuned for best results with this device. Your donations are appreciate!


Phil.

[Mrdjc]

Phil,
I must have the same version in that case.
I sent an email to vgr3 Vikash from Legacy Central, asking how he found the parameter addresses, and if he was prepared to share them with us.

It would be good if a list could be compiled (Similar to the Selectmonitor.ini file from Kevins VWRX Software) Showing ECU ID's alongside known parameters.

I take it Hamish from Evoscan has all the Subaru Cartridges in that case?

I'm just wondering if anyone else on this forum in the UK is interested in a cable Kit? So far I have three people interested over at UKLegacy.com Once I have 10 I can order up the bits and make them. (It's a fair bit of capital to invest if you don't get a return!)
The kits would consist of USB-TTL, 92 Fix and ISO Harness. All tidied away nicely into a small box. They would go for between £35-£40 with postage included.

Regards,
Daniel.

[longassname]

You actually had a schematic of a much better hardware interface earlier on. Using an opamp comparator you are removing hysteresis. You want to do the opposite. The better schematic you had posted showed a shmitt trigger. I think that was Kashima's. That design will adjust the input to trigger on the correct signaling level and maintain hysteresis. In actuality you shouldn't need either. It's not a bad ttl signal. The voltage levels are what they are on purpose. The best thing to do is use the correct generation line driver/buffer/gate to match the signal.

[b3lha]

You actually had a schematic of a much better hardware interface earlier on. Using an opamp comparator you are removing hysteresis. You want to do the opposite. The better schematic you had posted showed a shmitt trigger. I think that was Kashima's. That design will adjust the input to trigger on the correct signaling level and maintain hysteresis. In actuality you shouldn't need either. It's not a bad ttl signal. The voltage levels are what they are on purpose. The best thing to do is use the correct generation line driver/buffer/gate to match the signal.

Thanks Michael. That's very interesting information. :)

I know what a schmitt trigger does and I know what hysteresis means. But I am not 100% clear what you are saying. :confused: Could you explain further?

Kashima's original design didn't have any kind of comparator, it was just a max232 and a voltage regulator. It worked great on my 94 SVX and my Legacy. But it picked up bad signal from my 92 SVX and several others.

Then Calum showed us the comparator circuit and so far that seems to work perfectly on all the cars we have tried it with. On my problem car, I can let it run for 3 hours downloading the ROM and every byte of that 32K is perfect.

However, if you have an even better design to contribute then I'll be happy to build it and try it out.

[b3lha]

I did some testing.

There is definitely a problem with the VWRX software returning incorrect data. The older version does it too, even with an RS232 interface. I have checked with the hex com tool and the serial port is getting the correct data, but the program is displaying zeroes every few reads.

I'll email Kevin about it and see whether he can fix it.

[b3lha]

I found this:

http://www.rensu.net/index.php?valikko=RXL&sivu=lataa_select_monitor

It is a Select Monitor tool for Polaris snowmobiles. Their engines are built by FHI and their ECUs use the Subaru protocol just like ours.

The gauges don't mean anything because the parameter locations are different. But it has the ability to download the ECU ROM to a file - and that works 100%.

So now we have a way to download the ROM without needing to run Linux.

[TomsSVX]

I found this:

http://www.rensu.net/index.php?valikko=RXL&sivu=lataa_select_monitor

It is a Select Monitor tool for Polaris snowmobiles. Their engines are built by FHI and their ECUs use the Subaru protocol just like ours.

The gauges don't mean anything because the parameter locations are different. But it has the ability to download the ECU ROM to a file - and that works 100%.

So now we have a way to download the ROM without needing to run Linux.


I may need to fire up the old laptop...:) thanks

Tom

[TomsSVX]

well just dled the program and I am running it on my desktop... Cable is just long enough to reach the car... lets see what I can come up with

Tom

[TomsSVX]

depending upon how things go, I am going to be in the market for a decent writer/eraser. I have a couple stock ROMS around that can be erased so I would rather do some testing with them rather than buying/building adapter boards. Let me know if any of you have one you would like to sell or if you can point me in the direction of some good products...

Tom

[TomsSVX]

I have access to a couple OBDII cars... I might try and see if I can get into them

Tom

[TomsSVX]

Ok I was able to DL the ROM using the new software Phil posted... BUT i have no way of opening it. I also went ahead and dowloaded the Evoscan and purchased their cable considering I cannot use the com1 port for some reason:confused: It will only allow me to use their cable?? Has anyone else tried using this program yet??

Tom

[TomsSVX]

Ok, trying to use RomRaider to get the dump visible it is giving me error codes saying "content is not allowed in prolog" What steps should I take from here??

Tom

[TomsSVX]

Ok i did some searching on RomRaider's forum and dug up Upnorth's old posts. I was able to load his 92 dump and your 92 dump. I am still unable to load the 94 dump from your site or the dump I took off a 94 here today... Says the ROM definition is not found. Any help would be greatly appreciated

Tom

[b3lha]

Ok i did some searching on RomRaider's forum and dug up Upnorth's old posts. I was able to load his 92 dump and your 92 dump. I am still unable to load the 94 dump from your site or the dump I took off a 94 here today... Says the ROM definition is not found. Any help would be greatly appreciated

Tom

Hi Tom,

Good work!

Please email me the ROM you downloaded and I'll have a look and see why it's not opening. I'll PM you my email address.

[TomsSVX]

Thanks Phil, been waiting on a VERY late delivery for the last couple days and figured I would jump on board while I have the spare time... Problem is, now you have really caught my interest, so lets see where this takes us

Tom

[b3lha]

I had a look at the ROM file.

I've been working with 64K files, so that the addresses match up properly in the disassembly. I wrote the Enginuity/Rom Raider definitions on that basis and I should really fix them to work with the 32K files from the Snowmobile program.

The temporary solution is to preprend 32K of anything to the start of the file, or just copy the file after itself.

In Windows, open CMD.EXE and type

copy /b HEXDUMP.HEX + HEXDUMP.HEX NEW.HEX

and that should get you a 64K file called NEW.HEX that will open in Rom Raider.

[TomsSVX]

got the returned file to Open in RomRaider no problem... Looks like there are absolutely no differences in graphs when comparing the 92 ECU to the 94 I dumped:rolleyes:

Tom

[Tim]

I'm jumping in on this bandwagon too :D

[b3lha]

depending upon how things go, I am going to be in the market for a decent writer/eraser. I have a couple stock ROMS around that can be erased so I would rather do some testing with them rather than buying/building adapter boards. Let me know if any of you have one you would like to sell or if you can point me in the direction of some good products...

Tom

Let me know if you can't find an affordable writer for the stock chips.

I have two spare adapter boards to sell at cost price. But I need to go back and check my records to see what they cost me.

[genzzel]

:confused: Got the EvoScan cable and software. Fired everything up and seems to com well, but addresses(request) seems wrong--rpm not htere, batt shows 20 all the time, speedo is on 20 and coolant is -41C. Can not get much else. Not real sure how to use, but did notice each line is able to be edited. I am guessing i need correct requests--can anyone help me out??? It returns ECU 742522. Here are requests that are there with function:
Batt voltage 1335 x *0.08 volts
veh speed 1336 x *2 kmph
engine speed 1338 x *25 rpm
coolant temp 1337 x -50 degC
ing adv 1053 deg BTDC
airflow 1308 x *5/256 volts
engine load 1305
throttle pos 1329 x*5/256 volts
inj pulse 1306 x*256/1000 ms
ISU duty 1307 x*100/256 %DC
O2 avg 130A x*5000/512 mV
O2 min 0000 x*5000/256 mV
O2 max 0001 x5000/256 mV
knock corr 1054 deg
air/fuel corr 1055 x-128 %
atom press 1340 x*8 mmHg
manifold press 1341 (x-128)/85 bar


Please help----kevin

[b3lha]

:confused: Got the EvoScan cable and software. Fired everything up and seems to com well, but addresses(request) seems wrong--rpm not htere, batt shows 20 all the time, speedo is on 20 and coolant is -41C. Can not get much else. Not real sure how to use, but did notice each line is able to be edited. I am guessing i need correct requests--can anyone help me out??? It returns ECU 742522. Here are requests that are there with function:

Please help----kevin

Use these addresses:

Engine Speed (RPM) 1290
Coolant Temp 1185
Throttle Position Sensor 128C
Mass Airflow Sensor 1283
Engine Load 1282
AF Correction 12AD
Ignition Advance 10A2
Knock Correction 12A7
ISC Duty Cycle 129D
Battery Voltage 12A2
Vehicle Speed 12A4
O2 Sensor (Right) 1291
O2 Max (Right) 12B0
O2 Min (Right) 12B1
O2 Sensor (Left) 1292
O2 Max (Left) 12B2
O2 Min (Left) 12B3

[genzzel]

Thank you so much. I sent e-mail to evoscan and he replied that he will also send addresses. I will put these in today. Thank you again!!!!

[genzzel]

Put in addresses ----works great!!!!!! Not sure if the calculations are right for temp and speed---I tried to set them for degF and mph instead of degC and kph. LOL think my calc is wrong---what should i use?? Thank you so very much for the help. Also on side note---the O2 left is running bout twice the mV of the right---one bad??? kevin

[b3lha]

Thank you so much. I sent e-mail to evoscan and he replied that he will also send addresses. I will put these in today. Thank you again!!!!

Hi Kevin,
If Hamish does send you the addresses, please post there here so we can compare them with my list. That would be a great help with the project.
Phil.

[b3lha]

Put in addresses ----works great!!!!!! Not sure if the calculations are right for temp and speed---I tried to set them for degF and mph instead of degC and kph. LOL think my calc is wrong---what should i use?? Thank you so very much for the help. Also on side note---the O2 left is running bout twice the mV of the right---one bad??? kevin

The formula for km/h is N*2. A kilometre is 5/8 of a mile, so for mph it will be N * 2 * (5 / 8) which can be simplifed to N * 1.25

The formula for deg C is N-50. Fahrenheit = C*9/5+32 so the formula is (N-50)*9/5+32 which simplifies to (9N-290)/5

With regard to the O2 sensor, I see three possibilities:

1) The address I gave you could be wrong, double check it against the address that Hamish sends.
2) The O2 sensor could be faulty, switch the two sensors around and see if the problem swaps sides.
3) One side of your engine could be running bad. Someone who knows more about engines than me can advise you on that.

[b3lha]

Tom,

I have an idea to make a special cable that will allow a laptop and a select monitor to be plugged in at the same time. Then we can see on the laptop screen exactly what commands the select monitor is sending to the car and what replies the ECU is sending back.

If I can build the cable and send it to you, would you be willing to give it a try with your select monitor? I just need to go to the Subaru breaker and get hold of three of the yellow female diagnostic connectors and one radio harness connector, then splice them together in the right way.

Phil.

[TomsSVX]

Tom,

I have an idea to make a special cable that will allow a laptop and a select monitor to be plugged in at the same time. Then we can see on the laptop screen exactly what commands the select monitor is sending to the car and what replies the ECU is sending back.

If I can build the cable and send it to you, would you be willing to give it a try with your select monitor? I just need to go to the Subaru breaker and get hold of three of the yellow female diagnostic connectors and one radio harness connector, then splice them together in the right way.

Phil.

Surely I can and will;)

tom

[b3lha]

Updated version of the ecu_defs.xml file for RomRaider.

This version works directly on the 32K files download by the Snowmobile software without needing to expand them to 64K. Unzip it and use it instead of the one that comes with RomRaider.

[TomsSVX]

Thanks Phil... I will try dumping another car today if I have time.

Tom (still waiting for my EvoScan cable to show up)

[Tim]

Thanks Phil... I will try dumping another car today if I have time.

Tom (still waiting for my EvoScan cable to show up)

Good news is I have my EEPROM eraser.

No writer/reader though :(.

[b3lha]

Somebody asked me how I produced the excel graph showing the maps in the ECU. Here is the procedure for anyone who wants to try it.

1) Extract your ROM to a file using the Snowmobile software.
2) Download the attached mapex.zip file and unzip it into the directory with the ROM file. There are two files, MAPEX.EXE and MAPEX.XLS

3) Run the MAPEX.EXE program to extract the maps into a CSV (comma separated values) file. You specify the filenames like this:
MAPEX SVXROM.HEX SVXROM.CSV

4) Then run Excel and open the SVXROM.CSV file and also the MAPEX.XLS. I am using Excel 2000.

5) Go to the CSV page. Highlight the Fuel Map, cells A4 through Q20 and click Copy. Now go to the MAPEX.XLS page, select the "Fuel Map" tab, highlight the cells A4 through Q20 and click Paste. The graph should update automatically.

6) Go to the CSV page. Highlight the Base Timing Map, cells A23 through Q39 and click Copy. Now go to the MAPEX.XLS page, select the "Base Timing Map" tab, highlight the cells A4 through Q20 and click Paste. The graph should update automatically.

7) Go to the CSV page. Highlight the Max Advance Map, cells A42 through Q58 and click Copy. Now go to the MAPEX.XLS page, select the "Max Advance Map" tab, highlight the cells A4 through Q20 and click Paste. The graph should update automatically.

I have set the default values in mapex.xls to the USDM maps that Nomake Wan sent me. If your ROM is from a USDM car, most likely they will be the same. However, if you have modified your maps in Rom Raider then you will be able to plot graphs of them using this method.

I've been thinking about trying the stock UK and USDM maps in my JDM car to see which set of maps gives the best performance. But I am busy at present so it will have to wait for a while.

Phil.

[TomsSVX]

EvoScan is operational... Finally

So hopefully today after I get some work (yea actual work :rolleyes:) done I can take a couple runs while data logging... Only problem is... I REALLY need to monitor my knock correction but it seems to not work correctly... any ideas would be great

Tom

[TomsSVX]

Just a little FYI the Evoscan cable is working and working well on my 92... I want to test it on a totally stock 92 since mine has the ECUtune adaptor and I have next to no idea what year this ECU came out of:rolleyes:

Tom

[genzzel]

Hi All---Through the invaluable help of Phil and Tom the following are the correct addresses and calc's that are working in EvoScan for the SVX. Hamish is still stuck on wrong addresses--probably for legacy or imprezza.

Batt volts 12A2 x*0.08 volts
Veh speed 12A4 x*1.242742384 mph
Eng speed 1290 x*25 rpm
Coolant temp 1185 (9/5)*(x-50)+32 degF
Ign advance 10A2 x deg BTDC
Air flow sensor 1283 x*5/256 volts
Engine load 1282 x units
Throttle position 128C x*5/256 volts
Injector pulse width 1306 x*256/1000 ms
ISU duty valve 1290 x*100/256 %dc
O2 avg right 1291 x*5000/512 mV
O2 avg left 1292 x*5000/512 mV
Knock correction 12A7 x-128 deg
Air/Fuel correction 12AD x-128 %

O2 sensor avg is actually the instantaneous reading.

hope this is of value:D

[b3lha]

Thanks Kevin,

I think the formula for MAF, TPS etc should actually be x*100/255, so that the maximum value of 255 equates to 5.0 volts. But it is as close as makes no real difference.

Have you tried to construct a good Evoscan "dashboard configuration" for the SVX?

[b3lha]

It has come to my attention that the Polaris snowmobile software is not 100% perfect for downloading our ECU ROMs. I have seen two dumps that got corrupted.

It was just a single address where the software had got out of sync and picked up part of the address rather than the data from the ECU response. One byte out of 32768 doesn't sound like much but it could cause problems if the download gets used as the basis for a modified ROM and written back to the ECU.

For that reason, I suggest verifying the checksum of the ROM after downloading it. Attached is a utility for Windows and Linux that can be used to verify the ECU checksum.

The ECU and TCU both have checksums in their ROMS and routines to check them. But I can't figure out how to trigger those routines. I think they may be part of some internal self-test mode.

If you modify a ROM, it makes sense to set the checksum correctly before writing it back to the ECU, although it will still work if you don't.

Just to clarify the upgrade procedure:

1) Download ROM to file
2) Verify Checksum of file is correct
3) Modify file as desired
4) Update Checksum in file
5) Burn file to EEPROM and install in ECU.

[TomsSVX]

thanks Phil, appreciate the input.

On a seperate note, seems my knock correction utylity in EVOScan was working after all. Torture testing with the select monitor showed 0 deg pulled out of the advance even under heavy loads. I have recalculated load in evoscan too to accept the new levels. Now it is just being able to re-write them....

Tom

[genzzel]

LOL--No dash of gauges yet-maybe this weekend:p

[genzzel]

Just thinking--is there an address and calc for the trans temp that we could input????

[TomsSVX]

sure there is... but it is in the TCU... I wonder if you can send/recieve from the TCU and ECU at the same time... Phil... do you know the command to read the TCU addresses??

Tom

[b3lha]

sure there is... but it is in the TCU... I wonder if you can send/recieve from the TCU and ECU at the same time... Phil... do you know the command to read the TCU addresses??

Tom

The command to read from the TCU is 45 instead of 78. The address for the trans temp is 0017 and I think the value is in F, with no conversion needed.

If you enter 45001700 in the hex com tool then look at the data that comes back 0017xx. Convert the xx from hex to decimal. Verify that it matches the value from the select monitor at cold, warm, and hot. If not we need to work out the conversion factor.

If you flick back to page 45 in the thread you can see a screenshot of a program I wrote to read info from the TCU. The newest version includes the trans temp and some other stuff.

Is it possible to send command 45 instead of 78 with Evoscan? That would be cool.

[TomsSVX]

I am not sure of that. Honestly wouldn't know where to look to find out.... Not to mention... I don't have an auto:p

Tom

The command to read from the TCU is 45 instead of 78. The address for the trans temp is 0017 and I think the value is in F, with no conversion needed.

If you enter 45001700 in the hex com tool then look at the data that comes back 0017xx. Convert the xx from hex to decimal. Verify that it matches the value from the select monitor at cold, warm, and hot. If not we need to work out the conversion factor.

If you flick back to page 45 in the thread you can see a screenshot of a program I wrote to read info from the TCU. The newest version includes the trans temp and some other stuff.

Is it possible to send command 45 instead of 78 with Evoscan? That would be cool.

[genzzel]

Sent note to Hamish to see

[b3lha]

I've just finished giving my website a large overhaul to reflect our latest knowledge. The downside of this is that some of the links and images further back in the thread will no longer work.

http://www.alcyone.org.uk/ssm

[b3lha]

This document describes how to build a cable that will allow a Select Monitor and a PC to be connected to the car at the same time. The PC can eavesdrop on the conversation between the SSM and the Car. In this way we can build up a definitive list of the ECU parameters.

Tom has kindly volunteered to give it a go when he gets time.:D

Phil.

[TomsSVX]

I should be able to get the info for OBDII ECUs as well if it can use the process.

Tom

[b3lha]

Cool. I wonder if Evoscan works on the OBD2 ECUs.

Even for OBD1, it would be a huge step forward to know that we are using the right parameters for the data logging.

[TomsSVX]

surely. The evoscan cable has two plugs... The OBDII diagnostic plug and the SSMI plug spliced in.

Tom

[longassname]

I believe you only had 2 or 3 parameters wrong when you posted them way back when.

If I may suggest--what you should be working on is identifying the routine that calculates the learned ignition advance correction and where it stores the learned values. This feature of the SVX ECU makes it unecessary to have fancy memory devices which can be rewritten while the vehicle is running in order to do auto tuning. All you have to do is let the ecu do the auto tuning and then pull the learned values to use to correct your ignition advance tables. This is 99.9% of the tuning that is within the abilities of 99.9% of end users.



Cool. I wonder if Evoscan works on the OBD2 ECUs.

Even for OBD1, it would be a huge step forward to know that we are using the right parameters for the data logging.

[TomsSVX]

This document describes how to build a cable that will allow a Select Monitor and a PC to be connected to the car at the same time. The PC can eavesdrop on the conversation between the SSM and the Car. In this way we can build up a definitive list of the ECU parameters.

Tom has kindly volunteered to give it a go when he gets time.:D

Phil.

Seems simple enough, firing up the soldering iron now..> Will have the cable ready in a couple minutes

Tom

[TomsSVX]

Cable is done... I do not have time to use it tonight, looks like maybe tomorrow afternoon.

Tom

[b3lha]

I believe you only had 2 or 3 parameters wrong when you posted them way back when.

If I may suggest--what you should be working on is identifying the routine that calculates the learned ignition advance correction and where it stores the learned values. This feature of the SVX ECU makes it unecessary to have fancy memory devices which can be rewritten while the vehicle is running in order to do auto tuning. All you have to do is let the ecu do the auto tuning and then pull the learned values to use to correct your ignition advance tables. This is 99.9% of the tuning that is within the abilities of 99.9% of end users.

Thanks for the input Michael. :)

I see what you mean about letting the ECU do the tuning itself. Ingenious. I would never have thought of that. :cool: I will spend some time looking in to it.

[b3lha]

Cable is done... I do not have time to use it tonight, looks like maybe tomorrow afternoon.

Tom

Nice one Tom. Good luck with the experiment. :D

[genzzel]

http://www.codeplex.com/ssm interesting

[b3lha]

http://www.codeplex.com/ssm interesting
Interesting stuff.

I think that might work with the OBD2 SVXes, but probably not the OBD1s.

If somebody started investigating the OBD2 ECU, it would probably open the door to some tuning solutions. The work being done on early OBD2 Impreza ECUs will surely be relevant.

[TomsSVX]

Ok got all the addresses off the 92-96 SVX SSMI

in order of functions on the SSM

F00- 0C3D ( ROM ID NUMBER "YEAR")
F01- 102F ( BATTERY VOLTAGE)
F02- 1071 ( VEHICLE SPEED)
F03- "" ( VEHICLE SPEED)
F04- 106F ( ENGINE SPEED)
F05- 1185 ( WATER TEMP)
F06- "" ( WATER TEMP)
F07- 10A2 (IGNITION TIMING)
F08- 1283 (AIRFLOW SENSOR)
F09- 1282 (LOAD DATA)
F10- 128C (THROTTLE POSITION SENSOR)
F11- 1280 (INJECTOR PULSE WIDTH)
F12- 129D (BY-PASS AIR CONTROL)
F13- 1291 (02 RIGHT HAND)
F14- 1292 (02 LEFT HAND)
F15- 12B0 (02 R MAX)
F16- 12B1 (02 R MIN)
F17- 12B2 (02 L MAX)
F18- 12B3 (02 L MIN)
F19- 1097 (AFR CORRECTION 1)
F20- 109F (AFR CORRECTION 2)
F21- 12A7 (KNOCK CORRECTION)
F22- 12A5 (CANISTER PURGE CONTROL)
F23- 125F (ATMOSPHERIC PRESSURE)
FB0- 1029 (DIAG. READ)
FB1- 12BC (DIAG. MEMORY)

I still need to get the formulas but most are pretty close as is.

Tom

[genzzel]

WOW--Great job!!!!!!! Thank you for doing that!!! :)

[b3lha]

Fantasic Tom!!! Good Work.

Thanks for doing that. How long did it take to get them all?

[b3lha]

I've just started marking these in the ECU program to see if it makes any more sense now. It will take a while.


F00- 0C3D ( ROM ID NUMBER "YEAR")

I'm pretty sure this one should be 8C3D. Not that it's particularly important.

[TomsSVX]

Phil, it really only took about 10 minutes mostly because my trial of the hex-com tool will only run for 5 mins at a time:rolleyes:. That and I hand wrote all of the addresses.

I have double checked all but the ID and the diag. addresses in Evoscan and they all work. I will try and do it to Eric's 96 next chance I get to get those ID's as well since they do not carry over.

Thanks again for all of your help.

Tom

[TomsSVX]

OK, got the TCU commands up... I may try to run them in Evoscan today if I can get it.

F01 VB- 45104400
F02 VSP1- 45001900
F03 VSP1- 45001900
F04 VSP2- 45001A00
F05 VSP2- 45001A00
F06 EREV- 4500B600
F07 ATFT- 45001700
F08 ATFT- 45001700
F09 THV- 45104000
F10 GEAR- 45004E00
F11 PLDTY- 4500B300
F12 LUDTY- 4500B400
F13 4WDTY- 4500B500
F14 BAROP.- 45104600

Its a short list of commands but this is what I got from a totally stock 1992 LS-L

Tom

[genzzel]

Again Great Job!! I have to ask--how will these run in EvoScan?? I am not sure how to do that.

[TomsSVX]

Not sure, didn't touch on them today.. maybe sometime soon though

Tom

[b3lha]

OK, got the TCU commands up... I may try to run them in Evoscan today if I can get it.

F01 VB- 45104400
F02 VSP1- 45001900
F03 VSP1- 45001900
F04 VSP2- 45001A00
F05 VSP2- 45001A00
F06 EREV- 4500B600
F07 ATFT- 45001700
F08 ATFT- 45001700
F09 THV- 45104000
F10 GEAR- 45004E00
F11 PLDTY- 4500B300
F12 LUDTY- 4500B400
F13 4WDTY- 4500B500
F14 BAROP.- 45104600

Its a short list of commands but this is what I got from a totally stock 1992 LS-L

Tom

Battery Voltage 1044
Vehicle Speed Sensor 1 0019
Vehicle Speed Sensor 2 001A
Engine RPM 00B6
ATF Temperature 0017
TPS Signal 1040
Gear Position 004E
Line Pressure SolA Duty 00B3
Lockup SolB Duty 00B4
4WD SolC Duty 00B5
Atmospheric Pressure 1046

Fantastic Tom! Thanks. That helps a lot.:banana:

I can't see a way in Evoscan to change the 78(ecu) command to 45(tcu). I'm going to email Hamish and see if he is willing to include this in the next version of Evoscan. Being able to look at ATF temperature would be particularly useful.

[TomsSVX]

sounds good... The reason I included the 4500 is the fact that a couple were 4510 while most were 4500, i wanted to be sure that this was noticed.

Tom

[genzzel]

I have written Hamish couple of times and no answer??? If you guys come up with anything or if he puts out version that works with TCU please let me know.

[b3lha]

Dear Hamish,

Thanks for all the work you have done to support older Subarus. We in the SVX community are very happy to finally have some good datalogging software for our cars.

Would it be possible for you to support the OBD1 Subaru TCU (transmission control unit) in your next version?

It shouldn't be too hard to implement. The query is exactly the same as for the ECU but you send 0x45 instead of 0x78.
ie. The "read" command is "45aaaa00" instead of "78aaaa00" where aaaa is the address. The "stop" command remains "12000000" just like on the ECU.

The parameter addresses are:
Battery Voltage 1044
Vehicle Speed Sensor #1 0019
Vehicle Speed Sensor #2 001A
Engine RPM 00B6
ATF Temperature 0017
TPS Signal 1040
Gear Position 004E
Line Pressure Solenoid Duty Cycle 00B3
Lockup Solenoid Duty Cycle 00B4
4WD Solenoid Duty Cycle 00B5
Atmospheric Pressure 1046

Thanks.
Phil Skuse.


Date: 2008-10-19 18:53:14
Name: Hamish Ahern

Message:

ok I'll implement that for v2.6. thanks for the info.

Regards,
Hamish Ahern.


Let's hope he does.:D

[genzzel]

Chesked evoscan site today and there is a 2.6beta4 version out--down loaded it but do not see anything for tcu logging:confused:

[TomsSVX]

Phil, wondering if you had some insight on the following things

Injector voltage correction time @ the following voltages
10.0v
10.3v
10.7v
11.0v
11.3v
11.7v
12.0v
12.3v
12.7v
13.0v
13.3v
13.7v
14.0v
14.3v
14.7v
15.0v

I know this is stuffed into the ECU's programming, I am just wondering if you have found it.

Also wondering if you have stumbled over the water temp correction maps?Cold start phasing?Cold start Primer?

The voltage correction time is crucial to my writing the base maps to the Nemesis. There is a VERY lengthy and boring procedure that I can do to get the correct values but i would love to avoid them if you have the data already

Tom

[Mrdjc]

Good to see there has been progress in the last few months, I more or less forgot about this whole project!

About the eavesdropping.. Where are you meant to get three female connectors? Strip them out of three cars? I had a look on the Molex website, but to no avail.

Also, can an idiots proof guide be written as to how to eavesdrop?
It looks a bit confusing to me :confused:
Also, do you connect it to B35, or to the ECU?

When you refer to SSM, do you mean the scanner available from Subaru?
or another pc with software like VWRX or Evoscan?

What are m and c in your calculations??

Cheers,
Daniel.

[b3lha]

Phil, wondering if you had some insight on the following things

Injector voltage correction time @ the following voltages
10.0v
10.3v
10.7v
11.0v
11.3v
11.7v
12.0v
12.3v
12.7v
13.0v
13.3v
13.7v
14.0v
14.3v
14.7v
15.0v

I know this is stuffed into the ECU's programming, I am just wondering if you have found it.

Also wondering if you have stumbled over the water temp correction maps?Cold start phasing?Cold start Primer?

The voltage correction time is crucial to my writing the base maps to the Nemesis. There is a VERY lengthy and boring procedure that I can do to get the correct values but i would love to avoid them if you have the data already

Tom

Sorry Tom,
I've only just seen this. I assume from your other thread that you've got all this figured out now?
I can see dozens of different maps in the ECU, the difficulty is in knowing what they represent.

[longassname]

It uses a formula for voltage correction of the latency value so there is no table.

The starting fuel methodology will be different than for the nemisis as well so the starting pulse width, idle enrichment, and cold idle enrichment tables wouldn't be much use either.

The right way to do it for that system is to get the injector latency measured at all those voltages with the correct fuel pressure to be used. That's one of the advanced services at rc engineering.

[b3lha]

Good to see there has been progress in the last few months, I more or less forgot about this whole project!

About the eavesdropping.. Where are you meant to get three female connectors? Strip them out of three cars? I had a look on the Molex website, but to no avail.

Also, can an idiots proof guide be written as to how to eavesdrop?
It looks a bit confusing to me :confused:
Also, do you connect it to B35, or to the ECU?

When you refer to SSM, do you mean the scanner available from Subaru?
or another pc with software like VWRX or Evoscan?

What are m and c in your calculations??

Cheers,
Daniel.

Welcome back. :)

This should help explain the eavesdropping:
http://www.alcyone.org.uk/ssm/eavesdrop.html

The idea is that you connect the eavesdrop cable in between your car and the Subaru dealer's Select Monitor tool. Then you can use your PC to listen to the communication between the Select Monitor and the car.

For each parameter, you can see which address the select monitor is querying. That's half the problem solved.

The other half of the problem is to figure out how to map the value that comes back from the ECU to the value that gets displayed on the select monitor screen. Most likely it will be a linear relationship. That means the equation will be y=mx+c. y is the select monitor value, x is the raw data, m is a multiplier and c is a constant. The values of m and c can be worked out by taking two readings and using "simultaneous equations".

You need to get the female connectors from a car breaker. I haven't found another source. If you can find a breaker with a 1st Gen Legacy then you are in luck because you can pull it's diagnostics connector and it's radio connector. They are the same.

It's not difficult to do. I'll be happy to take you through it step by step.

[TomsSVX]

It uses a formula for voltage correction of the latency value so there is no table.

The starting fuel methodology will be different than for the nemisis as well so the starting pulse width, idle enrichment, and cold idle enrichment tables wouldn't be much use either.

The right way to do it for that system is to get the injector latency measured at all those voltages with the correct fuel pressure to be used. That's one of the advanced services at rc engineering.


You are right, thats why I am still in the market for an adjustable voltage DC power source. This way I can actually find the injector response times...

I spent a long time writing the cold start fuel maps and cranking enrichment maps. They are actually very good the way I have written them. But the bad part is, I will likely need to do them all over again after I get the correct response times for the injectors... Thing is, regardless of close they may be, it is going to vary slightly from car to car due to age of the wiring harnesses and how much resistance they have lost or gained over the years. So it will need to be done for every car if you want it to be that precise. It really only needs to be done if one was to run VE mode in the Nemesis. VE mode doesn't really gain you anything excpet the ability to change injectors w/ the entry of a new flow rate into the system. But all thing considered... tuning in ms is much better IMHO

Tom

[TomsSVX]

Welcome back. :)

This should help explain the eavesdropping:
http://www.alcyone.org.uk/ssm/eavesdrop.html

The idea is that you connect the eavesdrop cable in between your car and the Subaru dealer's Select Monitor tool. Then you can use your PC to listen to the communication between the Select Monitor and the car.

For each parameter, you can see which address the select monitor is querying. That's half the problem solved.

The other half of the problem is to figure out how to map the value that comes back from the ECU to the value that gets displayed on the select monitor screen. Most likely it will be a linear relationship. That means the equation will be y=mx+c. y is the select monitor value, x is the raw data, m is a multiplier and c is a constant. The values of m and c can be worked out by taking two readings and using "simultaneous equations".

You need to get the female connectors from a car breaker. I haven't found another source. If you can find a breaker with a 1st Gen Legacy then you are in luck because you can pull it's diagnostics connector and it's radio connector. They are the same.

It's not difficult to do. I'll be happy to take you through it step by step.

If you need, I can ship my connector that I built... I am not using right now and would have no problem lending it if you need it

Tom

[longassname]

a 47 cent trim pot connected to the battery being used to drive the system is an adjustable voltage dc power source.



You are right, thats why I am still in the market for an adjustable voltage DC power source. This way I can actually find the injector response times...

I spent a long time writing the cold start fuel maps and cranking enrichment maps. They are actually very good the way I have written them. But the bad part is, I will likely need to do them all over again after I get the correct response times for the injectors... Thing is, regardless of close they may be, it is going to vary slightly from car to car due to age of the wiring harnesses and how much resistance they have lost or gained over the years. So it will need to be done for every car if you want it to be that precise. It really only needs to be done if one was to run VE mode in the Nemesis. VE mode doesn't really gain you anything excpet the ability to change injectors w/ the entry of a new flow rate into the system. But all thing considered... tuning in ms is much better IMHO

Tom

[TomsSVX]

a 47 cent trim pot connected to the battery being used to drive the system is an adjustable voltage dc power source.

True, but it won't help me get over the 13.2v it is usually running at. A simple solution would be to use a 15v DC power adapter with a pot and a voltmeter... I am still waiting for my Delphi pins to show up. Once I have those I will be building a unit to do so.. I will also be wiring the harness for the TCU as well... But I am still waiting for 100 pins to show up at my door.

Tom

[longassname]

two batteries connected in series makes 24 volts for the circuit you want the 15v on and you can still wire everything else connected to just the 1 battery for 12v. Two batteries will last better for your test anyway.


True, but it won't help me get over the 13.2v it is usually running at. A simple solution would be to use a 15v DC power adapter with a pot and a voltmeter... I am still waiting for my Delphi pins to show up. Once I have those I will be building a unit to do so.. I will also be wiring the harness for the TCU as well... But I am still waiting for 100 pins to show up at my door.

Tom

[oab_au]

a 47 cent trim pot connected to the battery being used to drive the system is an adjustable voltage dc power source.

Can't really do it that way Mike. The series resistance of the pot will add to the circuit resistance to limit the current flow, that the injector needs to pull the pin.

Harvey.

[longassname]

that's true it would be better to have the same voltage with and without load. how many amps do the injector coils draw?

[oab_au]

that's true it would be better to have the same voltage with and without load. how many amps do the injector coils draw?

They are 12 ohms, so they would pull a nominal 1 amp at 12 V. They are probably the only resistance in the circuit, but due to the inductance reactance of the coil the current rush would be less. You would need to check it on a scope.

Harvey.

[longassname]

an lm338 is 5 amps i would think that would be plenty and you could just hook up a pot to control it

[longassname]

well if it's only an amp then an lm317 would be enough

[oab_au]

an lm338 is 5 amps i would think that would be plenty and you could just hook up a pot to control it

Yes that would be an easy way to do it.

Harvey.

[oab_au]

I would use the bigger one as it would be 1.25amps at 15V.

Harvey.

[TomsSVX]

Well I got the pins in today, I am in the midst of another project so it will wait till Wed. that I will be able to order the compontents needed to build the regulator. I will stop hijacking Phil's thread though:o

Tom

[Numbchux]

Alright, been reading through this thread....sooooo much information!!


unfortunately, all the acronyms and numbers and such have my eyes spinning in my head. also, the project I'm looking to undertake is not related to the ECU, but the TCU, so I'm having a hard time sorting out all this information. So I'm hoping someone would be willing to spoon-feed me a bit of info to get me off on the right start.


for starters, I was inspired to take on this project by a guy over on USMB who reprogrammed a legacy TCU to run the 4EAT in his GL-10, and then continued to reprogram to add paddle shifters and a "DCCD" knob.
The thread here on svx.net (http://www.subaru-svx.net/forum/showthread.php?t=47231)
his thread on USMB, with way more information, and me asking a bunch of questions (http://www.ultimatesubaru.org/forum/showthread.php?t=93670)

As mentioned by my posts in that thread, I would like to do this with my XT6. But I'm not sure if a legacy or SVX TCU would work better (working on harness modifications in my free time, I have access to both, in quantity), so some experimentation will be required.


Phil...positively awesome website!!! I don't think I would have been so confidant in taking on a project like this without the information you have compiled there. Thanks!



alright...questions.

first, how do you download the rom file from the TCU? through the PC->select monitor adapter? what program? I see the Alcyone program listed on Phil's site, but I don't have a computer running linux (and very little experience using it...). other options? or should I look into installing linux on one of my machines.

also, what would it take to communicate with the TCU out of the car? would it be possible to use a relay, 12v power source, and a little wiring to test things here in my living room?



I hope I'm not being too n00bish with my basic questions. and I know I've got a lot of reading and research to do before I can really take on this project....but I'm hoping you guys can get me off on the right foot.

Thanks!

[b3lha]

Alright, been reading through this thread....sooooo much information!!


unfortunately, all the acronyms and numbers and such have my eyes spinning in my head. also, the project I'm looking to undertake is not related to the ECU, but the TCU, so I'm having a hard time sorting out all this information. So I'm hoping someone would be willing to spoon-feed me a bit of info to get me off on the right start.


for starters, I was inspired to take on this project by a guy over on USMB who reprogrammed a legacy TCU to run the 4EAT in his GL-10, and then continued to reprogram to add paddle shifters and a "DCCD" knob.
The thread here on svx.net (http://www.subaru-svx.net/forum/showthread.php?t=47231)
his thread on USMB, with way more information, and me asking a bunch of questions (http://www.ultimatesubaru.org/forum/showthread.php?t=93670)

Thanks for the link to USMB. The work Ryan did is really very impressive.

As mentioned by my posts in that thread, I would like to do this with my XT6. But I'm not sure if a legacy or SVX TCU would work better (working on harness modifications in my free time, I have access to both, in quantity), so some experimentation will be required.

I would suggest using whatever TCU is the closest match to your transmission. The gear and diff ratios are factored into the calculations in the firmware. The less things you have to change, the more chance of it working properly.

Phil...positively awesome website!!! I don't think I would have been so confidant in taking on a project like this without the information you have compiled there. Thanks!

Thanks. I'm glad it's useful. The whole reason I published it was to help with cool projects like yours. :)

first, how do you download the rom file from the TCU? through the PC->select monitor adapter? what program? I see the Alcyone program listed on Phil's site, but I don't have a computer running linux (and very little experience using it...). other options? or should I look into installing linux on one of my machines.

At present, the only software that can read the TCU is my linux tcudump program. It talks to the TCU through the select monitor adapter.

You don't need to install linux, you can use a knoppix or ubuntu boot cd. If you have ever used the MSDOS command line, then you should have no problem learning a few simple linux commands.

If you know how to program for windows, it wouldn't be too hard to port my program across or write your own from scratch.

Longassname has another way of doing it (see "gearshift maps" thread). Unsolder the surface mount rom, solder some pins to it and slot it into your eprom burner. Personally I would not attempt this as I find it impossible to remove the rom without damaging it.

also, what would it take to communicate with the TCU out of the car? would it be possible to use a relay, 12v power source, and a little wiring to test things here in my living room?

I see no reason why it wouldn't work. But I've never tried it myself. Just connect the power and grounds as necessary. Connect the select monitor communication lines to your adapter.

But it's probably easier to just download the rom file with the TCU in a car because everything is already connected properly.


I hope I'm not being too n00bish with my basic questions. and I know I've got a lot of reading and research to do before I can really take on this project....but I'm hoping you guys can get me off on the right foot.
Thanks!
No problem. That's what this thread is here for.

Good luck with your project.

Phil.

[Numbchux]

Thanks a ton for the info! that's exactly the jump start I needed!


I need to dig through my FSMs and double check gear ratios. I'm not sure if I have a list for the SVXs. would be cool to use download the shift maps from the FWD Legacy TCU I have, and load it into an AWD one (FWD legacies use 100% identical gear ratios to my XT6 4EAT). my main concern, however, is using a TCU programmed for a 4-cyl with the 6-cyl, as the rpm signal will be calibrated differently. The code that Ryan posted is for a Legacy TCU, but a legacy TCU (unless modified....which sounds like it may be a possibility) will think it's hit redline when the engine is really at like 4200. which is why I'm looking into SVX stuff.

anyway, got a lot of work to do, but hoping to have this up and running sometime this summer.

[TomsSVX]

Hey Phil, do you still need/want an OBDII ECU to disect?? I just dug one out while doing some organizing

Tom

[b3lha]

Hey Phil, do you still need/want an OBDII ECU to disect?? I just dug one out while doing some organizing

Tom

Yes please Tom!

If you're happy to lend it to me for a while then let me know the shipping cost to England and I'll paypal you.

On second thoughts: Will it plug into my OBD1 car, or are the plugs completely different? If different then maybe it's better for you to look at it with my help. There are no OBD2 SVXes on this side of the atlantic where I could plug it in and download the data.

[b3lha]

It was my birthday a few months ago and Belha bought me some components to build a USB to SSM cable. She knows what I like.:lol:

I recently got around to building the cable and I've written up some instructions for anyone else who wants to try it. The howto describes two types of cable:

1) A simple cable, similar to the one you can buy from Evoscan.

2) An improved cable, incorporating Calum's comparator circuit to fix the 92 problem. This is the one I am using and it works great even on the problem cars.

[longassname]

Phil,

What I had aluded to before about the signal you guys are trying to modify with a comparator is that it is not supposed to be ttl. Check the datasheet for the processor and you will see that the serial lines are designed to match up with a different generation of driver with greater separation between vih and vil. The buffer gates are still available and very inexpensive. 54hc125

[longassname]

Phil,

I get legacy guys asking me to do their ecu's from time to time. The NA's all use the JECS ecu's some of which have daughter boards and others don't. My current memory adaptors were made to fit all of them but I don't want to invest the time doing the tuning. As long as you are on a mission to hack every suby ecu you can get into...want me to point them to you? I'll add the memory adaptors to my website and let them do their own tuning if you want to get them up and running on it.

[b3lha]

Phil,

What I had aluded to before about the signal you guys are trying to modify with a comparator is that it is not supposed to be ttl. Check the datasheet for the processor and you will see that the serial lines are designed to match up with a different generation of driver with greater separation between vih and vil. The buffer gates are still available and very inexpensive. 54hc125

I understand what you are saying, but there is something that doesn't make sense to me. If the CPU is using a greater logic separation than TTL, then surely the problem would occur on signals from the adapter to the CPU? But in fact, we were seeing the reverse problem, bad signal from the CPU to the adapter.

In any case, the comparator circuit solves our problem completely by converting whatever signal the ECU sends to a good TTL signal with a user-adjustable threshold.

I've been meaning to take an oscilloscope trace of the signal to help me understand the problem better.

[longassname]

Because the buffer gates are designed specifically to avoid the problems you have seen. They accept a much higher vil to allow for noise. They then output a VERY close to true 0 vil and very close to true vcc vih.

[longassname]

using that buffer gate will give you a better signal, remove the need to fiddle with adjusting, and cost less.

[longassname]

I understand what you are saying, but there is something that doesn't make sense to me. If the CPU is using a greater logic separation than TTL, then surely the problem would occur on signals from the adapter to the CPU? But in fact, we were seeing the reverse problem, bad signal from the CPU to the adapter.




Sorry, that's cause I said the wrong thing....the separation isn't greater..it's smaller to the same but with a higher vil to account for noise. at 5v you're looking at a vil around 1.5v and vih around 3.3v

[b3lha]

OK That makes more sense.

I know that the two designs that I have work 100% because I can download the whole 32K ECU rom and the checksums calculate correctly. 262144 bits without a single error can't be a bad thing.

I'm not planning to build any more adapters at present. But if you post a circuit diagram of your proposed design then I'll give a try next time I build one.

[b3lha]

Phil,
I get legacy guys asking me to do their ecu's from time to time. The NA's all use the JECS ecu's some of which have daughter boards and others don't. My current memory adaptors were made to fit all of them but I don't want to invest the time doing the tuning. As long as you are on a mission to hack every suby ecu you can get into...want me to point them to you? I'll add the memory adaptors to my website and let them do their own tuning if you want to get them up and running on it.

I'm happy for you to point people to my website. Whether I'll be able to help them much is another matter. I know nothing about tuning and most of the maps in the ECU are still a mystery to me. Probably the best I can do is to disassemble the code for them and tell them to go learn assembler.:lol:

I think selling the blank adapters is a good idea. I just sold one of mine to a guy who is building a wrx rally car.

I noticed that my Legacy ECU doesn't have a socket, but it does have a 2x14 row of solder dots where I could presumably attach a ribbon cable to a daughterboard. Not that I have any plan to do so at the moment.

[Mrdjc]

Phil,

I just dumped my ROM file using the Polaris tool, took about 45Min...
*EDIT2* I'm a numpty.. went back a few pages in the thread and caught up to what i hadn't read the last few months.. found the definition table for rom raider there. Many thanks for doing all the hard work Phil! Much appreciated.
*EDIT2*

*EDIT* Oh, forgot to ask, with eavesdropping I take it you require access to subaru's own SSM cartridge system and then make it ask for info from every feature it has? How do you propose getting hold of one? Do you know anyone who is willing to share it? I thought they were a tad expensive last time I saw one for sale.. £2K!!
*EDIT*

*EDIT3*
I stuffed the ecu_defs.xml file into the C:\Program Files\RomRaider folder. I started the program and went to ECU Definitions, ECU Definitions Manager, Pressed Add, selected the file, hit ok, hit save and hit apply.

I then tried to load the Rom file and it said ECU Definition Not found.
I tried your Checksum thing, fired it up in Cmd prompt and checked a copy of the original Hex file I got with the -w function.
Tried this in romraider, same error again.
Maybe my ECU is speaking in Hebrew rather than Japanese?
Not sure what to do now.. Should I dump it again and see? Is the definitions file specific for the SVX rather than universal SSM, supporting the N/A EJ20 Legacy?
*EDIT3*

I really think I need to read a book on ECU's, Binary, Hex, Engine managment etc. I want to learn!

Cheers,
Daniel.

[b3lha]

Hi Daniel,

Is the definitions file specific for the SVX rather than universal SSM, supporting the N/A EJ20 Legacy?

Yes. The definitions are SVX specific. RomRaider selects which definition to use based on the ROM ID. The error message you are getting means that it can't find a section in the definitions file to match your ROM ID. In order to use RomRaider with your ECU, you need to locate the maps in your ROM, figure out how to decode them and then write a defintion for them. I'm sure there are people in the tuner community who have already done this, but unfortunately they are not sharing the information.

with eavesdropping I take it you require access to subaru's own SSM cartridge system and then make it ask for info from every feature it has? How do you propose getting hold of one? Do you know anyone who is willing to share it? I thought they were a tad expensive last time I saw one for sale.. £2K!!

Yes that is how it works. Getting hold of a select monitor is the problem. Fortunately for the SVX community, TomsSVX had access to a select monitor with the SVX cartridge. If you are lucky you may find a Subaru Mechanic who will lend you one for a couple of hours. It doesn't hurt to ask.

I'm a numpty..
I tried your Checksum thing, fired it up in Cmd prompt and checked a copy of the original Hex file I got with the -w function.

:eek: The checksum program is designed for the SVX ECU and similar. It will almost certainly report a bad checksum on files from other ECUs. If you run it with the -w option on the wrong type of file then it will corrupt the file. I should probably have put a strongly worded warning in the program, but it was just something I knocked together in 5 minutes for my own use. It was never designed for "numptys". :)

I really think I need to read a book on ECU's, Binary, Hex, Engine managment etc. I want to learn!

Yeah. This stuff is tough to learn. I'm a beginner myself but I'm sharing what I know in the hope of learning more. The best resource I have found is a Nissan ECU hacking forum at http://eccs.hybridka.com.

There is a guy called Brett (log1call) on the SubieSmart forum http://www.subiesmart.com/forum who has just downloaded the ROM from his 1990 EJ20 Legacy. Rom ID 703315. Is that the same one that you have? He's a beginner at this too, so I'm going to try and explain to him how to get started with it. You are welcome to join the discussion.

[b3lha]

Shane, the JDash guy, has written a cool new version that will run on a mobile phone.

At the moment it only works for OBD2, but he is promising to support SSM at some point in the future. I think the problem is that he doesn't have access to an OBD1 subaru to use for developing and testing the code.

http://www.rs25.com/forums/showthread.php?t=97625

[Mrdjc]

Hi Daniel,
f you run it with the -w option on the wrong type of file then it will corrupt the file. I should probably have put a strongly worded warning in the program, but it was just something I knocked together in 5 minutes for my own use. It was never designed for "numptys". :)

So I was correct in calling myself a numpty then!
See what happens when you give kids a toy.. :rolleyes:
Luckily I did it on a copy, I still have my original so I should be fine. :lol:

http://www.subiesmart.com/forum[/url] who has just downloaded the ROM from his 1990 EJ20 Legacy. Rom ID 703315. Is that the same one that you have? He's a beginner at this too, so I'm going to try and explain to him how to get started with it. You are welcome to join the discussion.

Thanks for the link,
I'll jump on the bandwagon and get stuck in too.

There's a miniature goldmine to be exploited, consisting of the BD5/BG5 legacy comunity. As well as BC5 too. BG7 and BD/BG9 will be another kettle of fish though, but once you've mastered the way of the ECU Zen.. Should be fairly straightforward.

I've got my Rom ID written down somewhere, but VWRX doesn't pull it up, neither does the Polaris software.. I think Evoscan did though.

I can't quite recall, I think it starts with 732, but its definately the same Mitsubishi M37791 CPU as I had a peek inside.
*EDIT* Found the ID, its 742FA1 *EDIT*

Thanks for your help once again, I think you deserve a nobel prize.

Cheers,
Daniel.

[b3lha]

I found some new software on a Japanese site.

http://ssm.nextfoods.jp/

It's called WinSSM and from what I can make out, it's something like VWRX or Evoscan. The site shows it being used on an OBD2 STi. As I can't read Japanese, I can't tell if it's possible to make it work on an OBD2 SVX or even an OBD1 car.

There seems to be a hardware products as well. There is a video of it in operation.

[b3lha]

Also, somebody just posted on SubieSmart the procedure for reflashing JECS OBD2 ECUs. So that might open up a few new possibilities once I get my hands on one.

[svxistentialist]

That looks a very interesting piece of kit Phil.

Wonder how much it costs?

:)

[b3lha]

That looks a very interesting piece of kit Phil.

Wonder how much it costs?

:)

Dunno what that hardware thing costs, but I just discovered what the software is for. Check this out.

http://ssm.nextfoods.jp/index.php?DemoMovie%2F7

The software is a datalogger like the VWRX software but it connect to a USB video camera, and overlays the parameters on the video.

very cool. :cool:

[svxistentialist]

That is seriously cool!

So, taking that as a starting point would it be reasonable to presume their software takes raw data from the OBD II connections, translates it to something like mpeg4, and this can then be overlaid on a video as per the clip, or else displayed on an in-car video screen?

That seems to be the answer to many a prayer.

[ Well, with the notable exception of instrument manufacturers, they will not be able to sell so many of those stupid A pillar pod things :barf:]

Bring it on.

;)

[b3lha]

That is seriously cool!

So, taking that as a starting point would it be reasonable to presume their software takes raw data from the OBD II connections, translates it to something like mpeg4, and this can then be overlaid on a video as per the clip, or else displayed on an in-car video screen?

That seems to be the answer to many a prayer.

[ Well, with the notable exception of instrument manufacturers, they will not be able to sell so many of those stupid A pillar pod things :barf:]

Bring it on.

;)

Yeah that's what it does. There's a howto if you paste this URL into the "google language tools".

http://ssm.nextfoods.jp/index.php?HowToUse%2F20080510

[SVXdc]

Very interesting. They're showing two different things...

The WinSSM "How To Use" page describes the WinSSM data logging software. An (off-the-shelf?) ODB2-to-USB adapter connects to a laptop running the software. Video is captured from a USB web cam. The WinSSM software has the ability to overlay graphic representations of the data onto the camera video, displaying that on the laptop's screen.

Further down, the author mentions displaying the data graphically on an in-dash screen (but the example no longer shows it overlaid on video from a web cam). He mentions that your laptop would require an NTSC video output to connect to an in-dash (or sun visor, or rear view mirror) LCD display.

The G-SSM65 circuit board is shown on a different web page. It appears that its main purpose is to collect engine data from the car's ODB2 port plus an onboard accelerometer, and feed the data to the laptop via an RS-232 serial port for logging (optionally through a serial-to-USB converter, if your laptop lacks a serial port).

The board connects to the car's ODB2 port via the 3.5mm jack (which also provides +12V DC to power the board).

The large IC is a PIC24FJ64GA002 microcontroller (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en026374). The RS-232 conversion is handled by a MAX-232 IC (16-pin, adjacent to the DB-9 serial connector). The other two 8-pin ICs are an 8K byte EEPROM (AT24C64B (http://www.atmel.com/dyn/products/product_card.asp?part_id=3222)), and a 3-axis accelerometer (KXM52-1050 (http://translate.google.com/translate?prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fakizukidenshi.com%2Fcatalog%2Fg%2Fg I-01425%2F&sl=ja&tl=en&history_state0=)).

6-pin connector J4 is for temporarily attaching a device to reprogram the PIC.

But the board also somehow provides an NTSC video output. Since there are no other ICs that could handle this function, I can only conclude that the microcontroller is doing this in software! The examples on the web page show the output as lines of plain text and simple graphics (all monochrome), so this isn't out of the realm of possibility. It looks to be 32 characters wide x 10 lines tall. But it still sounds like it would take lots of CPU time to make it work.

Obviously, the WinSSM software running on the laptop is able to create slightly nicer and more colorful graphics to display the data.

As best I can tell, the "GT-R" data display (http://ssm.nextfoods.jp/index.php?plugin=ref&page=HowToUse%2F20080510&src=GT-R.jpg) is something different entirely — not from the WinSSM software (and definitely not from the G-SSM65 board). Perhaps that's some existing commercial car data monitor, and an example of a slicker look that he'd like the WinSSM to be able to match?

[TomsSVX]

Phil, what do you need out of the OBDII ECM?? I thought you told me not to bother sending it:confused:

Tom

[b3lha]

Phil, what do you need out of the OBDII ECM?? I thought you told me not to bother sending it:confused:

Tom

Yeah. I did.

All the work I've done on OBD1 has been with the ECU installed in the car. As I can't do that with OBD2, I would have to get make a harness to wire it up on the bench. I don't have the time to do that at present.

[TomsSVX]

gotcha. ok

Tom

[svxistentialist]

Yeah. I did.

All the work I've done on OBD1 has been with the ECU installed in the car. As I can't do that with OBD2, I would have to get make a harness to wire it up on the bench. I don't have the time to do that at present.

Well Phil

You could always go out and buy a OBD II car, instead of all those Japanese yokes you keep collecting! :bash:

Joe :p ;)

[b3lha]

Well Phil

You could always go out and buy a OBD II car, instead of all those Japanese yokes you keep collecting! :bash:

Joe :p ;)

LOL. If I had the cash to import a USDM 97, I'd spend it on another VL instead.:rolleyes:

[svxistentialist]

I think 96/97 UK cars are OBD II. I'm pretty sure Arthur's Polo green car is anyway. It has the socket beside the steering wheel.

:)

[b3lha]

I think 96/97 UK cars are OBD II. I'm pretty sure Arthur's Polo green car is anyway. It has the socket beside the steering wheel.

:)

That's not what Arthur said.:)

Hi, well I can confirm the UK SVX has no OBD connector ! (£10 for anyone who can put their back out and discover it)

[svxistentialist]

Oh, well that's a different kettle of fish then, isn't it? :rolleyes:

Are they a different protocol then Phil, OBD E or something?

Joe

[b3lha]

Oh, well that's a different kettle of fish then, isn't it? :rolleyes:

Are they a different protocol then Phil, OBD E or something?

Joe

OBD2 wasn't mandatory in Europe until 2001 and they called it EOBD just to confuse matters.

As far as the SVX goes, I think they just carried on fitting OBD1 ECUs. In fact I checked an ECU that was supposedly from a 1996 UK and it had a 1992 ROM inside. Maybe they never bothered updating the UK cars at all.

My 94 JDM has a 1994 ROM, and I've copied it to one of my 92 cars just in case the bugfixes are worth having.

[b3lha]

Einimas posted on SubieSmart forums that he is successfully using a cell-phone USB cable to communicate with his Honda ECU.

I did some digging around and it seems that a clone Nokia CA-42 or DKU-5 cable may work in place of the FTDI cable in my howto. It would substantially reduce the cost of making a cable. They can be bought on ebay for under $5.

I can't find any reliable information on whether they work at 3.3 or 5.0 volts. The ECU expects 5 volts. Further back in this thread, Hocrest tried a 3.3 volt cable and couldn't get it to work.

Anyway, Einimas is planning to test his cable on his Dad's 95 Legacy and we'll see what happens.

[b3lha]

Branden has managed to get his laptop to talk to a 1996 USDM Legacy OBD2 ECU. I reckon this is probably similar to the ECU in an OBD2 SVX. There is a good chance it will work if anyone wants to try.

He used a Volkswagen "VAG COM" OBD2 cable and the "techdiag" software.

http://cgi.ebay.com/ebaymotors/ws/eBayISAPI.dll?ViewItem&item=150329198731

http://techdiag.co.uk/obdscantech/web/home.html

[longassname]

Did 5 people ever come up with orders for the realtime from Calum? I remember he said he uses the ftdi chip for his coms. I'm working on a dot Net application complete with auto tuning. As I'm more of Systems Analyst than your typical programmer I have a well developed set of classes that should let the application support most any control device out there including the SVX. I'm using the the ftdi chip for my coms as well and can incorporate support for Calum's real time if you guys want to follow through on having him make it.

[b3lha]

As mentioned in the Gearshift Maps thread, Longassname sent me a copy of the SVX Select Monitor Cartridge. I have now analysed some of it and documented it on my website. I haven't documented everything I know yet and I still have a lot more work to do, in particular analysing the decode functions.

http://www.alcyone.org.uk/ssm/selmon.html

[longassname]

Shortly after Phil finishes the documentation of the conversion functions I'll release an alpha of the windows tuning software. It will be free to download and free to use for bin editing so you will be able to do offline tuning for free. It has support for the Moates Ostrich II emulator. The software uses an ftdi usb cable which it is serial locked to for coms with the control unit. You will have to purchase this cable from me to be enable the realtime tuning and diagnostic capabilities of the software. I'm using Microsoft Excel .xls spreadsheets for definition files so you will be able to easily extend your SVX tuning capabilities in a user friendly way as you identify new parameters of interest. That will be entirely up to you guys. I won't be offering support for particular applications just the general functioning of the software.

[Dessertrunner]

Has anyone heard how Calcum, is he still working on the SVX ECU? I have tried to call him and I didn't get a answer?
Tony

[b3lha]

I started this project as a bit of a hobby almost exactly two years ago. I've put in a lot of work and spent many long hours puzzling over complex bits of assembly code. Everything I've discovered has been freely shared here and/or on my website and I've never tried to make any profit from it. Even the cables and boards that I've made have been sold off at cost price.

All this work has now paid off. Big time. A couple of week back the software company I worked for went bankrupt and everybody was laid off. The economy is bad at the moment and I was very worried about whether I'd be able to find a new job.:(

But then I heard that a well known tuning company was looking for a computer geek who knew something about reverse-engineering ECUs. So I emailed them some links to my website and a couple of my threads on Subiesmart. They were impressed and invited me for an interview. It all went well and they just offered me a full time job! :D

Two years ago, when I first plugged my homemade adapter into my SVX and saw the numbers scrolling up the screen, I could not have imagined anything like this. Thank you to everyone who has contributed to this thread. Without your help, advice, encouragement, knowledge and expertise, I probably wouldn't have got this far.

Phil.

[longassname]

That's awesome Phil, congrats, and I say they have made a great choice in hiring you.

[svxistentialist]

Dang, Phil!

That's the sort of Good News I likes to see on my computer. :D

Congratulations man, it couldn't happen to a nicer fellow, you deserve to reap the rewards.:banana:

Errr, this doesn't mean we will have to pay you now for any future SVX analysis? Hmmm? Does it?

Phil?

:p ;)

Joe

[Trevor]

Great news PHil.

Believe it or not, I have been thinking of you and your strife, but concluded that surely someone with your skills could not long remain on the bench

Hobbies quite often result in work related opportunities. You were not lucky. You were rewarded for your previous efforts and now lengthy research of the employment market.

May this be a step upwards and forwards. :)

Trevor.

[oab_au]

Congratulations Sir Phil,:)
Could not get a better bloke for the job :cool:

Harvey.

[Bobb]

Hi Phil, Isn't life interesting. I'm sure the last thing you thought when you started this project was an ending like this. Lets hear it for natural curiosity. You will do great at this new job! Take care, BOBB

[Dessertrunner]

Thats great news Phil, its always good when adversity turns to success.
Tony

[b3lha]

Thanks guys. Had my first day today and I think I'm going to love this job:D


Errr, this doesn't mean we will have to pay you now for any future SVX analysis? Hmmm? Does it?


The company reverse-engineers ECUs and produces software to allow tuners to tweak the ECU maps and constants. The software doesn't support any pre-OBD2 Subarus and they have no intention to. I reckon if I confine my private work to obsolete non-flashable stuff like the SVX, there won't be any conflict of interest.;)

[NeedForSpeed]

Great Phil, simply fantastic!


Thanks guys. Had my first day today and I think I'm going to love this job:D



The company reverse-engineers ECUs and produces software to allow tuners to tweak the ECU maps and constants. The software doesn't support any pre-OBD2 Subarus and they have no intention to. I reckon if I confine my private work to obsolete non-flashable stuff like the SVX, there won't be any conflict of interest.;)

[svxistentialist]

As Ron says;........;)

That's great news Phil. I'm delighted you are enjoying it.

Joe :D

[Phil Hill]

Hey Phil

Just popped in and read about your triumph out of adversity. Having read (but not necessarily understood !! and I have some experience of mapping Gas Turbine fuel schedules !!) some of the work you've done in decoding the TCU and sorting out the various maps, profiles and what-have-you I think what started out as a bit of a hobby has paid dividends to you !!

I hope your new position remains both interesting and challenging, and importantly secure for the long term.

All I can do is add my congrats to the others, well done you !!

Phil (the other one.)

[longassname]

Hey Phil,

How's the new joby job? I guess word/rumor that I'm releasing a windows ap for control unit tuning isn't really good news now that you're working for a company that does likewise but eh, what can one do? At least now you guys are forewarned what's coming. I HAD been doing a good job of not telling anyone before now.

[b3lha]

I'm really enjyoing the new job. Thanks for asking. The newer ECUs that I'm working with do out-of-order execution and that really messes with my mind. But I'm starting to get my head around it now.

I look forward to seeing your new windows ap. I may give it a try on my own car at some point.

You don't have to worry about competition. As I said, the company I'm working for does not have seem to have any interest in working on the older ECUs.

[Mrdjc]

Its good to see you have found a new job so quickly Phil! one which is of interest and relevance to your "hobby" is even better! I really did feel a bit sorry for you when you sent the email adress change, and was wondering if it was the end of your work as we know it!

I've not been busy doing any more analysis with my ECU at all, kind of lost interest, I've been focussing on the future!

I am in Slovakia at the moment for 2 weeks but returning Home tomorrow already!
I'm hoping to get a BE9 (2.5) in left hand drive over here once I (Hopefully) start my studies in Mechatronics! (Surprise Surprise) at the end of September.

As for your new job Phil, did you sign any contracts which prohibit you from continuing on here, or developing software/hardware which you are allowed to resell via your website?

Longassname, I take it the software will be a part of your package you are offering, not stand alone for general use monitoring, something like Evoscan? Also I'll be interested to see what price range you come up with!

I really hope the spirit of this thread continues, where people are helping other people for no financial gain, rather than everyone piecing their information together and selling it off in packages.
A lot of people on here have been fantastic in that regard.
I really hope that some day I can return the favour and help someone else learn and understand how things work.

All the best for everyone, and I hope we can continue to develop this thread further!

Cheers,
Daniel.

[longassname]

I don't believe the bitmaps were ever posted so here are the most important ones to improve your dissassembly and find useful things to modify:

FA0 78105A00
IG=ignition 08
AC 02
ID=idle 80
AP=AC Pressure 20
NT=neutral 01
PS=Power steering 10

FA1 78105B00
UD=test mode 02
RM=read memory 04
TR=torque control 20
PK=park 08
FC=49 states/ca

FA2 78119D00
R1=radiator main fan 08
R2=radiator sub fan 10
FP=fuel pump modulator 80
IH=induction solenoid valve 20

[Mrdjc]

What exactly are the Bitmaps for?
Also what vehicle are they off, Rom ID?

If they are the CEL Bitmaps, there's a lot of stuff on there mine doesn't have, and also a lot of stuff mine does have.

Or are they the bits which cause relays to switch on and off? (Power steering on mine hasn't got any sensors or electronics at all.)

I just spent 2 hours yesterday reading this thread from Page 1 to 62 all over again, fishing out bits of info.

I've got my hands on a spare ECU and loom, and have made a board up with connector blocks so its on a bench next to my PC and cup of coffee.
Its a 1996 EUDM Legacy 2.0GL (N/A) with the "T8" Ecu.
Hi-res pictures can be found in the thread Phil set up for me.
He has been helping me disassemble over at the subiesmart website in this thread here: http://www.subiesmart.com/forum/index.php/topic,44.0.html
There's a few people that have started doing it but never seem to have ended on that website, its nice as it deals with individual models of ECU in separate threads, rather than everyone hijacking a single one.

I am however looking for a way to dump segments of the Rom file, I noticed Nobiwan managed to do it, but it doesn't state which software he used.
I rather suspect its Linuxy stuff (Blashphemy to me!)
I'm wanting to dump the RAM at 1000 to 14FF only, and have no idea how to request blocks of data like that, I only know how to get the whole ROM (Rensu's software) or line for line (Hexcomtool).

Any input is appreciated :)

Cheers,
Daniel.

[longassname]

The bitmaps are for switches which can be i/o or just used internally. Actually, there are a few loop flags included in these bitmaps but I didn't include them in the documentation.

Here, I'll explaint he first one:

(FA0 78105A00):FA0 is the select monitor label for this bitmap. 78105A00 is the command sent to the ECU to read the memory location of the bitmap.
(IG=ignition 08): IG is the select monitor label for the bit indicating the ignition switch is on or off. 08 is the hexidicimal number matching the bit. In binary it is 00001000
(AC 02): Is the bit for the AC being on. In hex it is 02. In binary it is 00000010
(ID=idle 80): Is the bit indicating that the throttle is fully closed. In hex it is 80. In binary it is 10000000.
(AP=AC Pressure 20): Is the bit indicating that the pressure threshold for the trinary switch has been met. In hex it is 20. In binary it is 00100000
(NT=neutral 01): Is the bit indicating the selector lever is in neutral. In hex it is 01. In binary it is 00000001.
(PS=Power steering 10): Is the bit indicating that the power steering is under load. In hex it is 10. In binary it is 00010000.


So the bitmap we are calling FA0 is a single hex byte being read from the ECU. A byte is 8 bits, any or all of which can be 0 or 1. By looking for where they are read or set in the code you can find the code blocks that do things of interest. Sometimes they are copied and is the copy that is checked but usually bitmaps are checked directly and more importantly you look for where they are set with bit sets and exclusive ors.

[longassname]

Just to clarify..the bitmaps themselves are not i/o. They are copied to 2000's and 4000's addresses which are i/o.

[b3lha]

Thanks for posting that Michael.:) I knew some of them but not all. It's definitely good useful information.

I've been doing a lot of work with IDA on the later ROMs, so now I'm busy trying to get it working with the SVX rom. But I can't get their 7700 disassembler to track the M flag properly. :(

[longassname]

A page or 2 back I posted a schematic of the correct interface to use between the ecu and an ftidi ttl232r cable. If you use that you will get perfect reads every time on every ecu.

Phil would know more about what software is out there ready made to do what but I do know that the serial terminal tool he suggests for diagnostics of your serial port can take scripts. Most terminal programs do and many are free. You could write scripts to read the blocks you want. The ECU returns the command along with the requested byte so you'll also have to do a find replace with a wildcard in a text editor to strip them out.




I am however looking for a way to dump segments of the Rom file, I noticed Nobiwan managed to do it, but it doesn't state which software he used.
I rather suspect its Linuxy stuff (Blashphemy to me!)
I'm wanting to dump the RAM at 1000 to 14FF only, and have no idea how to request blocks of data like that, I only know how to get the whole ROM (Rensu's software) or line for line (Hexcomtool).

Any input is appreciated :)

Cheers,
Daniel.

[Mrdjc]

A page or 2 back I posted a schematic of the correct interface to use between the ecu and an ftidi ttl232r cable. If you use that you will get perfect reads every time on every ecu.

Phil would know more about what software is out there ready made to do what but I do know that the serial terminal tool he suggests for diagnostics of your serial port can take scripts. Most terminal programs do and many are free. You could write scripts to read the blocks you want. The ECU returns the command along with the requested byte so you'll also have to do a find replace with a wildcard in a text editor to strip them out.

The buggyness is a known issue with the VWRX Software, mentioned here: http://www.vwrx.com/forum/index.php?topic=183.0

The data itself is flawless when using hex com or Evoscan etc, its just a known issue between the VWRX software and the Ftdi cable.

And I am using the FTDI cable, as well a the "92 fix" as hijacked from Phil's page, which I put together according to this drawing:
(I think I've posted this drawing before, about 11 pages back July last year, Gosh, time flies!)

http://i219.photobucket.com/albums/cc137/Mrdjc/92fixschem.jpg

Interesting on scripting, I wasn't aware that was possible, I'll have a look at it, Phil has also informed me the program he has made for linux is able to do it in selected ranges,(available from here: http://www.alcyone.org.uk/ssm/software.html) I'll probably set up 2nd (3rd actually!) pc for that instead of Knoppix.

Cheers,
Daniel.

[longassname]

Daniel I'm familiar with the opamp "92 fix" but the circuit I posted is superior and doesn't require any adjustment to get it to work even on cars where the "92 fix" doesn't or barely works.

[longassname]

Sorry, I think I had only posted the schematic in the gearshift map thread. Here it is: http://www.ecutune.com/posts/ttl232r-selectmonitor.pdf

If you have a "92 fix" and it is working for you then by all means keep using it but anyone that has to build something new should build this interface.

[Mrdjc]

Thanks for that longassname, that looks much more simpler to create than the board I've made, and probably a lot more compact as well.

Just a few questions, what diodes are you using?
I take it the Diode "leg" of the drawing with resistor/gnd/5V joins onto both the RX and TX "leg"?
Im just a bit unsure as there is no dot to connect or a bridge to go over, but it looks fairly simple, what else would the thing be doing there! :lol:

Also what variation of the line driver are you using, I just noticed Philips makes a whole range, as does TI. Are you using the same chip twice (I noticed some support more than one line, bit like the Op-Amp) or two seperate chips?

Also interesting to see you've done both the RX and TX lines, is this really necesary? The data from the FTDI should be clear and strong, it was just the reply from the ECU that could turn into garbage at times. I suppose its better to be safe than sorry though.

Anyhow, great work, thanks for sharing :)

Cheers,
Daniel.

[longassname]

Hello Daniel,

The signaling levels used by the serial port of the ECU's processor are not ttl. The 74hc125 is designed to communicate with the same signaling levels as the processor in the ECU. It's the correct/matching driver for our ECU if you will. I use texas instruments chips sn74hc125n.

The diodes form what is called a clipping circuit. A diode tied to vcc clips the top of the signal at the vcc level. Vcc is the +5v from the ttl232r cable. A diode tied to Vss clips the signal to the Vss level. The output to the ECU is clipped on both sides. The input from the ecu is clipped low and pulled high. The solid back arrow heads (not the ones that are part of the diode symbol) are the symbol for a connection to Vcc. The arrow heads made of lines are the symbol for a connection to Vss.

In the diagram there are 2 gates (gates a and b) of 1 74hc125 chip (component U1).

[Mrdjc]

I never knew it wasn't TTL!:eek: See, you learn something new every day.:rolleyes:

What rating are the diodes?

Have you got any numbers handy for them? I'm quite keen to try this out :)

I was referring to the cross through the RX and TX line, I was always taught to stick in a dot where it joins on, and a bridge where it crosses over the top, as the straight cross could be mistaken for either, but I get the point of it :)

So the Op Amp is only knocking the input and output voltage one way or the other, as close as it can get (0V or 5V)? so a garbage 3.5V signal gets bumped up to 5V and a 0.4 gets knocked down to 0? Is that correct?

Bare with me as I'm still learning!

Does your setup also get better formatting back from the Hex Com tool and others?

I take it it could be adapted to be used for serial as well?

Regards,
Daniel.

[SVXdc]

Are you using the same chip twice (I noticed some support more than one line, bit like the Op-Amp) or two seperate chips?
In the diagram there are 2 gates (gates a and b) of 1 74hc125 chip (component U1).
[for anyone else who isn't familiar with 74x chips] The 74x125 parts have 4 gates on one 14-pin chip. You'll only use 2 of those gates for this circuit.

Each gate has an input, an output, and an output-enable pin. In Michael's circuit, the output enables are tied to ground (so they're permanently enabled).

BTW, it's good practice to ground the inputs of the other two unused gates. Also, to save a tiny amount of power, tie the Output Enable (OE) pins of those unused gates to Vcc instead of ground.

Also, his schematic doesn't show the Vcc and Vss (power and ground) connections to the 74x chip. It's common to omit those from a drawing, but you will need to connect those pins. :)

Also interesting to see you've done both the RX and TX lines, is this really necesary?
The 74HC125 is relatively cheap insurance. The ECU and the USB adapter would be much more expensive to replace if there were a voltage spike.

[SVXdc]

Pin 4 on the Select Monitor harness (which Subaru also refers to on its wiring diagrams as the "Data Link Connector") is connected to pin 5 of the Cruise Control Module. Has anyone determined what that pin does? The wiring diagrams show only those two things interconnected.

I've started making the older-style Subaru radio harnesses with both illumination wires. A byproduct will be extra 9-pin harnesses, which I'm planning to offer to people who want to build a Select Monitor / DLC port interface. These harnesses will have only the 4 wires needed for the Select Monitor (Black, Red, Green, and Violet for Ground, +12V, TxD, and RxD, respectively). Price will be just a few bucks. If interested, please e-mail me (see my harness for sale post (http://www.subaru-svx.net/forum/showthread.php?&threadid=6530)).

If we discover that the cruise control pin is useful for anything, I can throw in an extra wire so people can access it.

Also, the USDM SVX wiring diagrams (both '92 and '96) show DLC pin 8 connecting to pin c15 on the ECU. The DLC harness in my '96 has no wire there. Is that wire present in earlier years? If so, has anyone figured out what that pin does?

[b3lha]

Pin 4 on the Select Monitor harness (which Subaru also refers to on its wiring diagrams as the "Data Link Connector") is connected to pin 5 of the Cruise Control Module. Has anyone determined what that pin does? The wiring diagrams show only those two things interconnected.

I've started making the older-style Subaru radio harnesses with both illumination wires. A byproduct will be extra 9-pin harnesses, which I'm planning to offer to people who want to build a Select Monitor / DLC port interface. These harnesses will have only the 4 wires needed for the Select Monitor (Black, Red, Green, and Violet for Ground, +12V, TxD, and RxD, respectively). Price will be just a few bucks. If interested, please e-mail me (see my harness for sale post (http://www.subaru-svx.net/forum/showthread.php?&threadid=6530)).

If we discover that the cruise control pin is useful for anything, I can throw in an extra wire so people can access it.

Also, the USDM SVX wiring diagrams (both '92 and '96) show DLC pin 8 connecting to pin c15 on the ECU. The DLC harness in my '96 has no wire there. Is that wire present in earlier years? If so, has anyone figured out what that pin does?

In the select monitor code there is an extra step involved when sending commands to the cruise control unit. I think it must be some sort of flow control using that wire. But LAN opened up his SSM and found the wire is not connected internally. It doesn't make much sense.

http://www.subaru-svx.net/forum/showpost.php?p=593005&postcount=127
http://www.subaru-svx.net/forum/showpost.php?p=593005&postcount=128

It would be nice to learn a little more about how the cruise unit works. I wonder if it is possible to simulate a drive by wire throttle by using a laptop to adjust the cruise speed up and down. That would open up all kinds of cool tricks. For example: using some sort of range finder to match speed to the car in front, or using GPS and setting the car to follow the prevailing speed limits.

[SVXdc]

In the select monitor code there is an extra step involved when sending commands to the cruise control unit. I think it must be some sort of flow control using that wire. But LAN opened up his SSM and found the wire is not connected internally. It doesn't make much sense.

http://www.subaru-svx.net/forum/showpost.php?p=593005&postcount=127
I found that thread and your post after I posted my message above.

I'm not too surprised about the apparent dead code — all sorts of remnants can get left in "production" code when people are on a tight schedule. Perhaps at one point they thought they needed the flow-control, but realized they didn't (or later fixed something in the cruise module).

Does the ECU talk to the Cruise module (or A/C module) across that serial channel, or is the serial used only by the select monitor (and our laptops)?

How about pin 8? Is that wire populated on any other years/markets?

[Elaine]

Bellow is the interface I'm using to read the ECU memory.
Here is the full story. I have a '92 model. In my first attempt to read my car's ECU I used the circuit found at alcyone.org.uk. It worked very well with the engine turned off but failed when I turned the engine on. By playing with the potentiometer adjustment I could make it working with the engine on as well. Since the beginning I wasn't happy with the potentiometer idea but having different adjustments for engine on/off was already too much. So I brought my scope and played a bit with the adapter I built. Here are my findings:
- The ECU input looks like a pulled up one. I played with the pull down current and I found that for a good "0" I need to "suck" at least 10 mA.
- The ECU output is a 1Vpp signal (1.2Vpp with the engine off for whatever reason) with a DC component of half of the car battery voltage. The fact that the car battery moves from 12.6V to 13.8V when the engine is on explains why the potentiometer needed to be adjusted again.
- With the engine on, both the 12V and the ECU output lines were affected by some 0.4Vpp noise but it was identical on both lines.

So I decided to change the classic design well known already by powering the analog interface to 12V and make the conversion to TTL after that. I ended up using the LM393 which has an open collector output so the interface to the 5V circuitry becomes a pull up resistor. Moreover, this device doesn't need any additional protection circuitry for this application.
For the RS232 interface I used the MAX231 but any RS232/USB transceiver can be put instead. D4 which is a Ge diode is used to move down the comparator threshold by 0.1V. It doesn't make a big difference, it can be removed. If you want to build this circuit don't use any other diode instead, it will ruin your threshold level. Also, don't use any filtering capacitor in parallel with R6, it won't help. R5 and R6 should have the same value with 1% tolerance.

I'm not sure if my ECU works properly or not (it's the only one I played with), although what I can see on my scope make sense to me. The beauty of this circuit is that it's simple, doesn't create any stress on both the ECU and the adapter itself and doesn't need any tuning, it's plug and play. If you play it right you can get even LM393 free samples....

[longassname]

You may want to take a look at the routines storing between 12d0 and 1318and between 1318 and 1338. You should find that's where the learned data is stored. The default values for the first range are 8000 and the default values for the 2nd range are 0000. You'll find the thresholds you were mentioning wanting to know compared in those routines as well.


Thanks for posting that Michael.:) I knew some of them but not all. It's definitely good useful information.

I've been doing a lot of work with IDA on the later ROMs, so now I'm busy trying to get it working with the SVX rom. But I can't get their 7700 disassembler to track the M flag properly. :(

[b3lha]

Thanks Michael, I'll look into that.

It's been a long time since I've been able to work on this project. I hope to get back into it soon.

Have you seen the per-cylinder timing adjustments? It's at address 8708 in rom 742512 (94 JDM). There are four sets of 6 bytes that get added onto the ignition advnce. The 1st byte for cylinder 1, the 2nd for cylinder 2, the 3rd for cylinder 3 etc. The ECU chooses one of the 4 sets based on some rpm thresholds at 8700 through 8703 and throttle thresholds at 8704-8705.

The adjustments are all zero by default, but you use them to fine tune the spark timing on each cylinder.

[longassname]

Sounds like good stuff to add to the definitions files for my ECUtuner software. I just updated the sample definitions file I posted earlier with a more complete one. If you get a chance, if you could check it for mistakes and add anything good you know that I don't have on it that would be great. It's already complete enough for some heavy duty end user tuning.

http://www.ecutune.com/posts/definitions.xls

Thanks Michael, I'll look into that.

It's been a long time since I've been able to work on this project. I hope to get back into it soon.

Have you seen the per-cylinder timing adjustments? It's at address 8708 in rom 742512 (94 JDM). There are four sets of 6 bytes that get added onto the ignition advnce. The 1st byte for cylinder 1, the 2nd for cylinder 2, the 3rd for cylinder 3 etc. The ECU chooses one of the 4 sets based on some rpm thresholds at 8700 through 8703 and throttle thresholds at 8704-8705.

The adjustments are all zero by default, but you use them to fine tune the spark timing on each cylinder.

[RoughSilver92]

So I have began an attempt to analyze the assembly code of the US ECU on Phil's page. This is all pretty new to me, I must admit, but I am fairly persistent and can usually figure things out pretty well with a little guidance. I need some guidance!

So far I have gone through and labeled all of the addresses that have been documented by Phil, Tom, Mike, and others. I am at the point that I am marking all commands accessing the memory between 8000 and 8fff that have not yet been documented and I just want to make sure my understanding is correct:

When an address with a final character other than 0 is accessed, such as "0x86a1" does the 1 indicates the first hex number in the 86a0 line?

This is the assumption I have been operating under, as it is the only logical explanation to me, but a confirmation that this is correct would make me feel better. I just finished a semester of Intro to C++, but as you all know this assembly language is a whole other thing!

[b3lha]

So I have began an attempt to analyze the assembly code of the US ECU on Phil's page. This is all pretty new to me, I must admit, but I am fairly persistent and can usually figure things out pretty well with a little guidance. I need some guidance!

So far I have gone through and labeled all of the addresses that have been documented by Phil, Tom, Mike, and others. I am at the point that I am marking all commands accessing the memory between 8000 and 8fff that have not yet been documented and I just want to make sure my understanding is correct:

When an address with a final character other than 0 is accessed, such as "0x86a1" does the 1 indicates the first hex number in the 86a0 line?

This is the assumption I have been operating under, as it is the only logical explanation to me, but a confirmation that this is correct would make me feel better. I just finished a semester of Intro to C++, but as you all know this assembly language is a whole other thing!

Yes. That is exactly right. My hex dump program just writes out 16 bytes on a line for convenience. So 86a0 is the first byte on the line, 86a1 is the second.....86af is the last.

There's a few threads on SubieSmart that might help you get started.

http://www.subiesmart.com/forum/index.php/topic,26.0.html
http://www.subiesmart.com/forum/index.php/topic,43.0.html
http://www.subiesmart.com/forum/index.php/topic,44.0.html

Good luck.

[RoughSilver92]

Great information and links. I read on the one of the posts that bits are read from right to left, and have noticed a discrepancy between the bitmap definitions posted by LAN and the diagnostics codes listed on your site. I believe that the bits are labeled backwards on the definitions spreadsheet, for example the crank angle bit for 1026 on the spreadsheet is labeled as hex 01 when it should in fact be hex 80. Is this correct?

[b3lha]

Great information and links. I read on the one of the posts that bits are read from right to left, and have noticed a discrepancy between the bitmap definitions posted by LAN and the diagnostics codes listed on your site. I believe that the bits are labeled backwards on the definitions spreadsheet, for example the crank angle bit for 1026 on the spreadsheet is labeled as hex 01 when it should in fact be hex 80. Is this correct?

You're right. There's a discrepancy. One of us has got it backwards and I think it's LAN:

If you look for the "seb" (set bit) insructions, you can see that bits 0x01, 0x02, 0x04, 0x08, 0x80 and 0x20 of address 0x1028 are all set in the same subroutine. These correspond to the six injectors error codes 14,15,16,17,18 and 19. It makes sense that the six injectors would be tested in the same subroutine. So I think I've got it right on my website.

(The "test injectors" subroutine is address 9F5B in rom 722527)

As you said, the crank angle sensor error is bit 7 (0x80) of address 0x1026.

[longassname]

Thanks, I'll fix it right now.

[longassname]

Ok, should be right now. I had copied and pasted the switches from one of my spreadsheets and the error codes from Phil's website and my sheet is layed out in hex order and his in binary.

[longassname]

I need to add the definitions for a few tables that are scaled by load but asside from that I think the definitions file is pretty complete. The tables I just mentioned are the only things I ever edit that I don't already have in the definitions file.

[longassname]

Phil,

Does your dissassembler comment defined locations?

[b3lha]

Phil,

Does your dissassembler comment defined locations?

Yeah, I think the one Calum sent me does that.

I normally disassemble to a text file, without comments, and then I run a sed script that does a regex search and replace in the text file:

eg. search for lines containing 106F and append " ; RPM " at the end of the line. Something like this:

s/(^.*106f.*$)/\1; RPM/g

[RoughSilver92]

That sounds a lot better than going through the document with the find feature for every address and typing/pasting the description like I have been doing. It only took about three days of working on it on and off, but I have everything that has been documented labeled! Now I can begin attempting to unravel the code so I can see what exactly is happening. I also want to try to define every bit of 8000-8fff. This is everything we are able to modify (i think) so it would be nice to know what every piece does does and what it affects.

[b3lha]

That sounds a lot better than going through the document with the find feature for every address and typing/pasting the description like I have been doing. It only took about three days of working on it on and off, but I have everything that has been documented labeled! Now I can begin attempting to unravel the code so I can see what exactly is happening. I also want to try to define every bit of 8000-8fff. This is everything we are able to modify (i think) so it would be nice to know what every piece does does and what it affects.

Which ROM are you looking at? 722525? I'll post whatever info I have about it in case it helps you.

Most likely people will modify the maps and constants between 8000 and 8fff. But it is also possible to carefully modify the program code too. Paul in Uganda has added a launch control feature to his 95 impreza by doing just that. He just changed the program to use a lower rev limit when the vehicle speed is below a certain threshold.

[RoughSilver92]

Yes-722525.
So when you burn the chip you burn the code in as well or do you have to modify the program some other way? I was under the impression only 8000-8fff was burnt.

[b3lha]

Yes-722525.
So when you burn the chip you burn the code in as well or do you have to modify the program some other way? I was under the impression only 8000-8fff was burnt.
The chip replaces the entire eprom from 8000 to FFFF.

[b3lha]

Here's a zip of my 722525 directory. I was working mainly on the JDM rom 742512, so there's not much to see. It's been so long since I worked on it that I can't really remember what state it's in, but maybe you will find something helpful in it.

I split the disassembly up into different files for each subroutine and started naming the subroutines according to what I thought they did. You can easily find the different maps by looking for calls to the graph lookup subroutines and seeing what parameters are passed in.

Don't assume any of it is accurate, because it's undoubtedly full of mistakes.

[RoughSilver92]

I don't see the file. I look forward to it.

[b3lha]

Sorry. I'm an idiot. Here you go.

[RoughSilver92]

Nice.
Now I am slightly stuck with these eor commands. I've looked it up in the software manual, but the explanation doesn't make it any clearer for me. May as well make sure about the sbc also.

00E22D A422 ldy dp + 0x22 ; Read from A/D successive approximation register
00E22F 98 tya
00E230 38 sec
00E231 EDD411 sbc ax, 0x11d4
00E234 B004 bcs 0xe23a
00E236 49FFFF eor ax, #0xffff

So here the tps value from the A/D converter is loaded to index register y.
It is then transferred to register a.
The carry flag is set (C=1).
The value stored at 11d4 is subtracted from register a.
If the result is greater than or equal to zero the program branches to e23a.
I know this much.
With the carry flag set does it also subtract 1 from register a (ie. A=A-(0x11d4 +1))?
What does the eor compare? We have the value in register a and the hex value ffff, but what about them? There doesn't seem to be enough values to do anything with.

It looks like the majority of the eors use #0xff or #0xffff. I don't know what the significance of this is. Right now it is just an observation.

[b3lha]

Nice.
Now I am slightly stuck with these eor commands. I've looked it up in the software manual, but the explanation doesn't make it any clearer for me. May as well make sure about the sbc also.

00E22D A422 ldy dp + 0x22 ; Read from A/D successive approximation register
00E22F 98 tya
00E230 38 sec
00E231 EDD411 sbc ax, 0x11d4
00E234 B004 bcs 0xe23a
00E236 49FFFF eor ax, #0xffff

So here the tps value from the A/D converter is loaded to index register y.
It is then transferred to register a.
The carry flag is set (C=1).
The value stored at 11d4 is subtracted from register a.
If the result is greater than or equal to zero the program branches to e23a.
I know this much.
With the carry flag set does it also subtract 1 from register a (ie. A=A-(0x11d4 +1))?
What does the eor compare? We have the value in register a and the hex value ffff, but what about them? There doesn't seem to be enough values to do anything with.

It looks like the majority of the eors use #0xff or #0xffff. I don't know what the significance of this is. Right now it is just an observation.

Very good work Andy. I'm impressed.

On this type of processor, you have to set the carry flag before a subtraction in order to get the right answer. If you look through the code you'll see an SEC before every SBC.

I can't explain it very well, but the reason is that the subtract instruction is designed so that when you are subtracting 16bit numbers, you can do it in 2 chunks of 8 bits at a time. The carry flag stores the sign of the result of each subtraction and it gets fed into the next stage of the subtraction. There's an example of this at EC68 where it subtracts a 16 bit value at 1098(and 1099) from a 16 bit value at 1096 (and 1097). But It's not really important to understand how that mechanism works, as long as you can recognise when you see it.

EOR, also known as XOR, is a boolean "exclusive-or" operation. It means either/or but not both. If you want to XOR two 8 bit numbers, you line them up on top of each other and calculate each column separately. The result is 1 if the bits are different and 0 if they are the same.

11000011
10101110
---------
01101101

An XOR by FF, in the case of a byte, or FFFF in the case of a word, is the same as a NOT operation. Every zero will be changed to a 1 and every one will be changed to a zero.

This piece of code here:

00E236 49FFFF eor ax, #0xffff
00E239 3A inc ax

Does a NOT of AX register and adds one. In "two's-complement" arithmetic, this is how you convert a negative number to a positive number or vice-versa.
For example:
11111011 is -5. If you XOR by FF (11111111) you get 00000100 which is +4. Add 1 and you get +5.

So the code is saying, do the subtraction, and if the result is negative, convert it to positive. If the result is positive then it jumps over that bit of code and continues with the positive value.

I hope that makes sense.

[RoughSilver92]

That makes perfect sense. Sorry to bombard you with these big chunks of code, but I think they can be summed up easily and I want to verify I have the fine details correct as it seems a little strange.

Code block address: E208 Length: 110 M:1 X:0 called by: E383
00E208 AE3610 ldx 0x1036 ; Call target from E383 ; TPS_Voltage
00E20B 8ED211 stx 0x11d2
00E20E 342008FC bbc #0x08, dp + 0x20, 0xe20e ; Read from A/D control register, Branch target from E20E
00E212 A622 ldx dp + 0x22 ; Read from A/D successive approximation register
00E214 642004 ldm #0x04, dp + 0x20 ; Write to A/D control register
00E217 8622 stx dp + 0x22 ; Write to A/D successive approximation register
00E219 D8 clm ; m:0 x:0
00E21A 8A txa
00E21B 38 sec
00E21C EDD411 sbc ax, 0x11d4
00E21F B004 bcs 0xe225
00E221 49FFFF eor ax, #0xffff
00E224 3A inc ax
00E225 8D0410 sta ax, 0x1004 ; Branch target from E21F
00E228 34200800FB bbc #0x0008, dp + 0x20, 0xe228 ; Read from A/D control register, Branch target from E228
00E22D A422 ldy dp + 0x22 ; Read from A/D successive approximation register
00E22F 98 tya
00E230 38 sec
00E231 EDD411 sbc ax, 0x11d4
00E234 B004 bcs 0xe23a
00E236 49FFFF eor ax, #0xffff
00E239 3A inc ax
00E23A CD0410 cmp ax, 0x1004 ; Branch target from E234
00E23D B001 bcs 0xe240
00E23F BB tyx
00E240 8ED411 stx 0x11d4 ; Branch target from E23D
00E243 8A txa
00E244 4A lsr ax
00E245 4A lsr ax
00E246 F8 sem ; m:1 x:0
00E247 8D8C12 sta al, 0x128c ; SM_TPS
00E24A D8 clm ; m:0 x:0
00E24B 8A txa
00E24C 8D3610 sta ax, 0x1036 ; TPS_Voltage
00E24F F8 sem ; m:1 x:0
00E250 A24E10 ldx #0x104e



So here it is basically just reading the tps value from the A/D converter twice in a row and comparing it to the previous tps value (11d4). It stores the difference (absolute value) of the first read/comparison at 1004. It compares the difference (absolute value) of the second read/comparison with 1004 and stores the TPS value corresponding to the smallest difference at 11d4. Then the value is converted to 8 bit and stored at 128c(SM TPS). The value is stored in 16 bit at 1036(TPS volts).

I am doubting my understanding of the carry flag here. I would assume that the program would want the bigger change, but the way I read it if the second read/compare is greater than or equal to the first the program skips over the command to transfer the contents of y (second read/compare) to x and stores the tps value corresponding the first (and smaller change) tps value.



I will take the easy route here and I will say that the program has detected a fault with the tps and the bit corresponding to a tps error has been set.

[QUOTE=]
Code block address: E276 Length: 9 M:1 X:0 called by: E253
00E276 AD238B lda al, 0x8b23 ; Branch target from E253
00E279 0C251001 seb #0x01, 0x1025
00E27D 800D bra 0xe28c

Code block address: E27F Length: 23 M:1 X:0 called by: E270
00E27F 2C1E102012 bbs #0x20, 0x101e, 0xe296 ; Branch target from E270, Branch target from E274
00E284 0C1E1020 seb #0x20, 0x101e
00E288 1C251001 clb #0x01, 0x1025 ; Branch target from E296
00E28C 9500 sta al, dp + 0x00 + ix ; Branch target from E27D, Branch target from E292
00E28E CA dex
00E28F E04410 cpx #0x1044
00E292 D0F8 bne 0xe28c
00E294 8040 bra 0xe2d6



So here I believe a default 8 bit value (hex 14 if I read it right) is loaded from the rom to A.
bit 01 of 1025 is set and the program branches to e28c where e28c-e292 is executed 11 times total(104e-1044). During this loop the default value (in this example) that has been loaded into A is stored 11 times somewhere (dp + 0x00 + ix). I am pretty sure that the 104e-1044 makes up the ix portion of the equation, so is it just 104e-1044 that the value is written to?


00E2D6 8D4410 sta al, 0x1044 ; Branch target from E294
00E2D9 8D8512 sta al, 0x1285 ; Write to RAM: TPS
00E2DC 8D1840 sta al, 0x4018
00E2DF 60 rts


Cakewalk. Store the value in A at 1044 (seems redundant if my guess at where A is being stored above is correct).
Store the value in A at 1285.
Store the value in A at 4018.
Return.

[RoughSilver92]

That code came out pretty hard to read. I meant to mention that bit 01 at 1025. It seems like some sort of indicator that a default value has been loaded, but I don't see anywhere else in the program where that bit is specifically looked at. Main things making me scratch my head are the dp + 0x00 + ix and if i interpreted the carry flag correctly.

[b3lha]

I don't really understand how the A/D converter works, except that it somehow converts an input voltage to a binary number. If you want to know, read chapter 9 of the 7733 User Manual on the Renesas site. It's not exactly the same CPU as ours, but it is similar.


http://documentation.renesas.com/eng/products/mpumcu/e7733um.pdf


You are exactly right when you say that
the value is converted to 8 bit and stored at 128c(SM TPS). The value is stored in 16 bit at 1036(TPS volts).

You are almost right about the next bit too. The ECU stores a history of the last 11 TPS readings between 1044 and 104e. This is so it can tell if you are increasing or decreasing throttle and how quickly you are doing it. It uses this information for things like "tip-in enrichment".

It looks to me as though bit #20 of 101e indicates whether the history buffer has been initialised. If the history buffer has not been initialised, then it is filled with the TPS value, or a default value if the TPS error flag is set. I think you are right that bit #01 of 1025 indicates whether the value is real or default.

If the buffer has already been initialised, then the code at E2C6 shifts it along one byte and then the new value is inserted at 1044.

Phil.

Edit: I forgot to mention, the value of dp is always 0 on this system, so you can ignore it. "sta al, dp + 0x00 + ix" just means " store AL at address 0+X"

[RoughSilver92]

Thanks Phil
Great info as usual. I didn't realize that the comparison thing that was going on there was part of the A/D logic(?). I guess in retrospect it doesn't matter how it chooses the value that the program uses. What is important is how the value(s) it does choose interact with the rest of the program. I need to try to stay focused on that. Just from what I have had a good look at so far I can see I should be able to find more things to label, like 1243 and 12c8 seem to hold either default values or (TPS Volts) dependent on certain conditions. I think I have a long road ahead of me breaking down each function into simple if/else statements then trying to pull it all together and make like a flow chart describing the program.

About these little Indians:

00008660 80 80 FF 66 00 0A 00 64 82 14 0A FF 02 24 02 02


In the chunk of code below when loading and adding the 16 bit values conventional thinking says 8663 contains 66 00 or 26,112(I think). Since it is little endian is it really a 00 66 or 102? Same with adc ax,8665, is it really adding 00 0a (10) or 0a 00 (2560)?

00E323 D8 clm ; m:0 x:0
00E324 AD6386 lda ax, 0x8663
00E327 8DC812 sta ax, 0x12c8
00E32A 18 clc
00E32B 6D6586 adc ax, 0x8665
00E32E 8D4312 sta ax, 0x1243
00E331 F8 sem ; m:1 x:0

[b3lha]

About these little Indians:

In the chunk of code below when loading and adding the 16 bit values conventional thinking says 8663 contains 66 00 or 26,112(I think). Since it is little endian is it really a 00 66 or 102? Same with adc ax,8665, is it really adding 00 0a (10) or 0a 00 (2560)?

8663 is 0066
8665 is 000A

At some point you'll discover a nasty little trick in the code where they write a 16 bit value to an address and then never use it.:confused: Sometimes, they just read the high byte from (address+1) and use that instead of the whole 16 bits.

There's also some 24-bit numbers. Again, these are stored low byte first, high byte last.

[RoughSilver92]

Sweet. I have run into something like what you are talking about here:

00E25F A90000 lda ax, #0x0000
00E262 89090058 mpy #0x5800 ; Branch target from E25D
00E266 8928 xab
00E268 8D0410 sta ax, 0x1004
00E26B F8 sem ; m:1 x:0
00E26C 42AD0510 lda bl, 0x1005
00E270 F00D beq 0xe27f


I didn't include it but if A is greater than or equal to 0 e25f is skipped and the value in A is multiplied by hex 5800. So it looks like either A or hex 0000 is multiplied by hex 5800. Then the xab followed by the sta ax, 0x1004 is swapping A and B (necessary because of the way the processor works, I suppose), putting the most significant 16 bit value in A and storing it at 1004. Then the most significant 8 bit value is loaded into bl from 1005. The program then branches to e27f if the zero flag is set, but set by what? Is it set if the value loaded into bl is 0? Or is it looking way up at the mpy to see if that equals zero?

[SVXRide]

Phil, et al,

This thread has definitely been interesting reading :cool: Any thoughts on the end result of all this hard work? Is it realistic to think that it will be the ability to reprogram (flash) our stock ECU like the WRX/STi folks can?

-Bill

[RoughSilver92]

AFAIK you cannot "flash" these ECUs like the OBD2 ECUs. You can build a board and burn chips as Phil describes on his site. Most of the useful parameters are documented and can easily be changed and burnt to a new chip. I am trying to analyze the code using the information others have already found as a starting point. I hope to understand some of the finer points of the program.

[b3lha]

Phil, et al,

This thread has definitely been interesting reading :cool: Any thoughts on the end result of all this hard work? Is it realistic to think that it will be the ability to reprogram (flash) our stock ECU like the WRX/STi folks can?

-Bill

I don't think there is any definite target as such. I think it would be great if we could uncover enough information about how the ECU works that technically skilled owners could have a go at tuning their cars themselves.

It is definitely realistic. We are actually really close to that point right now. We have a well-tested memory adapter design. We know where to find the fuel and timing maps and approximately how they work. All that's really needed is for somebody with tuning skills to fiddle with those maps and log the results and prove that they do work the way we think they do.

So many people have contributed to this thread and I'm amazed at the amount of good stuff has come out of it, directly or indirectly:

* An interface cable for connecting a PC to the car.
* Software that can display and log the ECU and TCU data.
* The locations of the parameters in the ECU and TCU.
* The TCU pin A4 power mode mod for USDM cars.
* The TCU software power mode mod for Euro/Aussie cars.
* A collection of ROM versions from different years and markets.
* A document showing the tuning differences between markets.
* A method for chipping the TCU.
* A daughterboard to adapt the ECU for modern eeproms.
* Decoding the TCU shift and torque converter maps
* Decoding some of the ECU maps
and finally, on a personal note,
* I got a full time job cracking ECUs.

That's just off the top of my head. There's probably a load of other stuff I can remember right now. And it doesn't include stuff outside the SVX world. I regularly get emails from people thanking me for information they've taken from my website and used for their own projects.

I'm particularly pleased that we cracked the TCU. I think we were the first people ever to crack the subaru TCU. In fact I've never heard of any car club cracking a TCU before.

I just wish I had more time to devote to it. I now have a two year old daughter and a 2 month old son, that I didn't have when I started this thread.

[b3lha]

Yeah, don't get me wrong. You can't "flash" these ECUs. They are too old. Flash chips were not available when these units were designed. To modify the ECU, you modify the rom file, burn it into two chips, plug them into the adapter and then plug the adapter into the ECU.

It's not hard to do, but it's not quite as easy as just hooking up a cable like the WRX guys do. In some ways it's better. The flashable ECUs can only be flashed a certain number of times and then they die and they're expensive to replace. With ours, you can replace the chips as often as you like.

(I suspect the OBD2 SVX ECU may be flashable, but I've never seen one and I don't know for sure one way or the other).

[b3lha]

Sweet. I have run into something like what you are talking about here:


I didn't include it but if A is greater than or equal to 0 e25f is skipped and the value in A is multiplied by hex 5800. So it looks like either A or hex 0000 is multiplied by hex 5800. Then the xab followed by the sta ax, 0x1004 is swapping A and B (necessary because of the way the processor works, I suppose), putting the most significant 16 bit value in A and storing it at 1004. Then the most significant 8 bit value is loaded into bl from 1005. The program then branches to e27f if the zero flag is set, but set by what? Is it set if the value loaded into bl is 0? Or is it looking way up at the mpy to see if that equals zero?

Yes. It's setting a minimum value of 0 to A. ie. Following the subtraction, if A has become negative, set it to zero.

The Z flag gets set if zero is loaded to bl. I think this code wants to end up with a number between 00 and FF in AL. If BL is not zero (ie. the result of the calculation is >= hex 100) then it sets AL to the maximum value of FF.

[SVXRide]

AFAIK you cannot "flash" these ECUs like the OBD2 ECUs. You can build a board and burn chips as Phil describes on his site. Most of the useful parameters are documented and can easily be changed and burnt to a new chip. I am trying to analyze the code using the information others have already found as a starting point. I hope to understand some of the finer points of the program.

Yep, I understand you can't flash our ODB1 ECU - in its stock condition;) I was hoping that maybe this was leading to replacing the ROM with a "flashable" version :cool:
-Bill


Phil,
Can't thank you enough for all the work you've done to date!
-Bill

[RoughSilver92]

Oh, that would be cool. I don't know if anybody is working towards that goal, Phil would be the most likely to be in the know on that.
I know there are programs out there that let you make changes with the vehicle running without having to burn new chips every time, but I don't remember reading if any have been used with the SVX ECU.

[longassname]

It sounds like what you are describing is the use of a device/devices called emulators. An emulator/emulators are hooked up to the ECU instead of a ROM and "emulate" the ROM. You load the firmware into the emulator which then functions as the memory for the ECU. For real time tuning an emulator which is capable of being updated without disrupting program execution is used. This means you can edit the data on it without disrupting its ability to be read by the ECU.

typically you see tuning software which allows you to load a binary image of the firmware and then edit tables/data in some user friendly manner....

some/nowadays a lot of tuning software also allows you to load that binary into an emulator so that you can make your edits and see the results while you operate the car

After you are done making your edits you write your new firmware to a ROM

[SVXRide]

It sounds like what you are describing is the use of a device/devices called emulators. An emulator/emulators are hooked up to the ECU instead of a ROM and "emulate" the ROM. You load the firmware into the emulator which then functions as the memory for the ECU. For real time tuning an emulator which is capable of being updated without disrupting program execution is used. This means you can edit the data on it without disrupting its ability to be read by the ECU.

typically you see tuning software which allows you to load a binary image of the firmware and then edit tables/data in some user friendly manner....

some/nowadays a lot of tuning software also allows you to load that binary into an emulator so that you can make your edits and see the results while you operate the car

After you are done making your edits you write your new firmware to a ROM

Bingo! Give Michael the gold star! :D
Having experienced first hand what the Hydra does for my 2v7/370cc/cams/etc...etc... SVX, I would love to have a less expensive option that would not require a MAF and would allow for dyno tuning as the engine/car "evolves"
-Bill (still putting $$ away in his Hydra fund....)

[longassname]

Unfortunately there aren't any 16 bit emulators which can be updated without interupting reading that don't cost $$$$$$$$$$$$$$$$

You can use 2 8 bit emulators though.

[b3lha]

Calum built an emulator for the Nissan guys and he was going to build an SVX version too, but I think not enough people were interested to make it worth his while.

Rob Files was working on an emulator for the early WRX ECU and it will work on our ECU too. I haven't heard from him in a while so I don't know whether he's finished it or not.

If you want to run without a MAF then it is possible, but you need an alternative way of figuring out how much air is going into the engine.

The Stock ECU has a fallback method which it uses if the MAF fails. IIRC It uses a map to estimate the airflow based on RPM and Throttle angle. If you unplug the MAF sensor, then start the car, it will run (badly) but it will throw a MAF error code. Obviously the map is calibrated for the stock intake. But I don't think it would be too hard to turn off the error code and update the map to cope with a modified intake. It won't ever run as good as using a MAF sensor though.

The stock ECU fallback method won't work for Forced Induction. For that you need a MAP sensor and you need to modify the program to use RPM and Manifold Pressure instead of RPM and Throttle Angle. That's a difficult project and even then it won't run as good as using MAF.

I'm no expert but I think the best solution is to keep the MAF, but use a bigger one, like LAN does with the stage 3.

[longassname]

If you are afraid the mass air meter is a restriction or it's just easier to plumb or whatever you can use two of them. The voltage is just averaged. You can put two SVX meters in and divide your K constant by 2 since the average voltage is representative of 1/2 of the total mass of air going in the engine.

I suspect you are more interested in running a map sensor because you have been told the mass air meter is too slow and causes a lean tip in. Mass air meters are slow but that is corrected for with the throttle enrichments. If the throttle enrichments need to be adjusted the throttle enrichments need to be adjusted. That's not really a reason to switch to map in and of itself.

I would imagine your best bet for switching to a map sensor is to wire it in place of the mass air meter, fill your primary fuel revision table with something safe like 12.7 and adjust the k constant and then start adjusting the air meter translation table while running on an emulator on a loading dyno in order to get it to actually run a 12.7 afr all the way from idle to max flow. Presumably you wouldn't max out your map sensor so you'd have to interpolate the higher airflows. With that done you'd be back to running right and ready to put real values in your fuel and timing tables. You'd have to redo this anytime you made mechanical modifications to the engine or induction system. That's why mass air systems are generally considered superior to speed density systems (map sensors).


I suspect any performance increases you felt running the hydra were actually from running more timing than for the theorized reasons. You can do the same thing with the stock ecu by taking the timing out of the revision table and adding it to the primary table. Once this is done you are no longer relying on the knock sensors to advance your timing to a performance level which has proved to be a problem for a lot of people. That's what I do in my aggressive software and it worked very well.

[NeedForSpeed]

I don't think there is any definite target as such. I think it would be great if we could uncover enough information about how the ECU works that technically skilled owners could have a go at tuning their cars themselves.

It is definitely realistic. We are actually really close to that point right now. We have a well-tested memory adapter design. We know where to find the fuel and timing maps and approximately how they work. All that's really needed is for somebody with tuning skills to fiddle with those maps and log the results and prove that they do work the way we think they do.

So many people have contributed to this thread and I'm amazed at the amount of good stuff has come out of it, directly or indirectly:

* An interface cable for connecting a PC to the car.
* Software that can display and log the ECU and TCU data.
* The locations of the parameters in the ECU and TCU.
* The TCU pin A4 power mode mod for USDM cars.
* The TCU software power mode mod for Euro/Aussie cars.
* A collection of ROM versions from different years and markets.
* A document showing the tuning differences between markets.
* A method for chipping the TCU.
* A daughterboard to adapt the ECU for modern eeproms.
* Decoding the TCU shift and torque converter maps
* Decoding some of the ECU maps
and finally, on a personal note,
* I got a full time job cracking ECUs.

That's just off the top of my head. There's probably a load of other stuff I can remember right now. And it doesn't include stuff outside the SVX world. I regularly get emails from people thanking me for information they've taken from my website and used for their own projects.

I'm particularly pleased that we cracked the TCU. I think we were the first people ever to crack the subaru TCU. In fact I've never heard of any car club cracking a TCU before.

I just wish I had more time to devote to it. I now have a two year old daughter and a 2 month old son, that I didn't have when I started this thread.


Phil, that's an impressive list, so very much to be proud of :)
Congrats, and continued success :D
Ron

[longassname]

you figured out and documented the solenoid a duty cycle too...that's pretty cool too

[longassname]

Hey Phil,

Someone asked me an intersting question today for which I don't have the answer and thought I would pass on to you in case you are interested in/willing to look into it.

He asked me how the ecu handles when to start fuel injection. Not the pulsewidth but the timing of fuel injection in relation to crank position/valve opening. I remember the factory service manual mentioning timing fuel injection to end as the valve is opening. It might be fruitful to be able to adjust this.

[SVXRide]

Michael/Phil,

1. I'm already running a z32 MAF with the ECUTune 2v7 chip and 370cc injectors (among other things;))
2. My Hydra experience was, unfortunately, limited to the better part of a single day. What struck me most, from just a driveablity standpoint, was that I suddenly didn't have to worry about the car stalling when I came to a stop sign/light and had to push the clutch in (yeah, it's also got a 5 spd). The car just idled smoothly with no drop in rpms beyond the stock 500-700 rpm setting. Was it quicker? Absolutely, but this could very well be due to the ability to run more timing than the 2v7 chip allows.
3. Yeah, I was thinking if we could replace the MAF with a MAP.

Thanks again for all your hard work!
-Bill

[RoughSilver92]

I'm not Michael of Phil, but I'll put my 2 cents in.
The 5 speed stall stumps me. While I was in the middle of my 5MT swap I read and reread everything about the 5MT stall, trying to figure out what to do about the problem I was sure to have. But since I have had my 5 speed installed I don't think I have ever experienced the 5 speed stall (or if I ever did I have blocked it from memory). This makes me wonder if either:
A) The people experiencing the 5 speed stall have some part (electrical or electrically controlled probably) not functioning correctly but not throwing a code.
B) The people not experiencing the 5 speed stall (myself included) have some part (could even be an air leak) that is causing them to not experience the problem.

On a different note, I feel fairly confident saying that the function E2F0 is learning the base TPS value (The TPS value at idle/throttle closed). This value is stored at 12C8.

[Mrdjc]

What's this five speed stall your talking about, I've never experienced it on my Legacy and Neither have I heard of the problem being specific to 5th gear on the UKlegacy forum. Usually stalls are throughout the whole range of gears and speed, down to a messed up IACV, TPS or leak.

Must be an SVX thing then? Does it apply to EJ20's as well as the EZ/EG series?

Roughsilver,
good job blowing some life into this project once again!

I've been meaning to do exactly what you are doing now, but lost interest and now I'm studying abroad in Slovakia so my Vehicle is at my parents in storage in Scotland.
Once I get the basics worked out for my N/A I'm hoping to move on into the EJ20 TT setups, as there is a heap of demand out there for it, and the only real option currently is a complete aftermarket ECU but it doesn't really include any of the code that is written into the stock ECU with regards to boost and turbo malarky.

Phil,
Congrats with 2nd child! You must be a really really busy man now!
I think your presence on this thread is probably what is keeping it alive and ticking over, its clear to see it suffers without you.

Wishing everyone a happy new year, and hopefully fruitfull in terms of ECU exploration.

Cheers,
Daniel.

[RoughSilver92]

[QUOTE=Mrdjc]
What's this five speed stall your talking about, I've never experienced it on my Legacy and Neither have I heard of the problem being specific to 5th gear on the UKlegacy forum. Usually stalls are throughout the whole range of gears and speed, down to a messed up IACV, TPS or leak.
/[QUOTE]

The 5 speed stall is pretty well documented here, but basically it sounds like the people that have it experience stalling when disengaging the clutch after using the engine to slow the vehicle. It's a weird one, though because not everybody has this problem. SVXRide said that the Hydra solved the problem for him. That has me leaning towards the idea that those of us not having the problem have an air leak or something which is why we are not experiencing the problem, but this is purely speculation.

Good luck on you project, Mrdjc.

And Phil is definitely what is keeping this going. Thank you Phil for all your help to me and others.

P.S. I'll be sure to need more help soon:D

[RoughSilver92]

What the heck is this?

00B090 3C8F84FF0B bbc #0xff, 0x848f, 0xb0a0

ff is 255, so is it looking 255 bits down, or is it some other crazy business?

[SVXdc]

BBC and BBS opcodes can use "Absolute bit relative" addressing mode (you'll need to look that up in the CPU software manual).

BBC is Branch on (all specified) Bits Clear

The 5th byte of the instruction specifies the relative branch (#0x0B in your example, so [PC] B095 + [offset] 0B = [branch target] B0A0).

Bytes 2 and 3 specify the memory location to read (848F).

Byte 4 specifies which bits to examine to make the decision whether to branch. FF here says to look at all 8 bits in the specified memory location. In other words, branch when all bits in 848F contain 0.

When the m flag is 0 ("16-bit data mode"), then the bit field becomes 16-bits (in bytes 4 and 5), and the 6th byte contains the branch offset.

[RoughSilver92]

Thanks, that is a big help. That ff was throwing me, up until now I have only ran into the 01,02,04,08,10,20,40,80. ff representing all the bits is perfectly logical, really should have been able to reason that out myself. With time, I guess.

[b3lha]

Hey Phil,

Someone asked me an intersting question today for which I don't have the answer and thought I would pass on to you in case you are interested in/willing to look into it.

He asked me how the ecu handles when to start fuel injection. Not the pulsewidth but the timing of fuel injection in relation to crank position/valve opening. I remember the factory service manual mentioning timing fuel injection to end as the valve is opening. It might be fruitful to be able to adjust this.

I don't know either.

At the lowest level it's going to be some kind of syncronisation between the crank sensor pulses and the six injector timers. That's going to be tough to figure out unless there is some obvious map that controls it.

I'll make a note of it but I can't promise to come up with any hard and fast answers.

[TomsSVX]

Hey Phil,

Someone asked me an intersting question today for which I don't have the answer and thought I would pass on to you in case you are interested in/willing to look into it.

He asked me how the ecu handles when to start fuel injection. Not the pulsewidth but the timing of fuel injection in relation to crank position/valve opening. I remember the factory service manual mentioning timing fuel injection to end as the valve is opening. It might be fruitful to be able to adjust this.

Fruitful for what?? Basic fuel efficiency?

I mean hell after about 2krpms it doesn't really matter if you even have sequential injection, esp with the stock injectors... To adjust the start angle would be trying to slit hairs with a hatchet

Tom

[b3lha]

What's this five speed stall your talking about, I've never experienced it on my Legacy and Neither have I heard of the problem being specific to 5th gear on the UKlegacy forum. Usually stalls are throughout the whole range of gears and speed, down to a messed up IACV, TPS or leak.

Must be an SVX thing then? Does it apply to EJ20's as well as the EZ/EG series?

Roughsilver,
good job blowing some life into this project once again!

I've been meaning to do exactly what you are doing now, but lost interest and now I'm studying abroad in Slovakia so my Vehicle is at my parents in storage in Scotland.
Once I get the basics worked out for my N/A I'm hoping to move on into the EJ20 TT setups, as there is a heap of demand out there for it, and the only real option currently is a complete aftermarket ECU but it doesn't really include any of the code that is written into the stock ECU with regards to boost and turbo malarky.

Phil,
Congrats with 2nd child! You must be a really really busy man now!
I think your presence on this thread is probably what is keeping it alive and ticking over, its clear to see it suffers without you.

Wishing everyone a happy new year, and hopefully fruitfull in terms of ECU exploration.

Cheers,
Daniel.

Hi Daniel, nice to hear from you. Hope your studies are going well.

The SVX only came with an Auto trans and the ECU makes certain assumptions based on that fact. When people swap in an impreza 5 speed manual trans, the ECU assumptions are sometimes wrong and this can cause a stall. The fact that not everybody gets the problem confounds the issue a little, but offers hope that the problem cars can be fixed.

I think you are right about the demand for tuning the TT setups. From what I hear, Subaru made a really bad job of it, and ended up with a huge dip in the middle of the power curve when one turbo had reached its limit and the other hadn't started blowing. This could be fixed by fitting some different turbos and then recalibrating the ECU. But as yet, very few people know how to recalibrate the ECU - and those that know aren't sharing.

[b3lha]

BBC and BBS opcodes can use "Absolute bit relative" addressing mode (you'll need to look that up in the CPU software manual).

BBC is Branch on (all specified) Bits Clear

The 5th byte of the instruction specifies the relative branch (#0x0B in your example, so [PC] B095 + [offset] 0B = [branch target] B0A0).

Bytes 2 and 3 specify the memory location to read (848F).

Byte 4 specifies which bits to examine to make the decision whether to branch. FF here says to look at all 8 bits in the specified memory location. In other words, branch when all bits in 848F contain 0.

When the m flag is 0 ("16-bit data mode"), then the bit field becomes 16-bits (in bytes 4 and 5), and the 6th byte contains the branch offset.

Very nice explanation David. :)

I always find it confusing when more than one bit is specified in a BBC or BBS statement. I can never remember whether it means ALL or ANY of these bits.

[RoughSilver92]

I am still trudging through this code and I want to make sure i am interpreting this correctly:

00ADC6 AD2E10 lda ax, 0x102e
00ADC9 2900FF and ax, #0xff00
00ADCC 890D1A80 mpy 0x801a


Since it is little endian, 102f contains the most significant digits and 102e contains the less significant digits. So the value at 102e is inconsequential because the and will clear those bits anyways. In reality it is multiplying the value at 102f followed by 8 bits of zeros with the value at 801b followed by the value at 801a, or:
[102f][#00]
x[801b][801a]
---------------

Is this about right or do I have it backwards?

[b3lha]

I am still trudging through this code and I want to make sure i am interpreting this correctly:


Since it is little endian, 102f contains the most significant digits and 102e contains the less significant digits. So the value at 102e is inconsequential because the and will clear those bits anyways. In reality it is multiplying the value at 102f followed by 8 bits of zeros with the value at 801b followed by the value at 801a, or:
[102f][#00]
x[801b][801a]
---------------

Is this about right or do I have it backwards?
Yes. That is correct.

The two 16-bit values are multiplied together and the 32-bit result is put into b,a
eg. [102f][#00] x [801b][801a] = [bh][bl][ah][al]
Then the next line of code takes the most significant 16 bits of the result and stores them at [1009][1008]
00ADD0 428D0810 sta bx, 0x1008

That's basically the same as dividing the result of the multiplication by 0x10000

[b3lha]

I am still trudging through this code

Hey Andy,

If you are still playing with this then I have something to help you:

The first file is an M7700 debugger program (for windows). The second is your 722525 ROM converted into Intel Hex format.

pd77simv310r1a_e.exe (http://www.alcyone.org.uk/ssm/pd77simv310r1a_e.exe)

722525.hex (http://www.alcyone.org.uk/ssm/722525.hex)

You can load the ROM into the debugger and run parts of the program one instruction at a time and watch what happens to the registers and the memory. You can also change variables in memory, then run through a calculation to see what effect it was on the result.

http://www.alcyone.org.uk/ssm/debugger.jpg

After loading the ROM, setup the M flag appropriately. Set the PC register to the address that you want to start executing from. Then set up any values in RAM or registers as you want them, and start stepping through the code.

Also, I think that you can dump the RAM from your car and load that into the simulator too, so the program has some good data to process.:) Obviously you'll have to fake ADC readings and other Input values because the simulator doesn't have an engine attached.

Phil.

PS. Daniel, if you're still here then you might like this too. It should work with your Legacy ROM. Just use bin2hex (http://www.ht-lab.com/freeutils/bin2hex/bin2hex.html) to convert the ROM binary into Intel Hex format.

[Mrdjc]

Thanks Phil,

That program looks mighty interesting.. I was going to try and make a flow chart type drawing to make note of what's happening with the registers but this will really help!

Might just be the best thing since sliced bread.. I'll give it a go some time in the near future.

I wonder if Roughsilver is going to get there before me, he most likely will.. :D

Cheers,
Daniel.

[RoughSilver92]

The start of the semester has slowed me down a bit on the code, but I will find some time to play with this. Now I should be able to test weather a couple of the values I have been guessing at actually do what I think.