NA Engine Control Unit tuning and Diagnostics

[SILINC3R]

im very interested in this. this could be what takes the N/A to the top... or well close

[epicfail]

I would be very interested in this. I understand that you don't want to step on anyone's toes about ECU tuning software, but one unit that could do both n/a and turbo ecus would be phenomenal.

[longassname]

I have all the na legacy ECUs but don't have an na legacy. If there is a na legacy owner in Miami interested in a performance chip willing to let me use his car to download the firmware from I can plug each ECU into his car and use my software to download the firmware off them so we have a complete library of na legacy firmware. It will take about 2 hours for each one. For his troubles I can give him the very first na legacy performance chip free of charge.

[Suigintou]

EDIT: deleted what I said because I can't read.

You need an entire, running NA Legacy? I live in the Tampa area but my front diff bearings are shot. My car is half way taken apart but I'm flat broke. If you just need a piece of the car I could mail that but thats it. Sorry.

[legacy4ever]

That is going to be a tremendous software with amazing capabilities! Look I'm in Europe, would that be possible to join it with my euro Legacy?

I used to play with a VWRX monitor with the FTDI converter. But it is limited and sucks with the communication (92 problem perhaps). Will that FTDI TTL to USB adapter also work with your software? I have all the sensor addresses for the EDM ROM and can try to download the ECU ROM as well.

Thanks for your great work! I'm watching your TCU tuning thread, too!

[longassname]

It doesn't actually have to run but it does need to have the harnesses and sensors in it so that when an ecu is plugged in it behaves normally. It also needs to be parked close enough to power to hook the car up to a battery charger and to plug my laptop into ac power.

EDIT: deleted what I said because I can't read.

You need an entire, running NA Legacy? I live in the Tampa area but my front diff bearings are shot. My car is half way taken apart but I'm flat broke. If you just need a piece of the car I could mail that but thats it. Sorry.

[longassname]

The software will work fine with the Euro model legacy but it will not work with the ftdi cable you already have because it uses the cable purchased from me as a license dongle.

That is going to be a tremendous software with amazing capabilities! Look I'm in Europe, would that be possible to join it with my euro Legacy?

I used to play with a VWRX monitor with the FTDI converter. But it is limited and sucks with the communication (92 problem perhaps). Will that FTDI TTL to USB adapter also work with your software? I have all the sensor addresses for the EDM ROM and can try to download the ECU ROM as well.

Thanks for your great work! I'm watching your TCU tuning thread, too!

[log1call]

If you just need the rom downloaded you should be able to connect the ecu up on a bench surely?

If you try to plug all different ecus into a car that they are not made to go in, the sensors are not going to give the correct readings anyway so there is really no point trying it, you won't get anything out that you can't get by connecting up on the bench.

[Lunatech]

Except actual readings from actual sensors on an engine that is actually running.

[longassname]

I don't believe the pin outs change over model years. I haven't tried it myself or made mental notes of the priorities involved but my understanding is that the speed of ssm communications are significantly decreased when the control unit doesn't have any of the things it expects connected to it. If the simple solution of plugging them into the car they are designed for proves terrribly inconvenient I'll look into alternatives.

If you just need the rom downloaded you should be able to connect the ecu up on a bench surely?

If you try to plug all different ecus into a car that they are not made to go in, the sensors are not going to give the correct readings anyway so there is really no point trying it, you won't get anything out that you can't get by connecting up on the bench.

[log1call]

The pin-outs are different from year to year and from market to market.

The sensors and actuators are different with year and market changes.

The output speed from the ecu is the same whether it's connected to the car or not. The more sensors or actuators you are logging will slow down the data-logging software though. The data-logging software will be slow if you are logging a lot of parameters whether you are getting live data or the default figure/zero figure you get when the sensors are not working/connected.

To take a rom dump takes about twenty to forty minutes unless you have a really slow laptop or software.

It's amazing that you are going to be able to reprogram the tcus. As far as I am aware they could not be written to in their rom addresses. The same goes for the ecus. As far as I know the only way to reprogram the older chips is to unsolder them, plug them into a programming burner and then refit them to the circuit board.

If you really can reprogram the ecus I would like to buy one of your cables and the software to do it please.

[longassname]

Both the TCU and the ECU require external memory be fitted to replace the firmware/change the data in order to change things. An explanation of the process and examples of things that are commonly done were given not many posts ago. The na legacy ECU uses the same memory module as the SVX ECU. I have long been making/selling performance "chips" for the SVX and some time ago redesigned the memory adaptor to a form factor which physical fits all NA legacy ECUs. The TCU requires socketing and the repositioning of a resistor to switch it to external memory. A standard jdec 8 bit memory module can then be fitted. Aren't you one of the guys Phil was instructing on how to do this stuff? I thought you new all this (I think maybe you haven't actually read the thread and have started off with the assumption that I'm out of my depth here).

I haven't looked at them in a long time but at one point Josh had given me pin outs of the legacy control units and I'm pretty sure I remember there being very few differences between models and years of legacys. I could be wrong; like I said it's been a long time since I looked at them.

Have you actually downloaded the firmware off of a Subaru ECU on the bench or are you just conjecturing about how it will work? It's very possible I was missinformed and it will download fine without anything connected. It's also very possible I was informed correctly that it will result in an interupt with a higher priority hogging the processors attention so that the serial port gets neglected. I think you would actually have to have done it to know for sure...though if you followed the program flow starting from the reset interupt you could probably make a pretty good guess(ok you would actually know if you didn't make any mistakes but I like to assume mistakes will be made..they usually are).

[log1call]

Oh Ok. A bit of confusion there. I thought you said you could reprogram any tcu/ecu. Fitting eeprom chips or piggy-back boards with eeprom on is fairly well documented though.

I didn't think you could get the original eprom any more so had to use a board to addapt newer chips. I also understood that the new chips could not be reprogrammed in place in the car but had to be taken out and put into a burner. But you have developed a way to reprogram them in place? And the original chips are still availiable? Is that correct?

Yes, I was getting Phil to work me through how he disassembles rom. You might have noticed I mentioned I reckon there is a simpler(and quicker)way of finding the addresses.

I have downloaded rom dumps both on the bench and from cars... no difference. The pre-programmed rom which is the bit we need to change to alter the tune is always the same. If you are dissasembling the code then the ram addresses aren't really important to you/us. Not till you want to check the results anyway, in which case they will be in cars. When you dump rom/ram on the bench you will just get default figures for some ram addresses, meaningless numbers in others, the rom will always be correct though and the data keeps coming out at the standard baud rate. The only real need for the ecu to be in the car I would have thought would be to test the addresses, which is the way I favour even though it's not as scientific as Phil's method.

With regards the ecu pin-outs all being the same... I suspect there are quite a few variations just because there are different types of sensor on different models, different pin-outs on the engine harness, different engines. I have seen quite a few instances on here of people discussing pin-outs and they do not seem the same as the ones we have here in New Zealand.

Anyway, if you have figured out a way to reprogram in car, with a eeprom chip fitted, that is still fantastic. The people on the ground will I'm sure soon figure out which definition will do which model.

Hey, and as an aside... I have modified my copy of evoscan to log most of those things you list, including the trouble codes. I haven't figured how to clear them yet but that should be fairly simple I'd think using the manual command sending panel down the bottom of the evoscan page. One day!

[longassname]

My memory adaptors use modern, readily available memory. You can not program them in the car. My memory adaptors also have the ability to switch between 2 versions of firmware on the fly according to an electronic input. There are all kinds of uses for that. Here's what one of my memory adaptors looks like:


Emulators are used to "emulate" a ROM piece so that the firmware can be modified while the vehicle is running in order to immediately see the results. Otherwise a new ROM must be written in order to be tested.


It's good news that the ECU serial port isn't neglected/effected if the ECU isn't connected to the car. That will make expanding the firmware library easier.

Have you documented the switch bitmaps for your car? Do you have anything useful defined that I don't have in my definitions file. I'm sure people would appreciate it if you shared them with them if you do.

Oh Ok. A bit of confusion there. I thought you said you could reprogram any tcu/ecu. Fitting eeprom chips or piggy-back boards with eeprom on is fairly well documented though.

I didn't think you could get the original eprom any more so had to use a board to addapt newer chips. I also understood that the new chips could not be reprogrammed in place in the car but had to be taken out and put into a burner. But you have developed a way to reprogram them in place? And the original chips are still availiable? Is that correct?

Yes, I was getting Phil to work me through how he disassembles rom. You might have noticed I mentioned I reckon there is a simpler(and quicker)way of finding the addresses.

I have downloaded rom dumps both on the bench and from cars... no difference. The pre-programmed rom which is the bit we need to change to alter the tune is always the same. If you are dissasembling the code then the ram addresses aren't really important to you/us. Not till you want to check the results anyway, in which case they will be in cars. When you dump rom/ram on the bench you will just get default figures for some ram addresses, meaningless numbers in others, the rom will always be correct though and the data keeps coming out at the standard baud rate. The only real need for the ecu to be in the car I would have thought would be to test the addresses, which is the way I favour even though it's not as scientific as Phil's method.

With regards the ecu pin-outs all being the same... I suspect there are quite a few variations just because there are different types of sensor on different models, different pin-outs on the engine harness, different engines. I have seen quite a few instances on here of people discussing pin-outs and they do not seem the same as the ones we have here in New Zealand.

Anyway, if you have figured out a way to reprogram in car, with a eeprom chip fitted, that is still fantastic. The people on the ground will I'm sure soon figure out which definition will do which model.

Hey, and as an aside... I have modified my copy of evoscan to log most of those things you list, including the trouble codes. I haven't figured how to clear them yet but that should be fairly simple I'd think using the manual command sending panel down the bottom of the evoscan page. One day!

[Legacy777]

Regarding the ECU pinouts. For the most part, the targeted cars, 90-94 non-turbo US legacies are going to be the same. I do know that the MT/AT identifier pin is reversed on the 92 and newer ECU's, however I'm not sure if your chip is really going to affect that or not.

Michael, I'd be happy to go through and try to put together a list of any differences I'm aware of on the ECU I-O between the years. I would just need to know what model years you are trying to target, and how your chip will modify things.

There are differences between AT & MT cars, but the ECU's have that differentiation built into them. I'd just need to know how things are going to be setup....

I'll shoot you an email.

[log1call]

Ok, it's all clear now, almost.

The trouble code bits for my ecu were identified by Phil. It took me a while to figure how to describe them to the software though!

I also have the ssm specs which show bit maps for some later model cars, the ones that around here at least hadn't quite got to be obd2 but had the obd2 diagnostic plug under the dash.

I have a few rom dumps if they are any use to you, 703315, A30117, A1100D and another one that's on another laptop which I can't remember the id number of.

[longassname]

I already have the trouble code bitmaps in my definitions file. Do you have any of the switch bitmaps? fa0? fa1? fa2? fa3?

Rom id numbers don't mean anything to me. A couple of those numbers look like label numbers (which don't mean anything to me either). What model and year cars do you have firmware for?

[log1call]

Hi,
those were all rom id numbers. I realised that the A1100D and A30117 were both ecus out of wrx and that the A1100D had been fitted to a legacy. The A30117 is fitted here in New Zealand to a wrx as standard but I have seen it listed as being a forester ecu for Europe. The 703315 is for a 90 N/A 2.0L JDM. The other ecu I still haven't found but it will be for a 93 N/A 2.2L and probably Australian or pacific market.

You are planning to use a year and model as the definition of ecu I presume? If you don't use the rom id numbers or the numbers off the outsides of the cases your software is going to be very model and market specific. We have different engines and specs to you fellahs in America for any particular year. Eurpoe has different specs again. The models you define will likely work, well with some addresses anyway, but it's likely they will work in different years or models. Some spec cars the addresses may not be right for at all. And... Those addresses you have in that photo on here... I have never seen those addresses before, what year and spec car are they for if you don't mind me asking?

I don't have any of those switches you asked about because I'm just a mechanic and I only gather what I can as the opportunity arises. I do have the trouble code addresses and bits for the 703315 if that interests you? I also have a ssm definition(you may already have seen it on the web somewhere) for ecus with their addresses in the 0*** range. It comes with switch address and bits.

(Edit).. Those switches I mentioned above, the 0*** range of addresses, they should work with rom id A30117 and A30113(both of which are documented on the web), although I haven't tested them yet.

[longassname]

I think you will find neither the ram nor rom locations are specific to the rom id numbers.

It will be up to the people who are modifying and creating definitions files to figure out what cars match what definitions files and label them appropriately but I can tell you now that using the ROM id scheme won't be efficient. There will be many different ROM id's that will work with one definitions file. I went to a lot of trouble to make the definitions files easy for users to modify and create and to make it easy for users to download their firmware for investigation without having a matching definitions file specifically to give you the tools to explore and define new control units.

The definitions file in the screen capture you asked about is an SVX definitions file.

[log1call]

You are right, any particular definition file will work with several vehicles. There are a lot of different definition files needed though.

I agree to a certain degree that it is probably a good idea to keep things as general as possible too, in the interests of adaptability. People that know what they are doing will be able to see which definitions are getting the correct information and which aren't.
In time all the definition files will be worked out and hopefully given rom id numbers so the amatuers can just read their rom number and choose the right definition file knowing the figures they are getting must be faulty if they do not comply with the ssm figures.

The trouble is, some people can't see what is working and what isn't and they will be reading the data, possibly wrong data, and trying to diagnose problems using faulty figures.

I have seen plenty of cases where the majority of the addresses were correct but there were a few that were getting data that did not fit the ssm range of figures and did not follow the expected behaviour... leading me to think they were wrong addresses.

I don't know what addresses subaru was using when they designed the ssm tools but the addresses they decided to choose were the ones they wrote the manuals around and are the ones that reflect the operating principles of the various sensors and actuators. The bottom line for me is that the addresses used must get figures within the ssm recommendations when the sensors or actuators have been tested against some other known sensor's figures. In other words, the behaviour between sensors has to comply with the industry standard operating principle, or the addresses are wrong.

Given that there are so many variations of engine, spec, market and year, I think there is plenty of scope for a lot of confusion and difficulties leaving it to people to try and figure what addresses they should be using for their car. What we need is something like the openecu forum, but for the older cars, somewhere all the various ecu id numbers can be matched up to models and years, where they can be tested and verified before release in their final form.

That I realise, does not fit well with the proposed commercial nature of your venture but it is probably, realisticly, the only way to ensure satisfactory testing that the software will work with the standard subaru ecus. Then again, if people have bought your aftermarket chip and fitted them, all these problems will be non existant I presume.

For myself, I will be doing what I have been doing for several years and gathering addresses for ecus as they become public and transfering them into the software of my choice, which at the moment is evoscan. If you do figure out a way to reprogram rom in place as I thought you were alluding to in your initial posts I would be very interested in buying the software or even hardware, unfortunatly, as things stand at the moment, I think the best option is still to buy another, newer car with reprogramming capabilities built in.

[longassname]

Maybe I like to see the glass half full rather than half empty but I'm quite certain things are much better than you are suspecting. The same definitions file will work with many versions of firmware not just a couple.

The two definitions files for the na legacy cover all US NA legacies and at least most of the other markets of na legacy if not all of them. Bang a huge number of cars for which there was virtually no support for last month now have everything they ever dreamed of and I really haven't even put my attention to creating definitions yet.

I also have a definitions file that covers the sti and ra sti wrx. Bang we're already creating definitions for other cars in other markets before we've even released the software for the US cars. As usual, some of the more obscure cars will be the last to be supported but you'd really have to be pessismistic to focus on some guy in zimbabwe with a 1.5 liter trying to use a us legacy definitions file because his car isn't defined yet instead of focusing on the hundreds and hundreds of thousands of cars that are correctly defined now.

[Lunatech]

Half full is better! Like with any project, taking care of the largest part of it first and then the minutia is the best and easiest way to get to the end, most of the time. In this case I believe it is the best course of action. As for the poor guy in Zimbabwe, sucks to be him, but till now it sucked to be us. Mike is narrowing down the list of people it sucks to be.

[czei]

I recently bought a '93 Legacy that's been made into a rallycross car, and while it looks like a rally car with gutted interior and STi suspension, the engine is bone stock.

I'd love to be able to get a few more horsepower out of this engine since I'm racing against WRXs. What is the expected improvement with a stock engine and/or relatively inexpensive engine mods?

Your project sounds really cool-- I'm definitely interested in buying.

[Jessekrs123]

hey, I was just wondering if you have finished this product yet? I am very interested because I have an idle problem that I cannot figure out, and it would be very easy to pinpoint if I had a datalogger like this. I was looking at the B10 scan tool, but your tool seems a lot better and has a lot more options.

[soobrdad02]

Any news on this???