RomRaider

No not really...

Here's how it is suppose to work...
Logger starts up and checks the definition file version (i.e.: <logger version="185"> ). If the version is not found or is too old you get a warning. There's two ways to fix this 1) add the version string to the logger.xml you are using or 2) copy the SD parameters info to the most current logger.xml and add the unique SD ROM ECU ID to the XML. How do I add it you ask? Find/replace the non-SD ECU ID with the SD ECU ID.

Now the Logger has a good def and does not complain about the version. All the SD parameters are there since you just added them. With that the Logger connects to the ECU and gets the init string. From within the init string the Logger parses out the ECU ID. With the ECU ID the Logger can now filter the logger.xml and present to you all the compatible parameters to log.

If you get a CAL ID: unknown then you don't have an ECU def defined in your Editor Definition Manager. In the RomRaider definition for your ROM your need these two things, 1) the ECU ID that you are using and the CAL ID that it cross references to.

In the sample I posted above you can adjust them as required for your SD ROM. Once you do this then point the Editor Def Manager at your new RomRaider def file (Note: EcuFlash def files will NOT work as they don't contain all the required info for RomRaider). The next time you start the Logger, if all cross references correctly then your should get an ECU & CAL ID in the Logger window. If not then go back and fix-up the defs as I describe above.

Once you get the ECU ID & CAL ID to show up correctly AND you are using a def version of 155 or higher (which contains DTC info for the DTC reader to work) then you should be able to use the Learning Table View feature in the Logger tools.

Give it a try and if you still can't make it work then post up the files you are using and a copy of the rr_system.log (with TRACE level detail) in a new thread so we can see what's going on under the hood.

I've confirmed that 0.5.7 has broken all of the SD defs. I'll see if I can get you a fix before the weekend. It's ridiculous for an end user to have to go through all this to fix a bug caused by lack of communication between the developers.

Interesting as I just described how RomRaider has worked from the very beginning. How have SD ROMs changed to not be compatible with it?
The addition of DTC reading is purely SSM so that should not change anything.
The addition of Learning Table Values only relies on ECU ID -> CAL ID -> RomRaider Editor def for the CAL ID. This hasn't changed either, only enhanced to support LTV.

Please show me where it's breaking down.

I looked this over and confirmed that the steps I outlined above will allow you to use all the functions of the latest version of RomRaider Logger. You just need to build your own RomRaider style ECU def as none is provided as part of the SD patch process.
Another anomaly I noticed is that the logger defs provided with the SD patches have <ecuparam> elements defined with missing <ecu id="##########"> elements. This violates the DTD check as at least one <ecu> element must be present. It will also through an exception when the def is parsed upon loading.

Here's a working set for a patched A2ZJB11J ROM so you can follow along.

Yep, ecuparams with no ecu element throw an exception that barfs the whole definition since https://github.com/RomRaider/RomRaider/ ... 6e4f578b75

Yes EcuAddressImpl.java was changed back in May to support non-contiguous SSM addresses for multi-byte parameters for TCU queries by adding an additional function. The functions check for a null address and throw an exception.

The simplest solution at the moment is to delete all <ecuparam > elements that have no defined <ecu> element from the logger def file as per the DTD.
Using the XML Tools plugin of Notepad++, it's easy to validate, locate and correct XML errors.

It's much simpler to add a well directed try catch to preserve the compatibility with files that work perfectly fine aside from adhering to a previously unenforced pedantic standard belonging to an atrocious xml schema that should be binned asap anyway.

Sure we can add additional error checking to handle malformed XML data. I'll add it to the list for the next update.