RomRaider

Update: Confirmed all supported SIDs for the ECU, TCM, and ABS Module. Just gonna have to work with Fenugrec to get the SRS working with Nisprog (I think it's just Nisprog throwing a fit about the ECU ID situation and just refusing to cooperate lol). But it's really cool to see how each module differs!

Hate to break it to everyone, but the ABS module doesn't seem to be programmable haha No security access, no RAM jump, no memory functions, no nothing. Hell, $AC can't even dump the ROM yet! (If at all)

Edit;
Well, that's disappointing. The ECU, TCM, and ABS module all have the same key bytes. And unfortunately, those key bytes don't allow for the extra length byte. Meaning, there's no way to utilize a length byte with OEM coding and we're stuck using a max data size of 63 bytes.

I suppose I’ll post this here so anyone whose interested can be updated.

Dschultz has been kind enough to allow me to implement extended ISO-14230 functionality into RR Logger! So in the future, all the useful things you see on the communication protocols wiki page will be usable within the logger! Now, I have very little experience with Java, so it’s not going to be something that’s fully implemented anytime soon haha But just wanted to make sure that anyone whose curious was aware that the logger is going to get a whole lot more NCS friendly!

Knew it, $A0 has so much crap in it, it's unreal. ~15 unique ARB ID's that all do something completely different. Also, confirmed $A0 05 is some kinda ECU reset. I mean, it was already technically confirmed, but the code shows WHY it causes an ECU reset. It does some stuff with SR then loop-branches to the same spot until a timeout occurs or something? because issuing it always causes a reset, so something with how the processor works is probably causing the reset.

But yea, $A0 is gonna take quite some time to analyze and figure out, there's just so much with all of it! For example, one of them actually appears to clear/write the entire RAM? Nothing useful for us, as it doesn't check any further ARB ID's to insert data with, just pasting and checking two constant longword values "AAAAAAAA" and "55555555", then putting the original value back. So based off that and the RAM parameter names, I think it's checking that the entirety of RAM can be safely rewritten and hold a value.

Getting an ABS ROM dump done atm. Used excel to calculate the ROM addresses for me since I have to use $A4 to dump it. Unfortunately, $A4 only is letting me dump from 0x400->0x17FF, so I can't get any bootloader stuff I guess. Weirdly enough, $AC for the ABS module doesn't seem to support ROM or RAM addresses, nor CIDs. So I think this is a case of formatting issues for CIDs, as it supports $22. But I don't see why they would include $AC if they weren't going to allow ROM/RAM addresses to be added

Update:
Oddly enough, I dumped the ROM a second time and quite a few values were changed Most of them stayed the same, but you'd have some random byte groups that would be different, alongside a few lines of bytes at the beginning Nothing should've caused it to change, so I'm not quite sure why so many bytes did.

What CPU does it use ? maybe those addresses are in RAM... some HCS12X cpus have weird memory maps

Honestly, I’m not really sure. I’m planning on ordering an ABS module next summer and disassembling that one to find out. That is, if I can’t figure out the processor from analyzing whatever data I can dump.

I was also thinking that maybe the address range isn’t the ROM. Because there were too many changed values in too many different blocks for it to have just safely reprogrammed itself for no reason. So I’ll definitely need to figure out the processor so that I can figure out the memory mapping. Because with the TCM, I have a dump of almost the entire thing! Strangely enough, $AC is able to dump every region of the MPC555 processor (reserved areas can’t be read). So I’m not exactly sure what’s handling the KWP2000 logic. I still need to analyze the data sheet further for sure.