RomRaider

[quote="rimwall"]@ajayel - thanks, looks like b8 locked down too. All a0/b8/b0 attempts have been via KLine so far. Let's try via CAN. Sorry for the shooting in the dark, but I haven't got a ROM file to look at, so we're in 'guesswork' territory. Please try FastECU_a0_a0_b8.exe in the repo and post up the log. This is just a spot test of a few addresses to see what happens.
No worries at all - please find the log attached containing first CAN and then K-line.

Okay, got things sorted, seams the software keeps loosing connection to the cable (I'm guessing an issue in windows)?
Anyway I hope this helps, let me know what else would be useful.

Thanks @ajayel, not much joy with those CAN commands. A few more to try - please try FastECU_b0_a8_b8.exe in the repo. Just CAN, no need to do KLine with these ones. If this fails we will try security access on KLine and see if that releases some constraints.

Hi, here's the log from FastECU_b0_a8_b8, seems the received bytes varied a little, maybe?

@Blake_Volpex - good news is that your TCU uses the currently known encryption words and dumping works. The bad news is that your connection seems to be inconsistent. It dropped out halfway through the dump. If you can get a reliable connection then flashing will be possible.

@ajayel - still no chink in the armour. Next thing to try is security access via KLine, let's see if that provides anything useful. Please try FastECU_Kline_27 in the repo.

Thanks!

I have had zero issues with EcuFlash using all the same equipment.
So this seams to be an incompatibility with FastECU and my specific setup.

How would you suggest I begin troubleshooting this?

Hi, please find log.txt attached thanks

@Blake_Volpex - you could try turning off background processes one at a time, or try running it from safe-mode, or try using a different laptop. Beyond that we would need help from MiikaS.

@ajayel - looks like K-Line access is pretty much deleted in your ROM. No response to anything except a couple of basic commands. Pretty much tried everything for access via normal comms. Trying boot mode might be the next option, however, that does require opening up the TCU box and accessing the PCB directly, so it typically means trying it on a spare TCU.

Does anyone on the forums know the access method and comms protocol for boot mode on these M32R processors?

@rimwall - looking at Blake_Volpex logs, it looks there is no visible response for request 27 01 nor TCU ID request, does it actually receive response for those? Or am I missing some logs or something?

@ajayel - answered to you on my forum, did you see it?

@MiikaS - the start of the log file is a CAN attempt. That doesn't work (as expected). On line 541 there is a KLine attempt. That works. The dump then works from line 550 to line 1047 after which nothing is received. It gets a bit jumbled after that, almost as if two KLine attempts are going at the same time. The second KLine attempt works for a while, then that also fails.

Good news for anyone following... access has now been achieved to the bootloader in @ajayel's TCU. Now need to prepare a kernel (no on-board kernel in this type of TCU).

Incidentally, this means access to some 4EAT TCUs will also be possible.

@rimwall This laptop has a pretty fresh install of windows and doesn't get used for much except tuning. But as I have the time this weekend I'll wipe it, re-install, and try again.

After a very stressful and tense day trying to recover an ECU, I unintentionally ended up accessing the TCU CAN module of my S Edition and wrote a ECU ROM onto it. I didn't know I was reading and writting to the TCU until I completely removed the ECU from the car and it was still reading and writting the ROM somewhere.

I bricked the TCU - completely lost gear indicators and other TCU related lights.

So I removed the TCU from the car, disassembled it only to figure out it was also a SH7058 processor, that's why the CAN might have accessed it instead of the ECU on the method I was trying to recover my ECU off a brick state.

I called up a few S Edition owners around here and one was willing to help me; Today we manage to read the working TCU and got access to the ROM file. So I managed to flash my TCU back to stock, and everything works as expected now.

I was speaking to rimwall during the process, and we might have more progress towards 5EAT CAN TCUs now. It wasn't my objective since I was just trying to recover my ECU, but now we made a little progress towards the TCU development.

As I was speaking to rimwall, the CAN TCUs have a very similar table structure to ECUs. It even has a CALID, everything. So all we have to do now is develop a correct and safe way to access the TCU over SSM, and make definitions for it, and it will be fully tuneable using RR or EcuFlash (editable via EcuFlash, but you would need to use other software to read/write).

That was a long and tough day.

Congratulations )

I'm glad that you can save tcu.

Good news! We have now successfully dumped a Denso TCU using the SSM approach. Credits... a big 'thank you' to all of the following:
- @ajayel for doing the testing of the SSM method
- @riksk for (accidentally!) doing the testing of the 'Denso recovery' method
- @MiikaS for FastECU and various coding improvements
- @fenugrec for the guts of the kernels which are derived from npkern

A status summary is:
- dumping of Hitachi 5EAT TCU achieved using on-board kernel
- dumping of Denso 5EAT TCU achieved using SSM method and an updated SH705x series kernel
- dumping and flashing of Denso 5EAT TCU achieved using Denso's 'recovery method' and a SH705x series kernel

The next step is to review the Denso TCU ROMs to locate key tables. As mentioned by @riksk, the Denso TCU ROMs use the same table format as their ECUs, so that will make editing with RR easy. The Hitachi TCU ROMs use a different table format as described earlier in this thread.

A side benefit of the recent breakthroughs is that the SH705x series kernels now also work for ECU dumping using the SSM method with FastECU.

Onward...