5EAT TCU Reverse Engineering

[utc_pyro]

Great info roadie08. So is each CAN message an upshift or was that just the data sent by the BIU (0x514) over some time period (including a shift)?

 

Looks like some of the frames have been decifered already:

https://subdiesel.wordpress.com/ecu-analysis/can-messages/#x514

 

Also I'm having a hard time figuring out those messages, they seem too long. Does the USBtin parce out some of the fields for you?

[roadie08]

Great info roadie08. So is each CAN message an upshift or was that just the data sent by the BIU (0x514) over some time period (including a shift)?

 

Looks like some of the frames have been decifered already:

https://subdiesel.wordpress.com/ecu-analysis/can-messages/#x514

 

Also I'm having a hard time figuring out those messages, they seem too long. Does the USBtin parce out some of the fields for you?

 

Yes its only upshifts when the button or paddle is pressed and they look diffrent from the ordinary BIU messages described on subdiesel. I havent checked any other messages from the BIU yet.

 

I think the lenght is correct. 514 (sender BIU) 8 (the message is 8 bytes) 2000730048931500 (8 byte message)

[hadvw]

Doing a quick google on "can bus 0x148", I found this:

http://www.ft86club.com/forums/showthread.php?p=284796

which says 0x148 is "gear selection".

 

Does this mean the t5 is his sniffer/software's way of saying 0x, so the messages should really read:

Engine on D mode

0x1482000730048931500

0x1482000730048931700

0x1482000730008921900

0x1482000730008921B00

0x1482000730048911D00

0x1482000730048911F00

0x1482000730088911100

 

Driving slow in D mode

0x14820007300C8A41D00

0x14820007300C8A41F00

0x1482000730088A31100

0x1482000730088A31300

0x1482000730008A31500

0x1482000730008A31700

0x1482000720088A81B00

0x14820007200C8A31D00

 

WOT in Sport mode

0x14830006F0008EB1300

0x14830006F0008EC1500

0x14830006F0008EC1700

0x14830006F0048EA1900

0x14830006F0048EA1B00

0x14830006F0088EA1D00

0x14830006F0088EA1F00

0x14830006F0048D21B00

0x14830006F0008D41D00

0x14830006F0088CD1100

 

Which ends up with nice 8-byte payloads?

Edited May 23, 2017 by hadvw

[nightfire37]

This is really great info. Keep this up and we might have everything we need.

[utc_pyro]

Yes its only upshifts when the button or paddle is pressed and they look diffrent from the ordinary BIU messages described on subdiesel. I havent checked any other messages from the BIU yet.

 

I think the lenght is correct. 514 (sender BIU) 8 (the message is 8 bytes) 2000730048931500 (8 byte message)

 

Well I feel stupid, hex = nibble = 4bits, two nibbles = 1bite, 16 hex caricters = 8byte field.

 

It's not like I don't ever have to use this for work!

 

Edit: Was the temperature when you logged these about 17.5C in D and 15.5C at WOT?

 

Doing a quick google on "can bus 0x148", I found this:

http://www.ft86club.com/forums/showthread.php?p=284796

which says 0x148 is "gear selection".

 

Does this mean the t5 is his sniffer/software's way of saying 0x, so the messages should really read........

 

I think roadie08 is right with it being 11-bit message (t), address (514), a length field (8), and a payload. His canbus adapter uses LAWICEL CAN protocol, and that's the same format you'd send that message back to the TCU.

 

Also the BRZ has some additional can modules that we dont, so it may be select by wire over CAN. On our cars the buttions are wired straight to our BIU. There probably is a gear postion message being sent to the BIU though, as it has to then retransmit that on the low speed bus to the gauge cluster.

Edited May 24, 2017 by utc_pyro

[hadvw]

I think roadie08 is right with it being 11-bit message (t), address (514), a length field (8), and a payload. His canbus adapter uses LAWICEL CAN protocol, and that's the same format you'd send that message back to the TCU.

 

Also the BRZ has some additional can modules that we dont, so it may be select by wire over CAN. On our cars the buttions are wired straight to our BIU. There probably is a gear postion message being sent to the BIU though, as it has to then retransmit that on the low speed bus to the gauge cluster.

 

Yeah, after posting that, I think they misread the 0x5148 messages 0x148 (i.e. dropped the 5).. So now we need to figure out exactly which subfields are doing what..

[utc_pyro]

Ok, comparing the Subi Diesel CAN data to this everything appears to match.

 

D-Mode:

51482000730048931500

 

Address: 514

Length: 8

Byte 0: 20 - Switches - 0010 0000

Byte 1: 00 - Flags

Byte 2: 73 - Ambient temp - 17.5C

Byte 3: 00 - His lights were off

Byte 4: 48 - Fuel level, fans, and some other stuff (varies a lot)

Byte 5: 93 - Fuel level (varies a lot)

Byte 6: 15 - Counter

Byte 7: 00 - Flags

 

Sport mode:

514830006F0008EB1300

 

Byte 0: 30 - Switches - 0011 0000

 

So based on that, I think bit 5 is shiftup, and bit 4 is sport mode.

Bit 3 of byte 4 might also be of interest, but we'd need other data point to compare.

 

Can you log a down shift for us? Both in sport mode and normal?

Edited May 24, 2017 by utc_pyro
Legability

[roadie08]

Yes my lights where off!

 

I will log some downshift later.

 

I think downshift starts with

51484 drive

51485 sport

[utc_pyro]

I think downshift starts with

51484 drive

51485 sport

 

Drive - 0100

Sport - 0101

 

So looks like bit 6 is the downshift button!

[hadvw]

According to subdiesel, bit 2 is "reverse". That should be easy to verify. Maybe also try Park and Neutral?

 

roadie - do you have SI/S/S# buttons (or whatever it is)? Can you see if they make any difference?

 

The fact that roadie noted earlier that the message from the BIU comes right away, makes it sound like it's the TCU that's deciding when to shift. A common thing I run into in GUI programming is the following: when to redraw the screen. I.e. if the user requests "change object 1", it's easy - just redraw after the change. But if the user requests "change objects 1-10,000", doing 10k redraws will be VERY slow, and you only need one redraw. But, what if the GUI isn't triggering the "change objects" message, and due to the architecture, you don't know if the notification you just got that an object changed is the last one or not? You set a timer, collect all the "object x changed" notices until the timer expires, and THEN do a redraw for the change notices you have. Say, 1-2 seconds. That way, the GUI doesn't seem to freeze forever, even during a long change, and the extra overhead usually isn't much.

 

This sounds like the TCU trying to be smart, especially because by default, it can't shift very fast. So if, it takes 3 seconds to shift, it should wait 1-2 seconds in case a SECOND up/down shift comes in, and then it can go right away from 1 to 3, or 2 to 4, or 5 to 3 (all if allowed).

 

It seems to beep right away if I try to downshift too far (i.e. go further than I'm allowed to) - is that the TCU or the ECU generating the beep?

(Edit: ok, on second thought, I don't do this too often, so maybe I'm wrong, and there's a delay here - will have to try today..)

 

roadie, do you get a beep if you try to shift down too fast (i.e. from 3 to 1 when at 3-4k rpm in 3rd)? If so, can you see if there's a shift event related to that? If so, then does that mean the BIU is just generating shift events, and the TCU is returning back an error code, saying "nope, too far", and then the ECU is generating a beep in response? As I understand it, all the modules on CANBUS are always listening, so it sounds like in this case, the flow is: BIU send shift, TCU processes it - either batches it for next shift, or says "nope" and aborts. If TCU says "nope", ECU beeps.

 

I hadn't really thought about it much before, but based on the new info, it does seem like it's the TCU "batching" shifts, because it knows its slow. Maybe there's a "here's how long it takes to shift" and "wait this much of a shift duration" timer setting that we can update, since with F1 we can shift much faster? And maybe we can up line pressure as well.. Of course, need to be careful that we don't overdo it, and cause the TCU to try to shift twice or something..

 

Way back, I seem to recall GIAC getting the Passat's 1.8T Tiptronic to shift in 125 ms. That 125 ms was probably a similar "broadcast every nn ms" type of restriction. Except ours seems to be every 20 ms?

[roadie08]

I dont have SI/S/S# but I have the beep when downshift too fast.

 

Yes BIU sends the message directly. If you press the button it will generate shiftmessages as long as it is pressed.

When I shifted from my computer it was exactly as slow as from BIU.

 

Need to find the canmessage input in tcu rom.

[nightfire37]

Any updates roadie? Just curious since how it has been quiet for the last few days

[roadie08]

Any updates roadie? Just curious since how it has been quiet for the last few days

 

No, havent had any time for canbus logging lately. I will probably log all shiftmessages this weekend.

 

Only thing I have done is changing the "Calculated torque" table. I feel difference at part throttle but hard to say if it is a difference at WOT.

 

 

Anyone getting anywhere with the dissassembly?

Edited June 1, 2017 by roadie08

[utc_pyro]

No, havent had any time for canbus logging lately. I will probably log all shiftmessages this weekend.

 

Only thing I have done is changing the "Calculated torque" table. I feel difference at part throttle but hard to say if it is a difference at WOT.

 

Did you observe how changing calculated torque effected messages sent by 0x410?

 

Also where did you tap into the CAN bus for your USBtin? Mine got here yesterday and I want to dig into the messages between the TCU and ECU.

[hadvw]

Just a couple of observations:

-if I try to shift "too low" for a given speed (i.e. into 1st from 2nd when at 4000+rpm), the beep of "can't shift" is instantaneous

-when I make an allowed gear change, the display of which gear I'm now in (i.e. if I change from 1 to 2, the display of "2") also seems instantaneous. Even if the shift hasn't happened yet.

 

So it seems the ECU controls if/when we are allowed to shift (based on simple rpm), and then the TCU decides when it makes sense to shift?

[utc_pyro]

Just a couple of observations:

-if I try to shift "too low" for a given speed (i.e. into 1st from 2nd when at 4000+rpm), the beep of "can't shift" is instantaneous

-when I make an allowed gear change, the display of which gear I'm now in (i.e. if I change from 1 to 2, the display of "2") also seems instantaneous. Even if the shift hasn't happened yet.

 

So it seems the ECU controls if/when we are allowed to shift (based on simple rpm), and then the TCU decides when it makes sense to shift?

 

More logging on the bus in these situation could help identify how that logic works. As the messages are transmitted instantly it may be the TCU sending a "nope!" command back to the BIU, but we'd need to watch the traffic and see if that's actually what's going on.

 

Also the more CAN messages that are decoded, the easier it'll be to pull apart the ROM. To make sense of the sea of memory locations that are moved or modified, you need to correlate some of them with something you know. So it's smart to start with things like identified canbus and SSM addresses and use those to name memory locations. Once you start naming memory locations, that move 0xf751 to register 2 multiply it by 0x80 and compare the product to location 0xB0A4 becomes if speed * 128 > rear turbine RPM do something.

 

When I was looking at that JDM rom it wasn't falling apart easily, so I decided to wait until we can get a USDM rom to play with. The only disassembly I've done before was back in collage (that was a fun Microprocessor midterm ), so I'd rather put the time climbing the learning curve into something that is closer to my car. Thanks to ClimberD the '05 TCU in OP is currently on it's way to Russia to have it's ROM pulled so we can start picking at it.

Edited June 1, 2017 by utc_pyro

[nightfire37]

No, havent had any time for canbus logging lately. I will probably log all shiftmessages this weekend.

 

Only thing I have done is changing the "Calculated torque" table. I feel difference at part throttle but hard to say if it is a difference at WOT.

 

 

Anyone getting anywhere with the dissassembly?

 

Try what hadvw and pyro suggested. Im curious what we can pull from that

[roadie08]

Did you observe how changing calculated torque effected messages sent by 0x410?

 

Also where did you tap into the CAN bus for your USBtin? Mine got here yesterday and I want to dig into the messages between the TCU and ECU.

 

Canbus logger was not connected.

 

In my 2005 RHD JDM can connectors is next to the BIU.

White connector with red and blue wires.

Red=CANH

Blue=CANL

 

http://i.imgur.com/hJJvsCS.jpg?1

 

In newer cars its probably in the obd port.

 

 

Try what hadvw and pyro suggested. Im curious what we can pull from that

 

I will try, just need to find something that I understand in the rom

 

 

Thanks to ClimberD the '05 TCU in OP is currently on it's way to Russia to have it's ROM pulled so we can start picking at it.

 

Great.

Did you try to pull your rom with ecumem?

[utc_pyro]

Canbus logger was not connected.

 

In my 2005 RHD JDM can connectors is next to the BIU.

White connector with red and blue wires.

Red=CANH

Blue=CANL

 

http://i.imgur.com/hJJvsCS.jpg?1

 

In newer cars its probably in the obd port.

 

Is that a conector that's just hanging there, or is it unplugged from the BIU?

 

Great.

Did you try to pull your rom with ecumem?

 

Yep, it spat out something but it didnt look like a valid ROM. I had the same results back in 2010/2011 when NSFW wrote a program that works the same way. They could have started at some odd point in the rom and put something else in the first few pages of flash though, I didn't dig too far into it.

[roadie08]

Is that a conector that's just hanging there, or is it unplugged from the BIU?

 

 

 

Yep, it spat out something but it didnt look like a valid ROM. I had the same results back in 2010/2011 when NSFW wrote a program that works the same way. They could have started at some odd point in the rom and put something else in the first few pages of flash though, I didn't dig too far into it.

 

Yes it is just hanging there. Look for twisted red and blue wires.

 

Ok. Iam interested to take a look at your rom when you get it

[utc_pyro]

hadvw, Per your questions on the shift indicator/inhibit: If you RTFM Subaru already tells us how this works.

 

 

So the TCU is what's sending the buzzer signal to the BIU to pass to the cluster. It also confirms what roadie08 saw in the BIU messages about the switches.

 

So the shift delay is pretty much confirmed as a TCU issue.

[roadie08]

Did some more canbus logging today.

Shifter P,D,R,N doesent make any messages.

 

D

Shiftup 51482

Shiftdown 51484

 

Sportmode 51481

Shiftup 51483

Shiftdown 51485

 

 

 

Brakepedal 514808

Ecomode 514802

 

 

 

Anyone know tcus canid?

http://i.imgur.com/6CxQD5D.png

Edited June 2, 2017 by roadie08

[utc_pyro]

So that confirmed what we saw before. It also looks like byte 0 bit 3 is the brake switch, and bit 1 is the eco switch. Bit 2 is supposed to be the reverse switch, but as you didn't see any messages change that may be published by the TCU on AT cars. Useful information for anyone making a TCU CAN spoofer for doing an AT -> MT swap.

 

Looking at the addresses, I think 0x420, 0x421, and 0x422 are the TCU. It's supposed to talk at the same frequency as the ECU, so the counters make sense. Also looking at other Subaru canbus addresses the pattern tends to be 0x4xx is drive train and 0x5xx is chassis. 0x41x is confirmed to be the ECU, 0x430 the DCCD, etc.

Edited June 2, 2017 by utc_pyro

[roadie08]

Alright.

Will log the 42x ids next time and try to find the tcu shift message bit for ignition retard

[nightfire37]

After some digging on the diseal stuff 0x410 is related to some transmission stuff

 

https://subdiesel.wordpress.com/ecu-analysis/can-messages/#x410