utc_pyro

A few of us are digging into the former right now. Sasha and roadie have gotten the furthest, but no one is anounced finding the counters. TC lockup changes have been acheaved via the calculated torque tables. Untill we get further into tearing the TCU code apart it's kind of guess and check to get whatever you're looking for. Theottlehappy clamed to have seen the table structure from a TCU memory dump, but he never shared this and his post history is gone.

I may have some work for you.... Can you do small runs in aluminum or FR4?

Finally back in country and have access to a real computer. Roadie: Are you digging into 91FE207100?

Not untill you fire up IDA or a hex editor and see if you can find anything. There are also online disassembaly programs that support this CPU if you don't want to deal with the cost or hassle of setting up IDA.

'05 USDM ROM is up thanks to the OP donors that bought the thing, ClimberD, and Sasha. http://www.romraider.com/forum/viewtopic.php?f=40&t=13725&p=128168#p128168

It's more "tell the TCU how much torque you're ACTUALLY making". Actually TCU flashing isn't quite here yet, at least in the English speaking world.

How are the C-Mod grills? I keep looking at getting an R-Rev but it sounds like they are barely in production right now.

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.

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.

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.

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.

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.

On the reverse light bulb adapter above. Here is the final product: Had to change a few things with it using epoxy and cutting, but the fixed version is up on thingiverse. Here is it installed on the car, it's the passenger side bulb: Subjectively it's brighter than the Philips 921 bulb in the driver side, and it's a slightly higher color temperature. "20W" T15 bulb only Philips bulb only I didn't take my light meter out and test, but it looks like the philips bulb is actually throwing the light further, while there is more of it to work with on the "20w" bulb. This seems to indicate that the bulb is too far in the housing. Need to print an "adjustable" version and find out.

Hey, they make HID based reverse lights so why not? These are basically the same thing as most aftermerket LED headlight bulbs. Absolutely useless for that application. But in a reverse light where the OEM bulb is only 18W and you only need to see 20ft they may just work!

https://www.thingiverse.com/thing:2353034 Designed an LED bulb adapter for wagon reverse lights. May work on the sedan as well, but I haven't looked to see if the mounting base is the same. This will let you use the CREE "20W" T15 led bulbs that look like aftermarket LED headlights. These actually run at ~10W each, but are a hell of a lot brighter than the stock bulbs.

Drive - 0100 Sport - 0101 So looks like bit 6 is the downshift button!

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?

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? 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.

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?

That was my original plan, but I ended up changing too many variables at once to get a valid before and after . I'll dig through some logs tonight to see what the shift speed actually is, then you could compare that to your logs. Sounds like any presumptions of if something is in the TCU or not was too early. What are you using to log and send canbus messages out of curiosity?

It is the alarm system. Along with being the CANBUS hub, lighting controller (depending on year), door lock controller, defroster controller, and a few other random things. Any delay in that guy would probably be software related, and there aren't a lot of people out there with the skill set to reverse engineer 15+ year old proprietary japanese microcontrollers.

Exactally what hadvw said. The button press to when the TCU decides the shift hasn't changed. What has changed is how the shift goes down once it decides to. They are rip the drivetrain out rally car quick now. This is with a Transgo shift kit (similar to the F1) and the calculated torque tables messed with. I've tried just scaling the CT table up, and two tables from tuners. The one that kind of matched the actual output of the motor had the best subjective feel. The RT tables seem to have more of an effect on shift point than sharpness of the shifting. I'm running a kind of linear tables based on NSFW's, and while that has changed the shift points it hasn't really changed the shift speed.

NSFW, take a look at the 5EAT Ask You're Questions starting around page 85. I think this post has your table address. Additionally as fahr_side stated there are a few good threads on romraider. Start here: http://www.romraider.com/forum/viewtopic.php?f=40&t=9358

What year? Edit: missed the '05 part. Will post the location of the table later so you can start digging into it.

You know the BIU has a delay counter to see if you're trying to change multiple gears at once right? Based on what're been found so far that's the likely delay spot. When the TCU decides to shift, it can do so extreamly quickly. I need to post a video of what my car does now, it shifts faster than my buddies S3 that has a DSG. After this is confirmed in the TCU code one could make a canbus module to simulate the BIU but not have the delay. The RT tables actually don't matter as much. The CALCUALTED TORQUE tables are the real deal in changing how things feel. They don't have that table defines in Romraider. ECUtec does though. Even worse: on the '05-'06 cars this table is based on injector pulse width. If you change the injectors without tweaking this, the transmission thinks the motor is putting out LESS powered and reduces line pressure and burnes out faster.