ST10VAR for ME7.1.1 with ST10F275 processor
------------
The goal of ST10VAR is to find variables and their address by providing a readout of the processor content and/or the flash file

ST10VAR uses pre-defined patterns/signatures and evaluates the matches through basic statistics to determine the most plausible location for X variable. It is not as quick or efficient as ME7Info, although I do plan to optimize the way the application analyze the file to optimize the selection of possible signatures (Ex. Projekt and Programmstand detection). I will also be adding more signatures to cover more ECU if there is interest


How can this be useful?
------------
Retrieving variables (measurements) data can be used for advanced logging through R32Logger or to speed up code implementation (I still recommend doing proper disassembly and double-checking results, especially for critical application)

R32Logger link : http://nefariousmotorsports.com/forum/index.php?topic=19670.0


How to read the ECU
------------
Thanks to R32Dude for R32Logger, he has also shared ST10Ripper which allows reading both the processor and flash file by OBD2 (K-Line connection is required, pin 43)

ST10Ripper link: http://nefariousmotorsports.com/forum/index.php?topic=21785.0


How to use ST10VAR
------------
- Execute ST10VAR.exe

- Select either a processor or flash readout, ST10VAR will ask if you wish to load an additional file

- A list of found variables with their occurrences and a "certainty" ratio is output to the console. As well as the signature files that has been used to determine the address of the variable. (Prone to interpretation, ex. 1 occurrence and 100% certainty doesn't mean 100% trustable)

- At the end of the execution, ST10VAR will ask if you wish to save the variables (measurements). This will output an .ecu. You can pick the variables you wish to log through R32Logger

I recommend loading both the processor and flash as they work in pair and this will improve the detection


Limitations
------------
It doesn't detect bitwise variables such as boolean, ex: B_brems. Detection accuracy could be improved

If you require 99% precision, I would suggest to look into commercial solutions such as VehiCAL

VehiCAL link: https://www.vehical.net/products/logger/


If you encounter an issue or want more support, please feel free to leave a message with your software number. If you can provide a similar .a2l, it would also help to implement new patterns/signatures (Please attach a readout of your mpc and flash, as I might not have a .sgo that match your ECU)

This has been tested on 022906032LT and a few 07K906032 (BH, BK, S, T, R)


ST10VAR download link : https://mega.nz/folder/ZdVjkaoC#1s4SUQpR5aQLav81ewn4KQ

I have never really looked into the inner working of ME7Info, although I have done some research based on this suggestion. Feel free to let me know if I got it right or if I am overcomplicating things

To parse the variables directly from the signal table (that would be the RAM table in %TKMWL if I understand correctly), I find the function that is responsible for creating that table by looking up for the code snippet that contains TKMWLNA, TKMWLNW, TKMWLMW:



From this, I gather the function is at 82AADE, and I can lookup for every call to that function in order. Then based on F0B9C, F0B9D, F0B9E and when 82AADE is called, I can determine what variable that is and its address

0: empty (first call to 82AADE)
1: nmot (second call)
2: rl (third call)
etc.

Example of second call to determine nmot


To be honest, I think this might be it, but I tend to overcomplicate thing and I feel you have a simpler / better approach up your sleeve. Fun part about that approach is that everything is on the flash, mpc readout wouldn't be needed anymore



This is what I would do if I were to entertain commercial ventures for multiples ECU, but as you said, this requires a lot of work and I couldn't afford to spend that time on developing something like this. At this point, I am not looking to re-invent the wheel and it just makes more sense to support you. I am really appreciative of VehiCAL and I praise you for that, sincerely, impressive work prj!

I did it with manual signatures as it was something I could do over the weekend



For the moment, I load it into IDA and run a script that find and creates the signatures. Most of the time, it works well on C167/ST10 and I can get going. Not the same results on Tricore though. In all honesty, I am a bit lazy, I should definitely try out bindiff instead of doing everything manually

Great work Artemisia, this is the essential missing part of  R32Logger.
I gave up very early on as I found finding signatures way too much work ( I never knew of the 'signal table' prj mentioned).
I've improved the logger heaps BTW, it uses code prj released that is similar to one used in the me7logger for very fast acquisition of variables, can log over 200 variables at once and can operate at 100 readings per second (depending on the number of variables) .The caveat is that I slacked off this time and didn't make it universal, it just works on the CE version, which is what is in my car. I haven't shared it as its too specific and Vehical can now do ST10 anyway.
Very grateful for all the info shared on this forum, especially by prj and other knowledgeable people.

I am mainly making this to makes R32Logger a reliable solution for enthusiast and for porting code quicker from one firmware to another. I also didn't think of using it prior to yesterday. I was aware of such table in MED17 as I have been using it for conversion factor on a CAN project I was working on, but I never thought on using it to find variables

Once I get more time, I will redo everything and make a table parser instead. It will be more efficient, and it will provide more variables as prj mentioned. For the moment, it gives most common variables that would likely be logged on most setups that run ME7.1.1

For your new version of R32Logger, are you using a custom service handler? I could look to create functions to dynamically creates it. I often use R32Logger for diagnostics, if I can somehow help to improve it, I would be happy to help

You are very welcome to improve the R32LOGGER as you wish!! VB6 is outdated and some of the methods I used back then can be improved immensely.
 I'm not a coder, I did play with Turbo Basic and Pascal in the 80s and when windows 3.1 took over VB3. I didn't know a thing about how ECUs in cars worked and didn't understand (still don't much of the time) what was being said on here but after many months of reading, much trial and error, one step at a time I miraculously  got it done and could finally log the car.  The 'breakthrough'  was in discovering how to write to RAM, since the usual service is blocked. Overall a massive job for me but Setzi could have done it overnight I bet!
In version 2 ,  I no longer use the flash RAM, but the a segment in the processor RAM, which is never used in the ECU code. It does use a  custom service, as detailed here:
 https://github.com/prj/me7log
But I skip a step or two, as I copy over my own modified service table and, in the process, made it specific for the CE version.  It connects at a much faster baud (89k from memory).  Its got a few other improvements but I'm beginning to forget. Version 1 is rough but after making v2, I find that v1 still did the job.
Not sure what the DID table is, haven't come across it before.

Ahh, yes, that's the method I used.