5EAT TCU Reverse Engineering

[RIPjeep2002]

So how does this affect us guys with the IPT valve body?

[underground000]

Nice start!!! I adjusted the top row of the throttle table, the one that is the table header. It is scaled up by the same % the RTq map is scaled up. You may have found something else since you did not adjust the accelerator map, which is that the manual states that throttle plate position and accelerator position are also pulled from the ecu to determine trans behavior. I wish I could work on this side by side with you, but I am still getting tuned, and am chasing a pesky air leak. Hopefully we can figure out exactly where to add pressure to benefit us with a greater clamping safety margin, without sacrificing comfort when it is not needed. I'm sure there is sn optimal way to tune these accelerator tables for trans behavior.

 

Can u post The accel table u also adjusted. I'm scared to adjust it too much. Like having too much of a range:lol newb at tuning

 

EDIT: Just looked, Requested Torque: the top row is Accel Position. Theres another chart for Throttle Angles and I was going to adjust that. I guess I wasnt paying much attention. And was thinking Throttle Angle is the same as Accel Position. I dont think Ill need to adjust Accel Position Do I?

Edited October 17, 2010 by underground000

[underground000]

So how does this affect us guys with the IPT valve body?

 

 

There's not much to say yet from tuning the tcu or the Accessport Req Torque changing. I do not have a VB mod. The hypothesis is increase even more line pressure then the VB mod (for those who have it) for more clamping power without spening $5k for full trans build. But don't expect this to hold 500hp with just tcu mod and VB Mod

[ClimberDHexMods]

I think the TCU shoots for full line pressure past a certain torque point, however determined based on TCU maps of 4 variables: rpm, mph, requested torque, and trans temp.

 

I think the top amount of line pressure is increased with doing the "VB mod," independent of ECU/TCU settings.

 

For either group, my personal hypothesis is that at part throttle, the engine can make double or more torque vs stock, but that increase in power is not matched optimally with more line pressure in those areas of the map. So the test is to see how best to map out the throttle and torque tables to get an ideal amount of line pressure at every operating condition of the engine.

 

This would be easier if we knew which trans bolt to remove and tap with a pressure sensor. I think I know which one, and the manual will confirm

[utc_pyro]

Just tap into it were the Subaru kit does. There is a port on the bottom of it. Check the service manual for were they talk about checking the pressure.

 

The only bad thing about the location is it's right on the bottom, so any road hits would rip it out, along with your fluid and possibly a chunk of the casing. Might be OK for short term testing, but I would not want to drive around like that in the long run.

[ClimberDHexMods]

Just tap into it were the Subaru kit does. There is a port on the bottom of it. Check the service manual for were they talk about checking the pressure.

 

The only bad thing about the location is it's right on the bottom, so any road hits would rip it out, along with your fluid and possibly a chunk of the casing. Might be OK for short term testing, but I would not want to drive around like that in the long run.

 

It's either the one on the bottom front, or side front, along the edge of the front diff/ torque converter case.

 

With 5.5 inches of ground clearance and lots of speed bumps here, I hope it's the bottom one

[NesCar]

@utc_pyro: Nice try but ...

 

First you need to understand (standard) SSM/SSM2 addresses are sort of fake or virtual as they don't represent real hardware addresses the processor uses. Think of them like defined IDs. The ROM includes SSM subroutines that handle incoming SSM requests and generate a response packet.

 

Example: on most ECUs requesting byte at 0x00001C yields battery voltage (value/12.5 = volts).

Address/ID 0x00001C tells it what you want. So far I've seen the ROM code uses either redirection table or function table lookup to generate the corresponding answer byte.

 

The virtual SSM address space is limited as this thing needs extra space and there's a limited number of measuring blocks than it supports anyway. Rather new ECUs limit addresses to being smaller than 0x350. Older ECUs have smaller address spaces like 0x200 or 0x150 bytes etc. If you request addresses above the limit, you just get constant fake byte 'FF' for these. SSM2 over CAN would tell you an error, SSM over serial line doesn't tell errors, reporting fake content instead or ignoring the entire request.

 

Another thing: Block read command A0 may not work for standard range e.g. 0x000000..0x00034F like on my ECU. I only get FFs by doing this. I've also heard some people get inconsistent data. In that case you'll have to use (slow) A8 messages. Again, that's a deliberate limitation compiled into the ROM software.

 

 

RAM case exception: Specific to firmware/model some RAM ranges are allowed which map almost directly to hardware addresses.

Example for 32bit control units: an SSM2 address like 0xFF1234 is a RAM address, highest address byte is FF, far beyond normal address range. It will be translated internally to 0xFFFF1234 which now is a real 32bit hardware address the CPU works with. One can dump real RAM by A8 or better A0 commands with this but only from the ranges that the firmware code allows. Outside valid range(es) you probably get fake FFs again.

 

SSM message length in general is limited, too. Modern ECUs take up to 255 bytes limiting the number of data bytes one can request/get per single message. Older units may use smaller buffers.

 

I think with your fubar TCU responses there must be something wrong with your tool. If there's not even a valid response header you should not even touch the msg with a stick.

 

IMHO there is NO way you can dump ROM using standard SSM2 commands like 'A8' or 'A0'.

 

If you want to know inner workings of SSM2 protocol you can disassemble available ROMs and see for yourself.

 

Flashing/dumping ROM is a different story. Sniffing a flash is a good idea but Subaru dealer tools transfer all data in encrypted form.

 

Makes sense? Haven't played with a TCU yet but it seems same SSM principles apply.

[hadvw]

So adjusting the Req Torque did make a difference. When I tested earlier I was doing WOT runs, today I was just doing city driving. There was not a difference in shifting, but there was more 'resistance' while driving. From what I understand for more 'resistance' is the lockup is gradual, not on/off. So adding more line pressure added more lock up at a lower rpm. I only changed S#, so when I changed to S the resistance was gone/decreased, and shifted back to S# resistance I can feel some resistance.

 

I did have a 2-3 upshift bang and that might have gotten a bit worse at higher rpms but I dont really know. What I do know if downshifting from 2-1 at high rpm it hit 1st pretty hard after rev matching, this is around 32mph

 

My concern now is if we have a pressure plate for lockup, will the increase line pressure at lower rpm and higher lockup wear the pressure plate more? Or whatever part is for lockup?

 

I did not adjust the Throttle Angles

 

 

Did you try manually shifting the gears? I don't even mind the stock shifting for regular driving, as long as it would "SHIFT_RIGHT_(*&@#$_NOW" when I hit up/down, instead of waiting for a consensus from the characters in Herman's Head..

[ClimberDHexMods]

Did you try manually shifting the gears? I don't even mind the stock shifting for regular driving, as long as it would "SHIFT_RIGHT_(*&@#$_NOW" when I hit up/down, instead of waiting for a consensus from the characters in Herman's Head..

 

The point is to not have to go around it. It is nice when an auto just shifts for you without you worrying that a clutch is slipping. It is realistically hard to make a 5eat clutch slip under most situations, but when you get early torque or big power, there is a very real need to make sure you're all good.

[utc_pyro]

@utc_pyro: Nice try but ...

 

First you need to understand (standard) SSM/SSM2 addresses are sort of fake or virtual as they don't represent real hardware addresses the processor uses. Think of them like defined IDs. The ROM includes SSM subroutines that handle incoming SSM requests and generate a response packet.

 

Example: on most ECUs requesting byte at 0x00001C yields battery voltage (value/12.5 = volts).

Address/ID 0x00001C tells it what you want. So far I've seen the ROM code uses either redirection table or function table lookup to generate the corresponding answer byte.

 

The virtual SSM address space is limited as this thing needs extra space and there's a limited number of measuring blocks than it supports anyway. Rather new ECUs limit addresses to being smaller than 0x350. Older ECUs have smaller address spaces like 0x200 or 0x150 bytes etc. If you request addresses above the limit, you just get constant fake byte 'FF' for these. SSM2 over CAN would tell you an error, SSM over serial line doesn't tell errors, reporting fake content instead or ignoring the entire request.

 

Another thing: Block read command A0 may not work for standard range e.g. 0x000000..0x00034F like on my ECU. I only get FFs by doing this. I've also heard some people get inconsistent data. In that case you'll have to use (slow) A8 messages. Again, that's a deliberate limitation compiled into the ROM software.

 

 

RAM case exception: Specific to firmware/model some RAM ranges are allowed which map almost directly to hardware addresses.

Example for 32bit control units: an SSM2 address like 0xFF1234 is a RAM address, highest address byte is FF, far beyond normal address range. It will be translated internally to 0xFFFF1234 which now is a real 32bit hardware address the CPU works with. One can dump real RAM by A8 or better A0 commands with this but only from the ranges that the firmware code allows. Outside valid range(es) you probably get fake FFs again.

 

SSM message length in general is limited, too. Modern ECUs take up to 255 bytes limiting the number of data bytes one can request/get per single message. Older units may use smaller buffers.

 

I think with your fubar TCU responses there must be something wrong with your tool. If there's not even a valid response header you should not even touch the msg with a stick.

 

IMHO there is NO way you can dump ROM using standard SSM2 commands like 'A8' or 'A0'.

 

If you want to know inner workings of SSM2 protocol you can disassemble available ROMs and see for yourself.

 

Flashing/dumping ROM is a different story. Sniffing a flash is a good idea but Subaru dealer tools transfer all data in encrypted form.

 

Makes sense? Haven't played with a TCU yet but it seems same SSM principles apply.

 

NesCar, that makes sence. That's the cearist explination of how SSM handels the request that I've ever seen. Thanks for the detailed information. I guess I didn't read enough into SSM past that PDF that list the basic commands. I got the idea to use SSM to read the address from work on the late '90s roms that use the same M32R core. Apparently the flash memory was accessible over SSM starting at 0x700000 in those ECU's (it was remapped), and they were able to SLOWY dump the rom.

 

Any suggesting on how to get started on these serial cars with the M32R core? Am I just going to have to figure out the JTAG interface, or is there a know way to take the dealer .pak files and extract the ROM?

 

I guess CAN may be a little easier, but I dont have access to anything there to start with .

Edited October 19, 2010 by utc_pyro

[underground000]

Did you try manually shifting the gears? I don't even mind the stock shifting for regular driving, as long as it would "SHIFT_RIGHT_(*&@#$_NOW" when I hit up/down, instead of waiting for a consensus from the characters in Herman's Head..

 

I always drive in manual mode. There is still the delay when you tell it to shift to when it shifts. But what I noticed from factory it downshifts nearly instantly when I tell it to

[NSFW]

Ok, the responses I'm getting from the TCU are STRANGE....

 

It would be interesting to try sending the raw SSM commands directly, and studying the output directly. That would shed some light on whether it's the TCU or the test utility that's causing the weird responses.

[utc_pyro]

It would be interesting to try sending the raw SSM commands directly, and studying the output directly. That would shed some light on whether it's the TCU or the test utility that's causing the weird responses.

 

I'm thinking it's the cable unless the program filters out responses until it sees "80 f0". I'll see if I can find something to send them with.

 

 

 

Any 2007 5EAT owners reading this? If so, does your car up-shift rev-match?

 

Looking at the list of TCU update files for the various 5EAT's, I noticed the Tribeca 3.0 '06 and '07 files were the same, but with an "A" and "B" suffix respectively. All of the '08-'09 files are the same file inside each model, so they appear to share the same ROM. Thus I wonder if the '07's have the older TCU, but updated to flash/respond via CAN. If so, pulling a '07 rom via CAN would help figure out the structure of the '05-'06 serial ROM's.

[underground000]

Any 2007 5EAT owners reading this? If so, does your car up-shift rev-match?

 

It shouldnt upshift rev match, just downshift rev match if it has downshift rev match

[utc_pyro]

Opps, that's what I ment . I had been up almost 22 hours and was a bit out of it at time of posting.

 

Edit: If this is going to be done JTAG, it looks like there are OEM tools, but pricy.

 

M32100T-EZ-E

 

It's a bit over a grand. Maybe there is 3rd party support?

 

Also there is a chance the rom is "password protected" as seen here:

 

http://www.renesas.eu/support/faqs/faq_results/Q101901-Q102000/m32r_101982_en_GL.jsp

 

It might be possible to bypass that if we can inject code to read that address block via JTAG. Or if Subaru is lazy and uses the same "password" for all the roms, we can pull it from a '99 RS ECU rom. This one is also not an issue if there is a way to inject enough of our own code into the RAM to serve as the entire itnerface (how ECUFlash does it). I think it's just the factory (hatachi) boot-loader ROM serving as a flashing interface that actually cares.

 

I need to go read into the flashing via K-line done on the older drive by cable roms. Maybe it's simular.

 

Edit 2: Figured out what at least ONE of the other chips are. The small one right above the M32R microcontroller is a watchdog timer. The other one (that has it's own clock) is itentical to some on other ECU's. I have no clue what it does, they didn't mention what it does, so I'm going to stop looking at it. Not much of it's I/O goes to the main core any way.

 

Also this: http://www.activeboard.com/forum.spark?aBID=99460&p=3&topicID=25151801

Other have stated that the CAN ECU/TCU's initilize in a simular way to each other.

And this shows the init stuff is about the same between the Subaru computers: http://forums.nasioc.com/forums/showpost.php?p=14204135&postcount=73

And the init code for the old 68HCXXX ECU's is in here some where: http://ecuexplorer.googlecode.com/svn/trunk/

Edited October 19, 2010 by utc_pyro

[LGTONCOKE]

I always drive in manual mode. There is still the delay when you tell it to shift to when it shifts. But what I noticed from factory it downshifts nearly instantly when I tell it to

 

 

This is my issue

[dschultz]

Edit: If this is going to be done JTAG, it looks like there are OEM tools, but pricy.

Why not use opensource JTAG hardware and software?

[utc_pyro]

Why not use opensource JTAG hardware and software?

 

Know of any that work with the M32R or simular?

 

Also this seems like the M32R is a small subset of the overall number of TCU's. We might need to work on the '08 first so we can support more cars overall platforms.

[dschultz]

Maybe http://www.kpitgnutools.com or http://urjtag.sourceforge.net/

[dwolson2]

finally caught up with the posts, Looking forward to the outcome, am looking at changing my requested torque tables. I think it may be easier on my transmission for towing...what do you guys think?

[underground000]

I upped my requested torque from 350 to 498 (max is 500), only upped the requested torque for S#

 

running OTS Cobb ACN Stage 1, w/ lightweight crank pulley

 

The other day I was on freeway to freeway on ramp, shifted to S#, manual shifted to 2nd gear, right after it rev matched I floored it and it seemed liked it free reved - was not pulling in 2nd. I quickly shifted to 3rd and was fine. I dont know what happened and didnt look at rpms/boost but knew I was going about 43mph. I know what 40mph in 2nd gear feels like

 

Maybe it didnt catch 2nd gear or hopefully was not slipping in 2nd

 

Im not concerned yet, just letting you guys know what happened

[dwolson2]

I have had that happen a few times(3/4), in 40K miles...

[OGHK87Jay]

I have the Subaru Legacy US MY2005 Complete Service Manual in pdf format if you need them it includes the 4eat and 5eat I don't know if this will help you

[hadvw]

I called TransGo about a shift kit for the 5EAT. They said they would do it for $350 and would like the valve body for a week or two. Sounds like they want to make a custom kit, but need a valve body to create it. They said that the Suby 5EAT valvebody should be close to the kit needed for the 350Z - part #RE5RO5A-HD2.

 

http://www.transgo.com/rpg_nissan.php

 

I could hear the TransGo folks talking it over in the background. They came back and said that the 350Z kit was complicated and they had several people have trouble installing the kit. They did not recommend anyone but an experience professional installing that particular shift kit.

 

Looking at diagrams of the kit on the web, it did not look overly complicated however.

 

Wait, so if we picked up one of the "floating" valve bodies and shipped it to TransGo, they'd be willing to work their magic on it?

 

Wish I knew more about who can do this kind of work around here.. I'd be all over that..

[seabass07]

Shit...for $350? Maybe that cheap because you'd be a guinea pig.