RomRaider

Hi All,

Recently I was playing around with my car again, and I decided to tackle an annoyance that had bothered me for a while. When using tools like BtSSM for logging via mobile app (Or on a head unit perhaps) automatic transmission users have probably noticed there is no way to read AT Oil Temperature. This isn't so handy if for example you are towing or racing and want to keep an eye on what the transmission is up to.

To get around this, I decided to have a go at hacking in the AT Oil Temperature value into an unused SSM Index in the SSM Table. I figured I'd post how to do that here in case anyone has any interest and wants to do the same at home. Note that you should already be familiar with Ghidra for this, and ideally you already want to have been doing a bit of Reverse Engineering of your ROM. If you aren't so sure, someone may be able to help you patch your rom, or I even may be able to assist.

Alright, onto the hack:

Firstly, you need to pick an unused (By the ECU) SSM Slot. There are actually loads that are not used by many ecus, but to keep it simple I decided to hack the slot that would actually be used by the TCU normally for it to report transmission temperature (When you are logging the TCU). For those playing at home, that slot is index 0x49. From what I can tell this shouldn't have any adverse effects, as you can only poll either the ECU or TCU, not both at once. All we have to do is edit the pointer at that index in the SSM Table to point to our hack code (check photo1.png). You can place the hack code anywhere there is room for it, but I chose to place mine just after the end of the factory code.



Next, we need the actual hack code. All it really does is extract the temperature byte from RAM (Which the ECU already gets for us via CAN Frame 0x422, but does not otherwise make use of) and then places that byte into the R0 register which is where the core SSM code expects the data when it requests it from our tiny fetcher. You can read about the CAN Frames the community already knows of here: https://www.romraider.com/forum/viewtopic.php?f=40&t=20850 (In case you wanted to log a different value not supported by SSM for example). One thing to keep in mind is that SSM outputs 16-bit words per item, so you won't directly be able to log floating point stuff, however in our case the AT Temperature is a Byte, so we are fine. Check photo2.png for my hack code.



Lastly, we need to locate the AT Temperature Byte (Don't use my location as it will likely only suit my ECU Software Version). To do that, we can just look for the CAN Frame 0x422 structure that declares where the Bytes Received via that CAN Frame should be stored. To do this in Ghidra, Press "S" to search memory, and search for 00 00 04 22 in hex. You should hopefully only get one hit, and right underneath this hex data, you should see a pointer (Photo3.png). Follow the pointer and you should see several RAM addresses containing One Byte Data (This is each of the 8 bytes from the CAN Frame). AT Oil Temperature is the 6th of 8 bytes in this frame, note down its address and use that in the hack code. Refer Photo4.png.




Lastly, all you need to do is tell your logging app to log a byte from SSM Index 0x49 (Or whatever one you used), set your minimum and maximum etc values and enjoy. In BtSSM, set up a custom value with index 000049 to achieve this, from what I can tell, the byte is unsigned and needs no correction formula, its units are degrees C.

Quick Side Note, The 5EAT has two temperature sensors, and I suspect the one that feeds the byte value given to the ECU is the Torque Converter Outlet Temperature rather than pan temperature, so you may notice it gets rather hot. I'm still working on confirming this part, if anyone happens to know I'd love to hear.

All the best!

Nice! Great work!

A few things to note:
- Index 0x49 is for ATF Temperature, but for the 4AT (oil pan, based on a nonlinear lookup table to convert to degC)
- Index 0x56 is for ATF Temperature Sensor 1 (oil pan) for the 5EAT
- Index 0x5A is for ATF Temperature Sensor 2 (torque converter outlet) for the 5EAT

Interesting that it worked without having to change the capability bits. The capability bits tell SSM which parameters a particular ECU can report. So, supposedly, for it to work you would have had to update the capability bits to say the ECU could report a parameter at index 0x49. Seems like whatever logging software you are using doesn't check the capability bits.

CAN ID 0x422 reports ATF Temp Sensor 1 (oil pan)

Hope that helps.

Appreciate the guidance on what sensor is reported! - I was seeing unrealistically high values at first (128c climbing a hill), but I later determined that the byte in RAM needs a fixed -40c offset applied to reflect true temperature (So actual temperature in my case was 88c), as do other common temperature byte values as they are not a signed byte, so that was a whoops on my part.

As for the capability bits, I figured there was a system like that (The logger has to have some way of knowing what is supported for reading I guess), but the beauty of BtSSM is that when specifying a custom SSM value to log, it will always forcibly log that value, even if unsupported. Normally that just means getting FFFF as the return, but it works out with a patch behind it, just no auto detection.

Any chance you can shine a light on those capability bits, can they be altered to mark my patched 0x49 as supported? I don't have in depth Reverse Engineering for my ECU yet, I was close but my PC crashed and set me back a bit.

The offset is -50 degC (it's different to the ECU for some unknown reason)

More info on the ECU capability bits here: https://www.romraider.com/index.php/RomRaider/SsmProtocol.

Similar to ECUs, the TCU capability bits are in the TCU ROM immediately after the last byte of the TCU ID. Each bit represents one of the parameters. The bits are in the same order as the parameters. What makes it a little tricky is that some parameters take up two index spots (eg: 0x0E and 0x0F for Engine Speed).

The most complete list of parameters I've seen is in RR's logger definitions file. Here is the definition for index 0x56....



ecubyteindex and ecubit indicates which is the associated capability byte/bit

Numbering of these bytes/bits starts at zero. ecubyteindex is in the index of bytes in a 0xBF response. ecubyteindex = 8 is the 9th byte in the 0xBF response which is the first capability byte. So ecubyteindex = 17 means the 18th byte in the 0xBF response which is the 10th capability byte in the ROM. And ecubit = 1 means the second lowest bit.

Hmm, at least for my ECU/TCU I am now certain the offset is -40 (this is the byte given to the ECU from the TCU via 0x422 I'm using so perhaps a compatibility thing?). Cold started the car this morning, outside air temp 17c and Reported Trans Temp with -40 offset was 18c.

I'll read up on those capability bits as that is rather interesting stuff, thanks again for that info. Just got done dumping my TCU ROM to play with directly, so I'll see how go with that and what else I can confirm.

That’s odd regarding the offset.

The 5EAT ROM I’ve RE’d reports ATF Temp as the same value via CAN 0x422 and via index 0x56 with SSM. SSM then subtracts the offset 50degC.

It’s possible your 5EAT is reporting ATF Temp via index 0x49. This uses a non linear lookup table to convert bytes to degC. A byte value of 0x3A = 58 converts to 15 degC using the non linear lookup table.

Perhaps have a look at your TCM ROM for the SSM_Base and see whether there is a non-null subroutine for reporting a value at index 0x49 or 0x56. There should only be one or the other, not both.

I'm about 5 hours into my TCU ROM as of writing this, I started with locating the CAN routines that handle inbound and outbound frames and now have documented all the variables that enter and leave the TCU via CAN messages (As per known can frame contents from that other forum post). I haven't found the SSM logic for my transmission, any chance you can share a tip on finding that?

As for the temperature data, I confirmed that my 5EAT internally stores the value of Pan and TC Outlet Temperature as x-50 as expected, but before sending the pan temperature via CAN, it corrects the value to be x-35 instead and then sends it out (Really strange stuff, we have not seen x-35 before ever. I'm wondering if its internally x-55 and CAN is x-40) I've attached a photo of the disassembly where this happens. I also confirmed this is not raw sensor voltage, there is a calibration table that converts ADC counts to a temperature value up stream of this.


Also interesting, my ROM makes Torque Converter Outlet Temperature available via CAN as well, in a bit position that is currently documented as not used / 0 (The one in between Pan Temperature and AT Desired Idle Speed). That's handy for me, but I suppose not all TCUs are doing this.


Evidently there is much to learn still with this TCU. Its worth noting mine is an M32r based Hitachi unit and not a SH based unit, Internal ROM ID: EMB562A80VF40B (I assume, seems to be the only string in the entire file).

I agree, odd that it subtracts 0xf.

The one thing that should be certain is that the ATF temp reported via SSM in the TCU ROM should have an offset of 50 degC. Locating the SSM ATF Temp, and tracing calcs between it and the CAN 0x422 ATF should provide certainty on the offset.

SSM_base can be found in the TCU in the same way as an ECU. It is similar whether Denso or Hitachi.
1. Find the TCU_ID in the ROM (or RR will report your TCU_ID). Your TCU ID might be in the string you quoted - TCU ID could be A80VF40Bxx
2. There will be a few XREF functions that refer to the TCU_ID
3. One of the functions will copy the TCU_ID into RAM
4. That RAM address will have an XREF that is just a pointer near the top of a long list of other pointers
5. The top of this list is SSM_base

Later on last night I confirmed that the SSM value gets corrected with a -5 before being stored. So it seems my TCU internally is using -55, CAN uses -40 and SSM uses -50. Strange stuff

I'm having trouble locating the SSM table, will have another try today. I found the RAM addresses that pre scaled SSM values that are ready to send are stored, but they are in no particular order in RAM and there are 0 read or pointer Xrefs to them, so I'm still missing something.

Do you know much about how checksums work on the M32r units?

I did work it out a couple of years ago. It can change depending on which TCU. It might be incorporated into the FastECU code - check FastECU to see if your TCU comes up with the checksum option.

This is how the Checksum for Hitachi TCU CAN seemed to work....
- all checksums are simple 32 bit summations
- checksum 1: During ROM load, the kernel checks that address range 0x8020 to 0x7ffff sums to 0x5aa5a55a. So address 0x8020 needs to be set to the 32 bit balancing amount to ensure it sums to 0x5aa5a55a
- checksum 2: The entire ROM from 0x0 to 0x7ffff needs to sum to the 32bit CheckSumValue stored at both 0x8000 and 0x8004. This makes it a 'circular' checksum. CheckSumValue can be calculated by first adding up ROMSum = sum of ROM from 0x0 to 0x7ffff excluding 0x8000 and 0x8004. Break ROMSum into its 4 byte values (ie) ROMSum3 | ROMSum2 | ROMSum1 | ROMSum0. Then CheckSumValue = (0xff - ROMSum3) | (0xff - ROMSum2) | (0xff - ROMSum1) | (0x100 - ROMSum0)

Ah ok, yeah from what I can see fast ECU is reporting my TCU can be checksummed, so that's good, but its always nice to know how it works. I am well in to more general disassembly now so I suppose I'll report back once I have a definition and my transmission is no longer racing for 5th gear as soon as the car drives off