RomRaider

mini update... working on the kernel and nisprog in parallel.

in this screenshot (see attachment):
First few lines is the code to match ECUID by similarity to find the most likely keyset to use (yay, no more typing two 32-bit hex keys !)

The last part is a test command "tfl" that compares CRC "checksums" over the whole ROM to determine which memory blocks were modified and need to be reflashed. As you can see in my test, blocks 1, 8 and 13 are different. The reason for this is mainly twofold :

- comparing CRCs takes about 6-7 seconds, instead of comparing a full dump which takes over 3 minutes for a 1MB ROM !!
- reflashing only the required blocks is a huge timesaver (from 8x to 256x faster !)
- bonus : leaving the other blocks alone can help with flash durability

The only drawback is that a CRC is not perfect. Currently I'm using one CRC16 per 256 byte chunks -- that is, 2 bytes of checksum for every 256B of data. It is very possible to find two different chunks that share a same CRC. (this is a well-known probability thing, "birthday problem")
I haven't done the math (someone please do, I'd like to see actual figure), but the takeaway is that it's very unlikely.
This is even more true since even the smallest flash blocks (4kB) are compared with 16 CRCs, and if there is a single different CRC the whole block is reflashed.

Still, I'll provide the reflash command with "orig_rom.bin" and "new_rom.bin" arguments so it can base its modified-block-selection on a file comparison instead. In other words :

1. provide desired new_ROM.bin file
2. select blocks to reflash, three options :
   
   1. full ROM, all blocks
   2. CRC comparison to select blocks, as described above.
   3. compare new_ROM.bin to a user-specified "old_ROM_contents.bin" to select blocks
3. erase + write selected blocks

Wow, this is awesome! Makes nisprog way more automated/user friendly and will save a lot of time! Thanks

Automated block modification checking? AWESOME!

I can honestly say this will help greatly with adoption by anyone without significant technical skills.

I can't wait to test this thing out!

Tested the kernel for reading my old Sh7055 tonight and got 5.5K/s ! It took all of 90 seconds to do a full dump.

Updated the kernels to fix a bug affecting some ECUIDs (at least 4M860) where the payload is transferred succesfully but did not respond to commands, requiring a power cycle to reset the ECU.

Source and precompiled bins available on my github as usual, http://github.com/fenugrec/npkern

.

maybe I have missed it , what command allows reading / writing of the eeprom ?

It's only documented inside nisprog if you do "help dump". It's almost the same syntax as a regular dump. But first you need to specify, for your ROM, the location of the eeprom_read() function. Some information about this on the wiki, https://nissanecu.miraheze.org/wiki/Eeprom_code

swami, I also got a patch for nisprog and npkern that allows read/write EEPROM, but only for more recent ECUs with ST95xxx EEPROMs.
I didn't submit it yet to the repo, but have promised to fenugrec to do it long time ago one day it will be there for sure

There is a lot of variants of EEPROM and EEPROM to SH705xF chip interconnections.
Thus software development is tricky and most probably the user should specify an applicable eeprom/cpu/connections.

the ecus i have are equipped with older 93c66 eeproms

Quite true. That's why I use the method of calling the ROM's own builtin eeprom_read() function, so I don't need to know which IO pins to use.

Swami - FYI, I use an FTDI breakout board and an SOIC clip to read/write my 93C66 eeproms. Much easier and more universal. Seems like Nissan uses them for a number of different things (instrument clusters, etc.)

For dumping ECU eeproms I use niskern/nisprog too.