RomRaider

Hey Colby. I've also developed the same thing in working for Cobb. I wish I would have done it 2 years ago as it is would have saved me a boat load of time! There are a few caveats with this type of system that I've found. If the tranny specific tables in the defs have only the ROM's native tranny tables defined (which is what I've done with OS and Cobb), the reference ROM would have to be the same tranny at the target ROM if you wanted 100% of the tables to be defined correctly. Another potential issue is that there are some routines (ex. primary ol fueling in later CAN ROMs) where the tables used are dependent on a couple of constants which can vary, so you would have to link the table prediction to the constants (or have someone manually go back and check the predicted defs). The other issue is that some of the ADC routines are identical for ECT/IAT/MAP, so these have to be checked manually (and they are not always in a consistent order in the ROM). Also, obviously, when you get into new model years, invariably, there are going to be changes/additions to the code that will need some human intervention even for existing table defs.

I was planning on doing a bug release of the RomRaider/Ecuflash defs as my final contribution to the OS community. Haven't had time to do this as I'm in the middle of building a house. But, hopefully, I can get that done in the future so you guys will have a good base to work off of.

I think I have most of the issues you mention addressed at the moment, but we will have to see. The code analysis is able to automatically solve some ambiguities with identical functions by doing further analysis as to what code is calling those functions, and in what order. Currently the system uses some initial techniques to find the nearest ROM relative with metadata and then uses that (which may lack the tranny defs as you mention if it has a different tranny). I can use multiple reference ROMs which will help solve this problem, but ultimately someone will have to decide what car it is transmission-wise (I'm hoping that users will provide this). I agree such a system will not be perfect in all cases, but the work reduction is amazing. I'm looking forward to running it on Mitsubishis as well as adding M32R, HC16, H8, C166, and TC1796 processors to cover the other cars I am working on.

merchgod,
U build the software, rom def & now u wanna build a HOUSE!!!! wonder what else u guys can build after this!! anyway all the best to u!!

I haven't formally posted about this, but I have invested a good amount of time building an automatic definition generator for SH2 Subarus (it should also work to a lesser degree for other SH2 makes). The system understands SH2 code and uses a variety of techniques to identify functionally equivalent code making memory references. By using similar ROMs with known good metadata, it is able to find 100% of the tables, DTCs, RAM parameters etc. I have been fine tuning it on the large body of ROMs / definitions already in existence to validate that it is always finding the addresses correctly. This program isn't going to identify new functionality / tables in future code versions - you still need a human for that - but it is exceedingly good at finding known things in new ROMs. Very soon I will be soliciting people for any ROMs that lack definitions so I can generate a definition for them. EcuFlash will also have an auto-upload feature so that new ROMs can be sent to us when they are found.

Colby

I haven't formally posted about this, but I have invested a good amount of time building an automatic definition generator for SH2 Subarus (it should also work to a lesser degree for other SH2 makes). The system understands SH2 code and uses a variety of techniques to identify functionally equivalent code making memory references. By using similar ROMs with known good metadata, it is able to find 100% of the tables, DTCs, RAM parameters etc. I have been fine tuning it on the large body of ROMs / definitions already in existence to validate that it is always finding the addresses correctly. This program isn't going to identify new functionality / tables in future code versions - you still need a human for that - but it is exceedingly good at finding known things in new ROMs. Very soon I will be soliciting people for any ROMs that lack definitions so I can generate a definition for them. EcuFlash will also have an auto-upload feature so that new ROMs can be sent to us when they are found.

Colby

Hey there! If someone it is necessary to Subaru ECU Definitions for EkoFlash, it is possible to order from us. But it is a complicated process that takes a lot of time and labor. This is have to pay. Contact will be done quickly and efficiently.

So you think it's ok to plaster posts advertising commercial definition generation on an open source community forum, where people have spent hundreds of hours of their time, for free, providing these definitions? Without even a vendor account? Impressive. A Yiddish word, chutzpah comes to mind.