RomRaider

The open-source nisprog/npkern utility has been enhanced to allow reading / flashing of the ECU EEPROM via the OBD port. This means there is no need to pull the ECU and desolder the EEPROM or use chip-clamps and EEPROM readers/writers. Full credit to fenugrec as the original author of nisprog/npkern. Please consider supporting myself and/or feugrec.

After a ridiculous amount of time reverse engineering the ECU code, the basics are:
- the ECU reads and writes to the ECU EEPROM as part of its normal operation
- the connections are hardwired on the PCB from the ECU serial (SCI) port pins to the relevant pins on the EEPROM
- A kernel running from RAM can activate the same ECU pins and send read / write commands to the EEPROM

Why would you use this?
- If you want to replace a faulty ECU and have it work with the immobiliser
- If you want to be able to swap in / out different ECUs and have them all work with the immobiliser

Limitations
- I've looked at a few different ECU ROMs. Some ECUs use SCI4 and the associated pins. Other ECUs use SCI3 and the associated pins. The right kernel needs to be used for the ECU serial configuration. There may be other serial configurations out there.
- All the ECUs I looked at used L56R EEPROMs, so all the EEPROM commands are the same. But, there might be other EEPROM types out there which need different commands.
- This is experimental software. As usual, you do this at your own risk. I have successfully read / flashed a 7058 ECU with an L56R EEPROM connected via SCI4.

Brief User Guide:
- read up on nisprog/npkern: https://www.romraider.com/forum/viewtopic.php?f=15&t=19677
- the EEPROM capability is in the ssm_test branch of these repos: https://github.com/rimwall/nisprog/tree/ssm_test and https://github.com/rimwall/npkern/tree/ssm_test
- EEPROM enhanced kernels are in the /precompiled folder with the names *_EEPSCI3 and *_EEPSCI4
- EEPROM enhanced nisprog will need to be compiled from the github repo for your platform (Windows/Unix etc). If there's interest, I can provide a Windows exe.

Brief Steps to use:
- run nisprog, use nisprog to load and run the kernel
- use command "dm eepdump.bin 0 0x100 subeep" to dump 256 bytes from EEPROM to file eepdump.bin
- use command "flsubeep neweep.bin 0 0x100" to flash 256 bytes from file neweep.bin to the EEPROM

Support
- You are mainly on your own. Help may be available on these forums.

Very interested to do this on my SH7055 SCI4 ECU with a L56R, what kernel / adjustments for SH7055 should I make (or compile on windows?), as I noticed there is only 7058 kernels relating to the EEPROM enhanced kernels in the precompiled folder? Cheers!

Great! The steps would be:
1. determine whether you have a 180nm or 350nm version of the SH7055, and whether security access is via 'normal' approach or '02 fxt' approach (or use trial and error in step 2 to work it out)
2. do a test dump of your ROM with normal nisprog + VAG-COM cable to make sure everything is working ok
3. compile an 'enhanced nisprog' version from the ssm_test branch of my repo
4. compile the correct version of a SH7055 EEPROM enhanced kernel (180 -vs- 350nm, 02fxt access or normal, EEPROM SCI3 or 4)
5. do a test EEPROM read
6. do an EEPROM write

Compiling can be tricky so let me know if you need help with items 3 and 4 once you have done items 1 and 2.

I got myself a VAG-COM cable as the Tactrix wasn't working and got to work, connected to ecu through nisprog with no issues and this is where I'm at.
The test dump that worked for me was the ssmk_SH7055_18.bin so I believe that my ROM is:
- 180nm
- normal approach
- SCI4 from you told me earlier
From this knowledge I'll get to work on steps 3 on compiling the enhanced nisprog version.
My question is step 4: How do I adapt / compile a SH7055 EEPROM enhanced 180nm, normal, SCI4 kernel? In the npkern ssm_test github the EEPROM related kernels are only SH7058.

Good stuff.

When compiling, use the ssm_test branches of my repo (both nisprog & npkern) and you should get:
- an enhanced nisprog (which will recognise the EEPROM read / write commands), and
- a series of kernels (SH7058 and SH7055_18 and others) that are enhanced using EEPROM comms over SCI4 (which is what you need) to execute the EEPROM read / write commands

You shouldn't need to edit any code because the ssm_test branch is already set up for SCI4.

Of course, make sure the EEPROM reading is working before attempting to write.

Alright I have the updated EEPROM enhanced nisprog up and running, can I just use the 7055_18.bin kernel in the precompiled folder or do I need to compile a different kernel (if so how do I go about that?) Tried to read using the precompiled 7055_18.bin and it just gave me corrupted repeating looking file.

I don't think it's relevant for EEPROM read/write, but I believe you need 350nm kernel if you want to write ECU because we haven't yet seen that Subaru uses 180nm kernel on it's SH7055 ECUs.

Test write will dump error with wrong kernel, read will work with both.

You need a kernel that will recognise the EEPROM read / write commands from the enhanced nisprog.

Here is a SH7055_18_EEPSCI4 kernel. I don't have this ECU so I can't test it... hopefully it works. Try a read first.

Tried a EEPROM read with the SH7055_18_EPPSCI4 kernel you sent and it goes through fine but the eedump.bin file isn't the EEPROM data is just repeating data. Is it possible that as MiikaS said that it may be a 350nm ROM? I checked the datasheet for my visual code on the chip (64F7055F40) but could not find any info related to it. Below is a log of what I'm doing on nisprog incase I'm doing anything wrong.

That more recent dump has a very similar data pattern to the first dump. I am wondering if the compile of the enhanced version didn't work. Did you do a clean compile when compiling the enhanced nisprog?

Try the attached precompiled enhanced nisprog.

The 350nm vs 180nm shouldn't matter for EEPROM reading. It does matter for ROM reading / flashing. But, just in case, here is a 7055 350nm kernel with EEPROM functions.

It's been a few months since I did this, so I might be doing something wrong. Hard for me to check without a SH7055 bench setup. See how you go.... Try running the attached nisprog with the attached kernel, try doing a ROM dump, check the ROM file is a match, then try an EEPROM dump.

When I try and load any kernel using the version of nisprog you just included, I get the following:

Sorry, my bad, I still had BIU comms mode on. Fixed up nisprog attached.

I just did a test EEPROM dump on my SH7058 and it worked fine.

EDIT: looks like you tried the SH7055_18_* version. Use the SH7055_35_* version

Just tried your latest version of nisprog with both the 18 and 35 EEPISCI4 kernels and it's still not giving the proper data in the EEPROM dump, very odd. The EEPROM read for both the 18 and 35 are exactly the same. Also tried test dump on the ROM on both versions before I tried the EEPROM's and they went through fine.

Ummm, that looks like an EEPROM dump. You can see the ECU/BIU pairing code repeated 3 times and the pairing flag also repeated 3 times.

The VIN is blank, and there are no DTCs or Freeze Frame data recorded.

Does it make sense that the VIN has been wiped?

Oh right, was expecting to see a different format from all the posts I've seen, but this is good news! Not sure why the vin would be wiped that's weird, is it possible that's how AUDM delivered cars came? I have exact same new ecu (only swapping ecu's due to ecu o2 issues) and put it in and read the EEPROM and it gave me same format but different values obviously. Put old ECU in to check and car started up fine. I'll try writing old ECU EEPROM into the new ECU now and I'll let you know how it goes!