RomRaider

Quick look at the log shows everything is ok up to sending calculated seed key back to TCU and that point it fails (response 7f 27 35 = wrong seed key). Maybe it uses different key set or something so @rimwall can suggest what else to try

@V6er - MiikaS is correct, it is failing at the security key stage. Are you sure it's a Hitachi ROM? If you can find your TCU part number, we can probably confirm via web images. What happened when you selected SH7058 Denso (under the same Unknown section)?

@jimihimisimi - it worked this time (you can ignore the popup). The values are all zero. Which seems odd. Looking at the ROM further, it looks like these values are inputs only. They can be used to enter a value, but they aren't updated to reflect the current value. I'm also not sure how they interact with the 'learning' process. It might be that they are simply a starting point, and, over time, the TCU will drifts back to a learned state that it always ends up in. Or it might be that they are permanent offsets. I need to look at the ROM more. Do you know if your TCU supports K-line logging (eg: FreeSSM)? If so, we might be able to log some RAM values to confirm. Or we could just try setting one of the SSM parameters and see what happens...

The transmission was cold when I grabbed these readings... any idea if the TCU will respond different with temp?

that's the funny part - under unknown car - there is just one choice - that Hitachi. I tried generic car "SH7058 denso" something - but it produced some error again.
may be I messed up with copying over those kernels...?

Everything shown there is on protocols.cfg so if something is missing, you have wrong version of file. Did you copy it from rimwalls repo?

@V6er - it should look like the screen grab below

Been looking closely into the use of the input parameters. Essentially they look like they are pressure offsets for upward gear shifts (1->2, 2->3, 3->4, 4->5) in a similar manner to the adjustments that were available on a 4AT. There are also offsets for general line pressure and 4WD pressure. If they haven't been entered, then the TCU uses fixed hard-coded values. If any one of them is non-zero, then all corrections are zeroed out and replaced with values from a TCU relearn or from direct entry via SSM.

The DC/IC/HLRC/FB offsets increase target pressure for the clutch that engages in the 4 upshifts. The 4WD & PL offsets increase the associated pressure at all times (I think).

There is some sort of tuning of the DC/IC/HLRC/FB offsets, so it's hard to tell whether they are permanent or will get tuned away over time. There doesn't seem to be any tuning of the 4WD & PL offsets.

Of course, it's very hard to be certain about any of this. The complexity is horrendous.

A couple of options:
1. Someone can just try entering some values and see what happens. I think whatever changes occur are unlikely to be permanent, but reversal of these changes may not be immediate - the TCU may take a while to adjust.
2. Someone can help with some logging first to try and understand better. Still may not get to a place where everything is perfectly understood.

Ok, I've done some more digging. Here's a summary of how the SSM corrections interact with the TCU operation.

For upshifts (1->2, 2->3, 3->4, 4->5), the TCU tracks the pressure of the relevant clutch and works out an approximate linear relationship between Target Clutch Pressure (TCP) and Factored Engine Torque (FET) such that TCP = M x FET + O, where M = multiplier and O = offset. FET is Calculated Engine Torque (CET from the ECU via CAN) multiplied by a factor between 1.8 (when slip is at maximum - nil Turbine Speed) and 1.0 (when no slip - Turbine Speed equals Engine Speed). This relationship means that when CET is high and slip is high, the TCP will be very high resulting in a fast increase in clutch pressure to get the Turbine Speed closer to Engine Speed and rapidly reduce slip. It also means that, even when there is no slip, TCP increases with CET to keep the clutch engaged and stop any slip. On each cycle the TCU trials values of M and O slightly bigger and smaller than the current values, and chooses the values that give the best match to recent clutch performance. This allows adjustments for clutch degradation etc. The last 8 values of M and O are stored in RAM and on the EEPROM so they are available even after loss of power to the TCU. The TCU ROM also has what are essentially default values for M and O, which are used when brand new or after 'Clear Memory 2'. Let's call the default values M_d and O_d. As the TCU is updating M and O over time, the calculations of TCP have to be adjusted for changes between M and M_d and O and O_d. Most of the TCU calculations carry on unaffected and calculate TCP regardless of any changes in M and O, and then an adjustment to TCP is made as follows.



This provides a TCP each computational cycle using the latest values of M and O. M and O values from the same Transmission may be useful to track over time because they will probably indicate clutch wear. M and O can possibly be compared between Tranmissions although may not be directly comparable (because each Transmission will have minor dimensional differences which may affect M and O).

The SSM corrections (when entered) replace the value of O. There is some logic that attempts a smooth transition from the prior value of O, but this is transitory. Once O is updated, the automatic tuning of M and O carries on as normal, so it is possible that any adjustment to O will gradually be tuned away. However, an increase in O will result in a decrease to M, which may take the ongoing tuning to a different equilibrium point with a higher O. So it's also possible that the correction will be retained. *In addition, the automatic tuning of O is restricted to remain within a tight bound from the originally entered value of O, so this seems to indicate the correction will be mostly retained. A TCU relearn provides new values for O, which provide a new starting point for the ongoing tuning.

Other SSM corrections like Line Pressure and 4WD Pressure are much simpler. These flow directly through. The Line Pressure increase is relative to a default value and is only applied during normal gearchanges (ie) not limp mode settings.

There are no SSM parameters to read the current values of M and O. However, they are stored in a standard location in RAM before being transferred to the EEPROM, so they will be fairly easy to read from a K-Line enabled TCU or from a CAN TCU that has a logging patch applied. Alternatively, if M and O cannot be read, the default values can be extracted from the ROM and entered via SSM, which will effectively take the TCU back to a state from which it should gradually get to the same equilibrium values of M and O it had reached previously.

In nutting all this out, I did also find the ROM has the ability to add another offset to each clutch/brake, which is a simple increase / decrease to all pressures at all times. This might also be useful, but does require a reflash.

Does someone want to try out the SSM corrections? Let me know and I'll take a crack at the SSM commands...

[EDIT: *]

The upshifts on my car typically aren't a problem, mostly just getting into 1st. I wonder if increasing the Line Pressure or 4WD pressure would help or not.

I have not had luck with K-Line logging (not sure it's feasible with MY2014) and I am not comfortable with a guess-and-check approach as it is my wife's car. I would like to log pressure readings/etc before just throwing values at the TCU.

Edit: I will try seeing what RomRaider can do for logging with the TCU...

On CAN only cars, the SSM commands do not allow logging of any RAM address. A reflash with a patched ROM is required to enable this. I can patch the ROM if you want to do a reflash.

I have done the coding to try setting these parameters. All we need now is someone to try it.

Let's do it! My TCU from image is a few pages back.

Took a bit of fiddling, but here is a patched Tribeca TCU ROM. This has a different 0xa8 command handler to allow logging of any RAM address. The ROM checksum is also updated.

In the repo, there is also an updated version of FastECU (v0.24) along with an updated protocols.cfg. This will allow test-write and write of a SH7058 TCU ROM.

Always worth a reminder about the risks:
- do a full dump first and confirm dumped ROM is unchanged. This will check FastECU operation and check comms are stable and error free. Do a test-write before a write.
- the ROM patching may have bugs. It is based on the ECU patching, but has changes specific to TCUs and specific to the Tribeca ROM. I have re-imported it into Ghidra and it seems to disassemble and decompile into the expected function. But, there could still be bugs.
- the ROM checksum may be incorrect. It's the same method as ECUs, but a mistake is still possible
- the TCU flashing uses the exact same code as the ECU flashing (and ECU flashing has been demonstrated to work). But, this flashing approach (using SSM commands) has not been used yet on a TCU. A different flashing approach (using the Denso recovery method - which uses the same kernel) has been used on a TCU successfully.
- if something goes wrong, the TCU most likely will be recoverable using the Denso recovery method. But, of course, no guarantees. And get in touch *before* using this approach to avoid comms overlap with the ECU.
- if the TCU can't be recovered using the Denso recovery method, the next option is the SH boot recovery method (requires connections to the PCB and some hardware).

Let us know how it goes!

Currently doing some maintenance on the car, once it's back in once piece I will try pulling the TCU code again and let you know how it goes.

Hello!
So good to see news here! would love to participate, but I am getting stuck at those kernels. Here is how/what I did:
1) downloaded https://github.com/rimwall/fastecu-oem/ ... recompiled for windows
2) downloaded .exe file https://github.com/rimwall/fastecu-oem/ ... TCU024.exe
3) downloaded kernels https://github.com/rimwall/fastecu-oem/ ... er/kernels (though, looking at dates - they should be the same as in precompiled? and FC comparison agrees)
4) downloaded protocols.cfg https://github.com/rimwall/fastecu-oem/ ... tocols.cfg (it has newer dates than precompiled date)

I still get just one kernel:
https://prnt.sc/mSAguiboK3jw

since others have managed to get it running - there is some issue "between my ears"... may be someone can point to me to that issue?

Item 4 (protocols.cfg) should come from the development branch (not master)

With testing help from @ajayel and @jimihimisimi, we now have the ability to change the 'hidden' TCU parameters on 5EATs. Use TCU v0.27 from the repo to change pressure offsets for upshifts, 4WD pressure and Line Pressure.

General approach:

(Not all TCUs have the ability to alter 'hidden' values. So far I've seen it in Denso 5EATs but not in Hitachi 5EATs. This approach requires a TCU that uses CAN and also supports K-Line logging)

1. Log your current values by adding the following to your RR logger *.xml file. Replace XXXXXXXXXX with your 5 byte (10 nybble) TCU ID.



2. Review the attached pdf file to choose what offset you want to enter. For example, if your logged Line Pressure offset is 186 at a logged Temp of 50, this means your TCU is currently applying an offset of 7 kPa to Line Pressure. To increase Line Pressure offset by 23 kPa to 30 kPa, you want to enter a pressure offset of 178.

3. Enter your new values using the Read, Set Params option in Fast ECU v0.27. If you want to leave a value unchanged, enter your currently logged value. The 4WD Torque Correction can be entered as 0 if you don't want to change this. Do not enter a 0 for any pressures or the temperature (entering a zero stops any settings being saved). Note that the Read, Read Params option will only report back any values you have just entered. It does not report the values that the TCU actually uses for its calculations.

4. Log again using the RAM addresses above to confirm the values have been saved to your TCU EEPROM. Then log TCU pressures (using the normally available parameters) to see the effect on the pressures. Hopefully you will also feel the changes in how the TCU behaves.

5. If you don't like the new settings, just use the Set Parms process to reset to your originally logged values.

Note: this uses SSM set commands (ie: there is no flashing involved). This is still in Beta stage and may not be 100% correct. Let me know of anything that needs fixing.

Enjoy!