RomRaider

So, I've got a couple of later ROMs where the alt2 checksum isn't working. I can't figure out why they don't add up. The routines appear identical to earlier ROMs with the alt2 checksum. I'm attaching 9DA0D for reference. Checksum code starts at 0x21270, but the main sbr I'm comparing is at 0x212b8.

<checksum type="alt2" start="0x8204" end="0xFFFFF" sumloc="0x9a18" xorloc="0x9a14"/>

I haven't look at those much, but my notes https://nissanecu.miraheze.org/wiki/Checksums#ck_alt2 indicate that there are 4 locations to skip when computing the alt2 checksum. I don't think RR supports that.
Just tried your 9DA0D and nisrom can't find the sums either, which is a bit strange.
In your sub_212b8 func, you can see it's skipping alt2 locations 9A14, 9A18 which you already figured out, but also 8200 (irrelevant since area starts at 8204) and 20000 (see that mov 2 + shll16).

I don't remember if and how I coded nisrom to skip those...

Yes, the "alt2" checksum implemented in RR skips 0x20000 by default. So all 4 locations to skip are accounted for. The routine looks the same as found in ZR35B, which calculates correctly as alt2.

I never knew ! Awesome.

nisrom manages to find alt2 on a bunch of ROMs, so I can't help but suspect a bad / corrupt dump ?

One thing I just noticed - you know that "NHU" signature near the end of the dump, usually it's at 0x80 [EDIT actually 0x7C; end-0x80 is somethign else, usually 01 FF FF FF ] bytes before the end, but yours has it at fffC0 for some reason ? could be nothing, but notice how the reset code @ 0x2620 checks for the signature at.... fff84 ! (end - 7C)

I think it wouldn't change the checksum value, but if that part is misplaced, maybe others are too ?

Yes, I'd noticed NHU position was "off" by 0x40. Perhaps there is something wrong with the end of the dump, it disassembled appropriately otherwise. 6GE2C is another I can't get correct checksum for. It has NHU in expected location.
6GE2C: <checksum type="alt2" start="0x8204" end="0x17FFFF" sumloc="0x9a2c" xorloc="0x9a24"/>

I checked one of my later dumps and it had the NHU data in the correct location. Turns out that was the issue. The xor chksum would not have calculated the same.

As for 6GE2C, the last 6 bytes were overwritten with partial ECUID. I reverted them back to FF and the chksums check out. So the checksum calc hasn't changed after all!

Excellent !
But, how did you make / obtain those dumps ? Those are weird problems to have, considering the rest of the dump is intact ...

I used a Macchina M2 (Arduino) for the 9DA0D dump. At one point I had tried to optimize the code for dumping large sections that could safely assumed to be 0xFF. It wasn't worth the time saved/possibility for error so I scrapped it...

LeftoverPi created the other file with a script from a text file he obtained from sniffing a CAN dump. Not sure how those bytes got in there...

I should mention that the latest version of NDS3 is also capable of dumping CAN ECUs.

SH7059. Why doesn't this work in RR v0.9.4???

Those appear correct, as confirmed by nisrom, for the dump you posted ( MD5sum 78d80b6e13deb337f9882adb19515d40 ). The earlier dump by a33b (md5 0e7c237393bf62bedd053f129bb22f1b) differs in a few places and as a result had a bad checksum.

No idea why it wouldn't work in RR.

RR code is programmed to skip the first 4 bytes, so just use 0x8200 as start.

I already did it.
<checksum type="alt2" start="0x8200" end="0x17FFFF" sumloc="0x9a2c" xorloc="0x9a24"/>
Does not work ...

There were 5/6 bogus bytes at the end of the ROM I had uploaded, the ROM you uploaded opens with 4 correct checksums for me.

Yes it works