5EAT TCM JECS ROM Image

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Excellent, thanks for having a go! The good news is that the first part of CAN comms worked with your ECU. So that verifies FastECU, the cable and CAN comms. It looks like it couldn't upload the kernel. That might be because it couldn't find it in the kernels folder (is the file ssmk_CAN_SH7058.bin in c:\FastECU-Windows\kernels?). Or it might be because of some Windows permissions issue? But for our purposes it doesn't matter because the first couple of steps verified CAN comms with the ECU. No need to try this again (unless of course you want to use FastECU for other stuff).

Unfortunately, there was no response from the TCU to the CAN comms. Let me have a look at the various settings and I'll build some alternative versions of FastECU. You don't happen to have software to sniff the CAN bus with the Tactrix do you? That might help figure out the problem.

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Hi again, a couple of things to try. These use iso15765 instead of CAN protocol. One of them uses a different CAN ID. The commands are also simpler - typical OBD commands. No wait time for a response too. If you could please try these and post up or PM the results.

Updated files are all located here
- different protocols.cfg to go into ./config folder
- FastECU_1f21.exe to go into same folder as FastECU.exe. Can run it without changing the filename.
- FastECU_1f1f.exe to go into same folder as FastECU.exe. Can run it without changing the filename.

Thanks again.

AJ08H65EAT · **Joined:** Tue Jul 05, 2016 7:14 am **Posts:** 17

Apologies for slow response. It would help if I went to the last page of the post to check for a reply...
Repeated the 1st step from last time and was successful with full ECU (engine) read, I think this was just a settings issue. So yes, adapter and CAN look to be working OK. Repeated TCU CAN read and same result as last time.

Tried both new .exe files and I don't think it did much. I was not able to copy from the log window this time - is there a trick to that? Pic of log window for each attempt attached.
Happy to try any next steps. Might be able to figure a way to read CAN during process if that helps.
Thanks, AJ

MiikaS · **Joined:** Tue Jun 06, 2017 2:11 pm **Posts:** 206

rimwall wrote:

Hi again, a couple of things to try. These use iso15765 instead of CAN protocol. One of them uses a different CAN ID. The commands are also simpler - typical OBD commands. No wait time for a response too. If you could please try these and post up or PM the results.

Updated files are all located here
- different protocols.cfg to go into ./config folder
- FastECU_1f21.exe to go into same folder as FastECU.exe. Can run it without changing the filename.
- FastECU_1f1f.exe to go into same folder as FastECU.exe. Can run it without changing the filename.

Thanks again.

Just for check, did you use 11-bit identifier with iso15765? CAN (extended) uses 29-bit, iso15765 uses 11-bit.

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Thanks for giving it a go. Hmmm, still no response from the TCU.

Hi MiikaS, I copied it from the *denso_sh7058_can* modules. Which uses this:

Code:

    // Set serial port
    serial->is_iso14230_connection = false;
    serial->is_can_connection = false;
    serial->is_iso15765_connection = true;
    serial->is_29_bit_id = false;
    serial->can_speed = "500000";
    serial->can_source_address = 0x1f1f;
    serial->can_destination_address = 0x1f29;
    // Open serial port
    serial->open_serial_port();

It would be great if you could have a quick look at the code in the repo - perhaps there is something I am doing incorrectly? See the extra class / module called tcu_subaru_hitachi* This is the 0x1f1f version.

In the meantime, I will think about some other things to try...

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Ok, two steps back to hopefully go one step forward. It is possible that your TCU doesn't have CAN or iso15765 comms implemented, but it should definitely have basic iso14230 comms implemented. So, next step is to try a simple iso14230 init command to the TCU. If this doesn't work, then I must be doing something wrong in the code.

Use the FastECU_bf.exe file from the ./precompiled folder here and the protocol.cfg file from the ./config folder here

Fingers crossed...

MiikaS · **Joined:** Tue Jun 06, 2017 2:11 pm **Posts:** 206

Just took a quick peek at it yesterday and it looked ok. But with CAN you could try to drop out data byte count from message or does it require it? Also, what does 0xAA do what is sent in iso15765 mode? Try to send same message in both modes, only drop trailing zeroes with iso15765.

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

The TCU uses iso15765 protocol, so the first byte is the message length. When I was using FastECU’s CAN protocol I have to put this byte in manually. I wasn’t doing it manually when using iso15765 protocol because I’m assuming the message length byte is constructed automatically when using iso15765 (because FastECU, when in iso15765 protocol, appears to work with ECUs).

0xAA is the iso15765 equivalent of 0xBF. It should report the capability bits.

In iso15765, are the trailing zeros sent? The echo to the log screen doesn’t show them being sent. But if they *are* being sent in the background it would cause problems. Although the TCU should still reply with ‘bad message’

I’m not sure why the log screen text can’t be copied, but this should be an easy fix once we get a reply from our shy TCU

MiikaS · **Joined:** Tue Jun 06, 2017 2:11 pm **Posts:** 206

rimwall wrote:

The TCU uses iso15765 protocol, so the first byte is the message length. When I was using FastECU’s CAN protocol I have to put this byte in manually. I wasn’t doing it manually when using iso15765 protocol because I’m assuming the message length byte is constructed automatically when using iso15765 (because FastECU, when in iso15765 protocol, appears to work with ECUs).

0xAA is the iso15765 equivalent of 0xBF. It should report the capability bits.

When iso15765 mode is used with tactrix (or any other mode), all necessary steps is done without any additional input from user, only ID and message needs to be sent to adapter.

rimwall wrote:

In iso15765, are the trailing zeros sent? The echo to the log screen doesn’t show them being sent. But if they *are* being sent in the background it would cause problems. Although the TCU should still reply with ‘bad message’

No trailing zeroes, message length is exactly what is added to it.

rimwall wrote:

I’m not sure why the log screen text can’t be copied, but this should be an easy fix once we get a reply from our shy TCU

If operation is succesful, log window is automatically closed so it could not be copied, but in failure, it will remain open to manually close so text could be copied from it.

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Hi, has anyone tried FastECU_bf.exe from a few posts earlier? It will help to know if it worked. Thanks.

SergArb · **Posted:** Sun Jun 25, 2023 7:53 am

I can test only on CVT ECU, Melco CVT MH8104/512KB.
If, someday, it will be needed

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Hi SergArb, all I'm trying to do at the moment is establish comms. The CVT might use the same CAN ID as a 5EAT TCU. You could try FastECU_1f1f, FastECU_1f21 or FastECU_bf and see if you get any response (after selecting "Unknown").

In the meantime, I've been steadily working through the logic that controls clutch engaging / disengaging. Very complicated!

AJ08H65EAT · **Joined:** Tue Jul 05, 2016 7:14 am **Posts:** 17

OK, apologies for slow response, I have tried the ISO14230 with the 5EAT - refer attached and let me know if that is good or bad.
Roughly from .jpg
Sent: 80 12 f0 01 bf 48
Response: 80 f0 18 39 ff a6 10 22 ad a0 21 60 00 01 00 80 04 00 00 00 00 a1 46 2c 00 08 00 00 00 00 00 00 00 dc 06 00 08 29 c0 04 7e 01 1e 00 3e 00 00 00 00 00 00 80 a6 e0 00 fe fe 00 00 20 00 da

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

Excellent! Definitely good news. Thanks for doing that.

Next step is security access and/or dumping the ROM using iso14230 commands. I’ll update the code shortly.

rimwall · **Joined:** Fri Aug 21, 2020 6:05 am **Posts:** 315

@AJ08H65EAT - really appreciate the help! Ok, let's keep rolling forward and try a ROM dump. Two files to try here

FastECU_a0_short.exe - attempts TCU init, then trials dumping the first 4096 bytes of the TCU ROM. If this results in bytes of any kind being received, save the byte data using 'Save calibration as'. If it worked, you can then try FastECU_a0_long. (If it didn't work don't bother with the next file because it's just a longer version of the first file)...

FastECU_a0_long.exe - attempts TCU init, then trials dumping of the whole TCU ROM. This may take a while. Just let it roll until finished. Once finished, save the byte data using 'Save calibration as'. And then zip and post up the ROM.

I have also adjusted the logic so you should be able to copy text from the log window. It results in a few 'ok' and 'cancel' button pushes but these won't cause any issues.

Once we have the full TCU ROM, I'll be able to dig into it and see if it is CAN enabled, or whether we should push on with K-line flashing.

RomRaider

5EAT TCM JECS ROM Image

Who is online