5EAT TCU Reverse Engineering

[dwolson2]

http://legacygt.com/forums/showthread.php/5eat-owners-converge-168643.html?t=168643

 

for the lazy

[NSFW]

TCUs with Nissan and GM are hacked, so you are correct it's simply a function of talent and time.

 

Where can we learn more about the Nissan TCU tools? The TCUs were probably developed by a third party, kinda like Denso for the ECUs. Maybe they made the Subaru and Nissan TCUs too... or maybe some other third party did. With luck the same hacks might work on Subaru TCUs.

[ClimberDHexMods]

I was generally refering to the R-35 GTR that Cobb hacked, but to what degree I have no idea. Don't own one (yet), haven't looked into it. Entirely possible the LGT TCUs are Denso, as the 08+ valve bodies are. Which is weird... I don't know the relationship between Jatco and Denso, if any... but it begs the question was it Denso or Jatco or ??? who made the 05-07VBs. Back to topic, the 05-06 TCUs are probably as similar to the 08-09 TCUs as the 05-06 ECUs are similar to 08-09 ECUs. Physically I don't know what changed, but similar logic + more CAN and few more auxilary functions. I'm afraid I'm not much help with knowing about the TCUs, though the OP has posted his findings here about what he could see on the TCU he bought and opened up. I don't remember the details, but see early pages... denso doesn't ring a bell... sorry I'm not much use. But if you have a question about how the various TCU tables are structured and interact with eachother, I can be a lot more use in that regard. I know very little about actual computer software/hardware engineering. I just tune what you guys program, and hack around what you don't, with springs and such.

 

Side note, Doesn't denso stamp its name on damn near everything it makes? If so, then that's a very simple way to tell what was and was not made by Denso. That simple

Edited August 25, 2011 by ClimberD@HexMods

[ClimberDHexMods]

Add Kia A5SR1 & AFSR2 to the list. Might also see the similar transmission valve body in a Hyundai Genesis RWD! Some of the Genesis modders are getting pretty into things, perhaps something can be learned about that TCU, or that of the Kia transmissions.

 

Basically, we drive a Kia shift box

[Tomkat1127]

Add Kia A5SR1 & AFSR2 to the list. Might also see the similar transmission valve body in a Hyundai Genesis RWD! Some of the Genesis modders are getting pretty into things, perhaps something can be learned about that TCU, or that of the Kia transmissions.

 

Basically, we drive a Kia shift box

 

I like to think Kia stole it from Subaru....

[fishbone]

And Subaru stole it from Nissan, who stole it from JATCO

[ClimberDHexMods]

So did Kia steel it from Hyundai who borrowed it from Jatco before it was stolen by Nissan and sold on eBay to Subaru?

 

Or is it the other way around

 

Random picture of two idiots

http://thekimkardashian.com/blog/na/2010/7/2/tn_Reality-Tv-Star-Kim-Kardash.jpg

Edited August 26, 2011 by ClimberD@HexMods

[bmx045]

idiot or not I'd tango

[scoobyscoodle]

They look smart.

[bmx045]

yes, externally smart

[scoobyscoodle]

Looks like they have quite large medulla oblongata's

[utc_pyro]

Just to add a few things based on the last few pages:

 

The 05-06 TCU is based on the M32R, the same old-ass ECU used in the late 90's-early 02's Impreza RS, along with many other Subaru’s. It's rather old, so getting test equipment and documentation for it is somewhere between extremely difficult/expensive to impossible. Coby has the tools sitting around to do it, but no motivation. A few of the early Evo hackers also have the equipment, but also no motivation to work on our transmissions.

 

The 07-09 TCU is based on a modern processor, with lots of documentation and devkits, and is flashable in the EXACT SAME method as the ECU, but with a different address. The Germans working on the diesel legacy/outback actually managed to get into it.

 

Both are based on a Hatachi platform from what I can tell. Logic is probably similar as well, might be even off the same code base, but the CPU core and flashing method are different.

 

As stated before, the '05 Test ECU plus seed cash can be sent off to Cobb, Coby, or another known tuning house if you guys get them interested. Without a devkit or affordable flashing tools I'm over my head on this.

 

Also I have the files for doing the flash with SSMIII, but they are encripted/padded. the SSMIII software also willnot run without the hardware attached, so I cant intercept it. If you think you can hack the file, I can send it to you.

[bmx045]

good to know! since freeSSM doesn't work on 07+ tcu's what can we use?...SSMIII isn't available to the consumer

[ClimberDHexMods]

utc_pyro excellent post. Have you or anyone else talked with Cobb or Coby about the nitty gritty of a contract involving pay for service? Because if they can do it, it sounds like money will be the motivator. And as anyone with a lick of business experience knows:

a) Pay up front at your own risk (and here I see a huge risk since they have no personal incentive to complete this project without the prospect of payment at the END of project completion and beta testing). This would be a good use of escrow or perhaps some informal type of escrow such as funds collected and held in advance in a paypal account, whatever all parties can agree to.

b) Clearly define the extent to which various portions of the TCU must be hacked. If they only define some specific tables and not others, then many people may find themselves having paid a small fortune to be able to tune line pressure, but not shift input-to-action delay or individual clutch pack solenoids ramp-up / ramp-down, temperature compensation, speed compensation, etc. I haven't even mentioned tuning shift points, which also have base table(s) and compensations. An example would be when Cobb first hacked the R-35 GT-R, they found the main timing tables, but not all the compensation tables. So people would do two seemingly identical pulls, and timing would be 3* off from one to the next, meaning you really had to guestimate the right way to setup timing so you 'probably' wouldn't knock. I just have a concern that, like anything, it would be awesome if done right, but would need to be done at least largely right. You definitely want to get a handle on what the TCU calculates what 'might' happen when you stab the accelerator pedal, as there are tables much like tip-in, which read the rapid change of the pedal, and up the pressure for a certain amount of time, even after you have let off the gas. This leads to reasonable shift firmness when stock, and a hard thump when everything is all turned up. It's those kinds of details that will have an effect on end user satisfaction. It would be equivalent to defining boost and wastegate tables, but not TD. So you could up the boost, but it wouldn't be super stable. The magic (these days) is in having boost be stable. Same thing.

 

All that said, there is of course strong interest and money behind it, and if done right, it would truly change the paradigm of the later GenIV 5eats, in a huge and excellent way. Please do not confuse my cautionary words with criticism. Sometimes I feel like the guy telling his friend to not go cliff diving until he's verified the depth of the water. "Don't be so negative ClimberD, just jump and it will be fine." I don't want to hear it

[utc_pyro]

Personally I didn't speak with anyone directly about having them take over from the preliminary work. Those negotiations might be more up your professional ally ClimberD .

 

If we can get Coby on the project, we can get the raw ROM file. We get that, then the community can figure out the definitions. Cobb or another tuning house, eh, might be more of an issue.

[ClimberDHexMods]

What we need is a proper project manager. Most people on here actually DO the projects and are managed by managers. We need the manager, the guy who doesn't actually do the doing... Though maybe I am being too ideal.

[subarutech77]

Not sure if this helps much, but awhile back dschultz suggested using the RR test app to read a block of memory from the tcu. Starting at address 0x040000 for 1024 bytes.

 

Here is the raw data result of that read of an 05 OBXT 5eat:

 

6003F000A00DC8AD1FCEF0006004F000A00DC8AD1FCEF0006005F000A00DC8AD1FCEF0006000F000A00DC8AD1FCEF0006001F000A00DC8AD1FCEF0006002F000A00DC8AD1FCEF0006006F000A00DC8AD1FCEF0006007F000A00DC8AD1FCEF00084ADD5082094610100E120046204F000A20DC8AD1FCEF00084ADD5082094610100E12004A10DC8AD1FCEF00084ADD5082094610100E120046206F000A20DC8AD1FCEF00084ADD5082094610200E120046201F000A20DC8AD1FCEF000A09DCAD06101F000B011000484ADD5082194620201E221046001F000A00DC8AD1FCEF00081ADD4CCA0BDD4B4B0900003A29DD4BCB082000260007F1EA0BDD4B8B0800009A2BDD4B0B082000260007F052091505EB0B0000260017F026000F0007F14F0002091505DB0B0000260027F112091505EB0B00009A09DC8B66202F000B0120006E401D1C42294F000A39DC88702437D0260027F07A0BDD4B0B09000032291525EB0A2000260007F026001F000A00DC8B31FCEF0002E7F2A7F297F287F8AADD4CCA99DC887A09DCAFF6101F000B011000269FF5918A09DC8B3B0900022A29DC80A6100F000A0CDC9F4FE0013D1188011895158511880C000FF01407C0362FF5218B0120004209A610200E1200A7F04F000209AF00080C0FFFD200AF000A29DC80A6100F000A0CDC9ECFE0013C11880595859185058501809407C0361FF5118F000B0110004209A610400E1200A7F04F000209AF00080C0FFFB200AF0007F4BF0006101F000B00100076102F000B0110025219A515EB0B10023219A515DB0A10021A29DC80A6100F000A0CDC9F8FE0013A8188011895158511880C000FF01407C0662FF5218B0020004229AF00082C2FFFD220A7F03209A610200E1200AA29DC80A6100F000A0CDC9ECFE0013991880595859185058501809407C0361FF5118F000B0110004209A610400E1200A7F04F000209AF00080C0FFFB200AF0007F23F000A09DC8B36102F000B0110020A29DC80A6100F000A0CDC9F4FE001385188011895158511880C000FF01407C0362FF5218B0120004209A610200E1200A7F04F000209AF00080C0FFFD200AF000A29DC80A6100F000A0CDC9F0FE0013751880595859185058501809407C0661FF5118F000B0010004219AF00081C1FFFB210A7F03209A610400E1200A209A505EB0A00006209A505DB0A00004209A610100E1200A7F04F000209AF00080C0FFFE200AF00028EF29EF2AEF2EEF1FCEF00083ADD4B082ADD4B4A09DC7E791F00084B001000991F00084B001000791F0008CB0010005E401D1C52194F000A09DC80700417D0260017F09E401D1C6219400417C04F000E601D1C7259605407D02F00060027F026000F00081C000FF6401F000B11400062493F00084C4FFFE2403640125B205E425227F0D6002F000B110000620936401

I also have a java command line app that parses this text representation into pure hex format courtesy of dschultz, but still can't wrap my head around any of it. Reading a datasheet for a processor is one thing, understanding what I've read is quite another.

[bmx045]

fascinating....... who would need to read that? a software engineering or?

[hadvw]

fascinating....... who would need to read that? a software engineering or?

 

Someone who understands what format the numbers are in, what they are used for, etc..

 

At this point, it's just a bitstream, and could in theory mean anything..

[utc_pyro]

Not sure if this helps much, but awhile back dschultz suggested using the RR test app to read a block of memory from the tcu. Starting at address 0x040000 for 1024 bytes.

 

Here is the raw data result of that read of an 05 OBXT 5eat:

 

6003F000A00DC8AD1FCEF0006004F000A00DC8AD1FCEF0006005F000A00DC8AD1FCEF0006000F000A00DC8AD1FCEF0006001F000A00DC8AD1FCEF0006002F000A00DC8AD1FCEF0006006F000A00DC8AD1FCEF0006007F000A00DC8AD1FCEF00084ADD5082094610100E120046204F000A20DC8AD1FCEF00084ADD5082094610100E12004A10DC8AD1FCEF00084ADD5082094610100E120046206F000A20DC8AD1FCEF00084ADD5082094610200E120046201F000A20DC8AD1FCEF000A09DCAD06101F000B011000484ADD5082194620201E221046001F000A00DC8AD1FCEF00081ADD4CCA0BDD4B4B0900003A29DD4BCB082000260007F1EA0BDD4B8B0800009A2BDD4B0B082000260007F052091505EB0B0000260017F026000F0007F14F0002091505DB0B0000260027F112091505EB0B00009A09DC8B66202F000B0120006E401D1C42294F000A39DC88702437D0260027F07A0BDD4B0B09000032291525EB0A2000260007F026001F000A00DC8B31FCEF0002E7F2A7F297F287F8AADD4CCA99DC887A09DCAFF6101F000B011000269FF5918A09DC8B3B0900022A29DC80A6100F000A0CDC9F4FE0013D1188011895158511880C000FF01407C0362FF5218B0120004209A610200E1200A7F04F000209AF00080C0FFFD200AF000A29DC80A6100F000A0CDC9ECFE0013C11880595859185058501809407C0361FF5118F000B0110004209A610400E1200A7F04F000209AF00080C0FFFB200AF0007F4BF0006101F000B00100076102F000B0110025219A515EB0B10023219A515DB0A10021A29DC80A6100F000A0CDC9F8FE0013A8188011895158511880C000FF01407C0662FF5218B0020004229AF00082C2FFFD220A7F03209A610200E1200AA29DC80A6100F000A0CDC9ECFE0013991880595859185058501809407C0361FF5118F000B0110004209A610400E1200A7F04F000209AF00080C0FFFB200AF0007F23F000A09DC8B36102F000B0110020A29DC80A6100F000A0CDC9F4FE001385188011895158511880C000FF01407C0362FF5218B0120004209A610200E1200A7F04F000209AF00080C0FFFD200AF000A29DC80A6100F000A0CDC9F0FE0013751880595859185058501809407C0661FF5118F000B0010004219AF00081C1FFFB210A7F03209A610400E1200A209A505EB0A00006209A505DB0A00004209A610100E1200A7F04F000209AF00080C0FFFE200AF00028EF29EF2AEF2EEF1FCEF00083ADD4B082ADD4B4A09DC7E791F00084B001000991F00084B001000791F0008CB0010005E401D1C52194F000A09DC80700417D0260017F09E401D1C6219400417C04F000E601D1C7259605407D02F00060027F026000F00081C000FF6401F000B11400062493F00084C4FFFE2403640125B205E425227F0D6002F000B110000620936401

I also have a java command line app that parses this text representation into pure hex format courtesy of dschultz, but still can't wrap my head around any of it. Reading a datasheet for a processor is one thing, understanding what I've read is quite another.

 

Looking at the speck sheet, that address maps to "CS2 Area". My sleep depribed mind cant figure out what it's used for, but something having to do with a external data bus (CS= Chip/Channel Select maybe?).

 

The ECU's likes to remap things (what you request via SSMIII isn't the REAL memory address), so it's hard to tell what this might actually be. But they did pull the rom out of some old M32R ECU's using this method.

 

edit: Can you provide the formatted hex (as in just the date, no ssmIII commands)? I tried to decompile it by hand just to realize there was a tone of SSMIII garbage in there as well.

Edited September 7, 2011 by utc_pyro

[bmx045]

is there any form or fashion to acquire a SSMIII to gain communication with the tcu as the device has the capabilities already? Or hell, aren't there previous SSM's that are available?

[NSFW]

What we need is a proper project manager. Most people on here actually DO the projects and are managed by managers. We need the manager, the guy who doesn't actually do the doing... Though maybe I am being too ideal.

 

What y'all need is someone who knows how to do this and is motivated to get it done. Would-be managers are everywhere, it's the people who can and will do this kind of work that are scarce.

 

I'm willing to take a shot at it if someone can get me a ROM image, but I can't promise that I'll get anywhere with it. I am getting the hang of reverse-engineering our ECUs, but I'm not sure I would have gotten anywhere without RomRaider's definitions as a starting point.

 

I tried converting that hexadecimal string to binary, and opening it with IDA, but it doesn't appear to be M32R code. Reading a block that starts from address zero (rather than 0x040000) might be more fruitful, but that's still just a shot in the dark.

[dschultz]

edit: Can you provide the formatted hex (as in just the date, no ssmIII commands)? I tried to decompile it by hand just to realize there was a tone of SSMIII garbage in there as well.

There's no SSM stuff in that string of code. It's the hex result of the read X number of bytes at the arbitrary address of 0x40000.

 

it doesn't appear to be M32R code. Reading a block that starts from address zero (rather than 0x040000) might be more fruitful, but that's still just a shot in the dark.

Agreed about it's not code, but it could be table data/parameters of some sort. But you can't use SSM to read address 0x0 as that results in a virtual address, which is used for standard SSM parameter logging.

 

SND [init]:    8018F001BF48
RCV [init]:    80F01839FFA6102291FE2163000100800400000000A1462C000800000000000000DC06000B29C0047E011E003E00000000000080A20000FEFE000000001E
Trans = E-5AT

Attached is the data pulled from that one read. (Remove the .csv from the filename.)

MB436G.hex.csv

Edited September 8, 2011 by dschultz

[utc_pyro]

Reading a block that starts from address zero (rather than 0x040000) might be more fruitful, but that's still just a shot in the dark.

 

Gave that a shot a few months ago with the program you provided, and it didn't turn up anything useful. That said my laptop/cable interface was also picking up gibberish so who knows.

 

If I'm not mistaken, there was talk on the old M32R ECU's about the entire flash memory space being accessible, but at some offset. They were able to dump entire roms that way, but no progress past that.

 

On the data in the block, the first 96 bytes are a 12 byte long pattern that keeps repeating (only differences being the last three bits of the second byte).

 

Edit: See here about memory offset and M32R Subaru ECU's: http://www.subiesmart.com/forum/index.php/topic,28.0.html

Edited September 8, 2011 by utc_pyro

[hadvw]

What y'all need is someone who knows how to do this and is motivated to get it done. Would-be managers are everywhere, it's the people who can and will do this kind of work that are scarce.

 

Agreed. Good luck. Wish I had more time (job with tight deadlines currently, wife, 2 small kids..).

 

I work in EDA (one of the big 3 for EDA software), so if someone can figure out which chip they need documentation for, there's a small chance I might be able to help obtain it, assuming it's not available online.

 

And, I could help with a bit of general-purpose programming (C/C++/Java), but I'm assuming I'm not the only one here with those skills..