RomRaider

Ayayayay... the Denso TCU ROM is tough going... I've been chipping away at @ajayel's Outback TCU ROM.

Some tables have the same format as ECU tables, and there are extra table formats. All up some ~1500 tables along with ~3800 functions. Lots of gbr addressing too which makes referencing messy.

However, I'm pretty sure I have found the shifting tables. See pics.

Next I will look at what ROM integrity checks there are, because these will need to be understood before flashing will be effective.

Is that rom similar to my SH7058 TCU or is it completely different ? Did you compare them ?

Hi guy's,

I recieved my new Openport (last decided to dead ....)
Can you create a summary or how to do on first post?

I will try to download my TCU after.

@riksk - the shift curves in your ROM - there are 12 table headers that start at 0xe9080. Each table is 15 x 5 (ie: the start of each header is 0x00 0x0f 0x00 0x05).

@kiki86 - to download your TCU ROM - make sure you can get normal FastECU working, then use FastECU_TCU019.exe, ssmk_tcu_CAN_SH7058.bin and protocols.cfg from the repo

So, it looks like Denso ROM integrity checks are the same for TCUs as they are for ECUs. There is a table at the end of the ROM structured like this:
0xffb80 [start address] 4 bytes
0xffb84 [end address] 4 bytes
0xffb88 [chksum balance] 4 bytes

The above 12 bytes repeat if there are multiple ROM blocks checked.

The simple 32 bit sum across [start address] to [end address] (inclusive) plus [chksum balance] needs to equal 0x5aa5a55a.

The FastECU Denso TCU module needs to be expanded to allow flashing, but that should essentially be a copy of the existing ECU flashing module. So, the pieces are now in place to try a TCU ROM edit and flash. The usual risks apply regarding flashing, although options to recover from a bricking will include the Denso recovery method and SH boot mode (already done by @riksk).

Who is ready to try a flash?

Using Denso recovery over CAN, it may access the TCU, or the ECU, whatever controller responds first, since the access method is pretty much the same. So then flashing a TCU over CAN using the recovery method, you either have to pull the ECU fuse or disconnect it completely to prevent access to the ECU instead.

Same for the ECU on CAN cars, to use Denso Recovery method over CAN on the ECU, if the TCU is SH7058, you have to disconnect the TCU, otherwise it might happen exactly what happened to me; Trying to write over an ECU lead to a TCU write.

Also, just to clarify, I have sucessfully recovered my TCU using the Denso recovery method over CAN, I haven't tried the SH boot mode yet on the TCU, I believe it will work just fine as the controller is also SH7058. However I'm not sure about the test pads on that board yet, I forgot to take pictures of the other side of the board to check if any test pads exists there.

I just pulled. The ROM off my 09 FXT TCU.

I'm keen and almost ready - I'm currently tracking down a backup 3.0 TCU locally as I bricked my ECU a few years back and need a plug and play backup for the daily driver. Appreciate that there are a huge number of tables and functions in the Denso TCU ROM I am interested in how calculated torque, requested torque, other ECU or CAN params play into the shift equation and wish I could help more but don't have the skills. Thanks again for sharing your incredible work!

@curt4576 - thanks for having a go, however, that ROM file looks like it didn't work. Can you post up the log.txt file?

@ajayel - sounds good, let me know when you're good to go. Is there a particular table you're interested in? Is there any more detail on how it works (eg) the ECU sends a request via byte [x] of a CAN ID [yyy] message. The TCU then targets this torque by changing [???] which then changes [???]. The TCU then replies with CAN ID [zzz]. Any tiny little bits of info can hugely help tracking down the particular table.

I think it goes just like ECU sends continuously data over CAN and different controllers use that data for their needs. There is some info on internet for data and values that ECU sends and what I have logged from 2003-2007 Legacy ECUs, there is CAN ID 0x4?? and 0x6?? data sent over CAN with some 0.1s (or 0.01s) interval. Unfortunately I didn't save those data values anywhere...

TCU might then send some data back to ECU when it needs to manipulate ECU behavior when shifting normally/wot (ign retard/fuel cut).

Obsolete Denso 4AT TCM use completely another approach.

I was just thinking about my ECU's Requested (0xff8264) and Calculated Torque (0xff65cc) params as there's discussions if the transmission uses them or if they are just for ECU throttle control. It's more out of curiosity but thought it could be interesting to finally see things from the TCU's perspective!

2011 Forester 4EAT and 2011 Forester 5EAT seems to use the same TCU (same Part number).

I have yet to pull the ROM from the 4EAT TCU (don't have access to one right now), but pretty confident it will use a similar ROM.

are you sure that Forester had BOTH transmissions in the same year?
https://parts.subaru.com/ - this doesn't even offer 5eat...

Yeah I personally own an 5EAT version.

Forester S Edition 5EAT.

It's an EJ255 Forester with a VF52 turbo from the factory, same as the GR WRX.

Stock 17 inch STI wheels (same model from the 18 inch wheels, but it's 5x100 and 17 inch), blue alcantara interior, 5EAT transmission, etc...

The Forester XT and LX variant (2.0 n/a) has the 4EAT.