RomRaider

Good news and some not so good. Both .exe worked, except for a tiny flaw at the end.
a0_short ran for a short time and appeared to pull some bytes. Unfortunately I could not capture them as while the TCU Operation dialog window appeared as normal, selecting OK caused the application to crash which foiled any attempt to copy or save the data. So there is only another .jpg to provide a glimpse of what is there (attached).
a0_long worked also, pulled heaps of data, but also crashed in the end. Looks promising if we can get past that little glitch!

Super, thanks! The TCU is replying, but the reply is being truncated. "80 f0 18 fd" should be followed by e0 and 252 data bytes. The very last one seemed to receive the full response, so the next message might be being sent over the top of the reply.

I've updated FastECU_a0_long (same location in the repo) with some more delays between messages so see if that works. Hopefully the data bytes aren't all "ff" (which will mean we need security access first).

The crashes are probably caused by the truncated replies resulting in the data dump store having the incorrect length. I've changed the code to hopefully avoid that even if the reply is truncated.

No great news, appeared to be the same result as last time. The delay between messages felt longer. Another picture for you unfortunately, as it did crash again after hitting OK. I was not fast enough with Ctrl A, Ctrl C to capture anything useful as text. The glimpse of the first Recd data did look longer but all subsequent were 80 f0 18 fd as you can see in the pic. Sorry for more less than helpful data.

Thanks again. Not all bad. That final read shows some bytes I was expecting - 55 aa cc 33, so the read *is* working correctly. It's just that the code is not receiving the bytes correctly.

I now think the code was only receiving 4 bytes because the number 260 was getting transformed into 4 (260-256) due to the variable being an 8 bit unsigned integer. And that could be why the last data request (which is only ~100 bytes) worked.

Fingers crossed that is fixed in this version of FastECU_a0_long in the same repo location. I noticed a few blank received messages as well, so this version repeats each message up to 5 times if it receives a blank. Hopefully we'll also avoid crashes now.

I've also compiled another version FastECU_a0_long_2 which attempts the dump in shorter chunks. This may work if the one above doesn't work.

Making progress now - thank you for developing another version to test! a0_long did not appear to work any different to last attempt. still only 4 bytes recd. The first recd looked OK, but only the same 4 bytes after that. I did not run it to the end.
a0_long_2 did seem to be working - lots of bytes - plenty of ff at the beginning but may just have been those memory locations as after that it looked like useful data. Ran for a long time, about 20 minutes. Unfortunately it crashed again after pressing OK at the TCU operation was successful dialog window, so I was unable to get the file. Another jpg attached , but I did manage to get a tiny snippet of hex out of the window near the start of the read, also attached. Hopefully no more jpg next time!

Nice. Some thoughts:
- the truncation from 260 bytes to 4 bytes must be happening somewhere in the 'core' FastECU code, but I can't quickly locate where. So for now I'll stick with the workaround of only reading 96 bytes
- I wasn't getting the crashes because I didn't have any definitions folder, so the definitions were blank. But when I add the definitions folder, and FastECU loads in the definitions, I can replicate the crashes. So it's something to do with the 'core' FastECU. It seems to occur when the TCU ROM has been read into ecuCalDef->FullRomData and after returning to MainWindow FastECU tries to open a file via open_subaru_rom_file(), but the filename is blank so it crashes. Again, I can't quickly locate the problem, but I've made a workaround - the TCU ROM will be automatically saved to "default.bin". FastECU might still crash afterwards, but the file will have been saved beforehand.

@AJ08H65EAT - could you please have another go with the updated FastECU_a0_96.exe in the repo. Sorry about the bugs, but hopefully it's now fixed (with work arounds).
@MiikaS - maybe you can have a look for the bugs above. I'm sure you would have more success than I!

Thanks!

Yes, I can check those bugs out. Can you send me the TCU ROM to test with if I need to emulate download.

Thanks, there are commented out lines in the tcu module code in the repo that you can use to emulate a reply.

Can also send the ROM once we manage to successfully download it!

All worked exactly as predicted this time. It did still crash, but the default.bin file was saved. It is in attached zip. I will PM Pswd. Success!

I've been following this thread! This morning downloaded a 512Kb ROM from my RHD JDM 2008 3.0R 5EAT with FastECU_a0_96.exe via Tactrix OpenPort 2.0. Although it seems the file is all FF I've attached it here zipped. I had the TCU checkbox selected in Fast ECU with the new protocol selected for 5EAT, the process seemed to take around half an hour. btw Romraider logger shows my TCU with ID TCU0217500 with the transmission label of TG5D7CVDBA. Sorry I didn't grab the log window text this time but the exe did not crash for me.

This is awesome work guys. I'm lurking right now but can give it a shot if anyone needs my 2009 obxt 5eat rom.

Hi guys,

@ajayel - yes, it's all 0xff. Could you get FastECU working for other things? For example, see my post on page 5 that starts with "Onward. Here's a rough plan:" That will confirm it's not some other issue. Did you have the "Unknown" protocol selected in FastECU? I don't think the TCU tick does anything at the moment (@MiikaS will know for sure). These TCU ROMs do have a bit that will stop a ROM dump via the a0 command. Your TCU ROM may have this bit set. Once we get kernel access working this shouldn't stop flashing.

@lvkeith - help is always good, you can try a TCU ROM dump if you like. After that I need to figure out kernel access.

hi @rimwall. I was using the new protocol to connect to the TCU which picks up the TCU ID, I tried over again just now and was able to get a screenshot of the initial conversation;

Found some bugs that are causing crashing at different states of software, but not on every machine/compile versions. I will fix them and check and fix few other things also asap, but it may take some days to get them done as I have very limited time now.

Super, thanks @MiikaS. We'll keep going with workarounds in the interim.

A quick stocktake:
- CAN: first attempt failed
- K-line: basic SSM commands worked enabling ROM dump for some folk. The ROM for some folk is protected from dumping via SSM.

Updates:
- CAN: I went through the ROM code in detail and discovered I was doing some things wrong in the first attempt. New attempt below.
- K-line: kernel access via CAN looks easier so I'm going to see if the new CAN attempt works before working more on K-line

New CAN attempt:
- grab an updated version of protocols.cfg from here and save it to the FastECU ./config folder
- Try FastECU_07e1.exe from the repo here
- On first use, use the "Select" button. Under "Unknown" there will now be a CAN item and a K-Line item under "family". Select the CAN item and press Select. Then press the large green down arrow.

Copy/paste the log window of results. Note that the crashes may still occur for some people, so might need to do a screen capture.

Thanks!