NefMoto

Windows based logger, similar to ME7Logger, which won't work with ST10 ecus, and is easier to use.
Features include pausing logs with space bar, automatic increment of last filename on start and robust connection.

Developed for the VR6 R32 golf MK5 / audi A3 3.2 with the ME7.1.1/ST10 processor but might work with other ST10 ECUs.

You will need RAM locations for your ECU. These are found in A2L files. Or the hard way using IDA. I included the ones for the 022906032CE in the package. Version 1.2 has a RAM dump , useful for getting some codes from the EEPROM mirror and anything else hiding in the RAM.

If the logger crashes the ecu immediately, you just need to manually find another RAM scan range as described below. I only had a 022906032CE and 022906032KG to test and the default memory area works with those. Some audi A3s and probably R32s,  just need a different RAM scan area and will work very well.

Uses K-Line dumb cable.


Written in VB6, tested on XP through to Win10 32&64

What to do if it crashes on first log:
For some ECU versions, logger will connect just fine, but crashes the ecu when it tries setting up for the log.
This occurs because each version of the ecu is different and the logger used an area of ram which was not free, although it looked like may have been.
What you need to do is to do a ram dump of the whole ram area, 380000 to 38fe00. This takes a few minutes if you clicked on the fast timing parameters first. Use the developer section of the logger in the settings menu for the ram dump feature.
Then you look in the dump file for ram areas that look empty (all zeros in a row) and write down a few addresses to try.
Then, delete the cfg file created by the logger file so that the logger will need to search ram areas again. In the advanced menu, change the 383400 for the ram search to what you believe is a good area, and try logging.
If still no good, repeat the process with another ram area. Be sure to power down the ecu for 2 minutes each time to clear RAM, or the pointer will not be found.I can't remember if just the ignition off is enough, but if the logger no longer finds the pointer it was still getting some standby power.
Eventually the logger will be happy and the new settings saved for the future.

Edit :27 Aug 2021
-----------------
Latest version 1.2+ (source code available) and 'developer' functions, including RAM dump, which allows you to view and save memory locations of the ST10 (Similar to VAG Commander, which doesn't work on ST10). Also works in countries where decimal places use "'," instead of ".".
 

Download  and install the 1.0 version first! 1.2 is just the updated exe file. No need to download the source code if you just want to log.

Source Code
--------------------
If you have VB6 you can edit the code and add your own functions change mine etc etc.
Source code has not been beautified. It is exactly as it developed as I experimented with the ECU.
It might be useful for someone who wants to write a specific logger in  for other KLine ME7s that have a KWP2000 protocol with a slight twist.  For example, only 'slow init 'is executed to connect to the ecu, but you could add 'fast init'  code if you needed it.

Very nice job, and going the extra mile too with a good frontend +1

Good job! Quick test shows it starting up after dll register (must be running CMD as admin,very important).

Look forward to testing this! +1

I tested this quickly on a R32 022906032CE ecu (same as op), my sw version is 6733.
No error messages on startup or anything, connects fine and starts logging, but logged values in file are all zeroes (engine running).

Created VIN.cfg file, contains [PointerAddress] 0F11CA and [VariablesNewMapAddress] 383400.

Same SW as mine.
Addresses are spot on and connection is stable.

I will test compatibility mode.
My Windows is 10 Pro 21H1 build 19043.1110

 I just  tried it out with my win7 64 bit tonight to see if I could replicate the problem, as I normally use W7 32 bit, but the only problem was when I ran it in the program files folder without running it as admin (although my account had admin privileges). It looked like it was logging but the log file did'nt save.
On the desktop it worked fine.

Try setting compatibility as XP SP2 , run as admin and see what happens.
Attached in post above are the test.ecu and log I just got with those settings. Try that and see what happens.
if no  good still, please attach the log file.



Now very important, don't delete the cfg file, because the ecu never clears the 38XXXX area (unless battery is disconnected physically for 3 minutes) and if the cfg file is missing the logger will look in areas that will stall the motor only when logging begins. 383400 is what it should find in all R32 mk5s.
 If you do delete it accidentally simply turn off ignition for  2 minutes. This clears the memory area where the pointer is.  Restart logger and it will find pointer and table, but the free memory will be now above 383400. Quit , go into the settings folder and manually change the cfg setting to 383400. restart logger and test at home while idling.

I've been using it for about 3 weeks and its always worked 100%, but I'm waiting for problems such as yours to come up before I release the source code.
If it still records zeroes, I will make a modified program to see what raw data its getting off the ecu for you to try out.

Btw i have 64bit Win10.
I tested XP SP2 and SP3, still all zeroes. Tried running as admin, with and without compatibility mode, same result.
Tried connecting only ignition on and also engine running, same result.

I haven't touched the cfg file since it was first generated, ecu file is the one supplied with sw.

Edit: I tested file in your rar, same result. Tried also Win7 mode.

Looking at your log, could this be a locale thing. Your timestamp uses . and mine ,

Very strange. The timestamp part has nothing to do with the ecu and is just a simple command:
Print #1, Format$(TimerEx - Start, "0.00")
TimerX and Start are just  real numbers. Regardless of the result, it should always have  2 decimal places when printed, yet on your computer is printed rounded up with no decimals!

Looks like all the printing of numbers isn't working, or the mathematical operations are integers instead of real numbers or both!

I will try out an up to date win 10 64 bit tomorrow on a bench ecu tomorrow and let you know.

Where's the source code?

Although I am not sure if anyone wants to look at VB anyway... but would not hurt to publish.

It is indeed locale handling problem in software.
I changed system decimal separator from "," to "." and now values display normally in log file.
This still happens A LOT with US made software when used elsewhere in the world, propably vice versa also.

When doing any kind of logging software like that you always need to force the system locale of the application to something, so that the behavior is uniform.
Otherwise logs written by someone in one country will be unreadable by someone in another, because the formats will be different.

Edit: Latest version now works.

Yes it works.
You changed field delimiter to semicolon, was that intentional?
It's totally fine by me, but then it differs from me7logger output.

Yes...
when I saved a file I made  in excel while the laptop was in Finland settings, the saved csv used semicolons to separate  numbers, and commas for decimals. I don't know what me7logger does to save a csv with commas for both as I cant use me7logger.
So the program now detects if the comma is used as decimal, temporarily changes the decimal to to '.' so the calculations work, and prints to the csv with the ";" as the separator but still uses '.' as the decimal separator, because excel seemed to not care whether a comma or dot is used when I loaded the file.
 When you press Q to quit, the system reverts to using ',' as the separator.

I'm guessing you don't want a proper csv for Excel  your country, but one that loads in EcuX. Is that the case?

I don't really care about Excel, i never ever use it  :D
For logging stuff I use MegaLogViewer, cause i like it. You can also change field delimiter in settings, if automatic detection fails.

Often there are functions just for handling separators for different things, for example converting from numbers to strings.

Umm , so the country setting is only important for the calculations, the final format of the csv still has commas as separators and decimals as in the US. That's an easy fix. More importantly, are the numbers making sense now? Any other  probs?

Everythings seems fine now, yes. Didn't spot any other problems, i did a small test drive with custom parameters.

I just posted an updated version (1.1C)  in the original post.
 

I tested this and it seems to work perfectly.

Thanks for the feedback!  ;D

Next version, which will be the final one, has a development  menu, for sending custom commands, RAM view/dump, development mode , security key. It is already in the logger but not visible.
That section should work on most ECUs with K-line not just ST10s. Source code as well...

There is no such thing as final.

True!

But unless there is a major bug in the next one, that it will be it for me. I actually spent many more weeks on it than I wanted to, just to make it usable by others. Being written in VB6 it might be final one from anyone,since in isn't compatible with the crappy NET version of VB that came afterwards and is still around.

And the newer ones propably generate 40 megs bigger executables aswell  :o

This is what github is open source is for; so it doesn't turn into yet another buggy bit of abandonware

I just uploaded the final version, 1.2, including source code.

It comes with a developer button which should work with me7 and probably more.
This allows viewing/dumping ram and all sorts of other stuff.

Source code is VB6 simply because last time I had to write a program was in the late 90's and I never needed to learn anything else.
I'm not a programmer, so don't shoot me it you don't like the code.

Actually they don't.
My Logger's installer (which is all .NET Core, and some C) is only 4 mb. And the only reason it is that big is because I have a statically linked RPC library in it, which takes up 80% of this size.

The only way to get ridiculously sized executables is by mindlessly bundling the whole runtime with the application instead of using what is installed on the system, or downloading and installing it during setup.

Forgot to mention that the source code is in text, Form1 is the one with the code. Being piss easy, BASIC, it's easy to see what it does.
What I'd like to look into next, is to see if the ecu can be made to read my own values, for example cam timing,from an empty ram location and use that instead of the map - without any reflashing. Any ideas?

I'm working on a simple tuning program that is based on the logger. Works on the bench so far but will try it on the car when I have time. So far it just helps with ignition timing. I'd like to do the cams, although it may not be quite as straight forward as there is no ram cell for both cams on the FR although there is one that McMess uses. I got to do more reading...

I tried out the logger on my R32  for 2 hours and it worked really well.
The pause feature is very handy.Top job.Never gave a problem.
It is way better than vcds for loggings.
Shame it is not done in python I dont know VB.

Thank you very much for sharing it.

When do you think the tuner version will be ready?

Glad it worked for you.
I don't like Linux so avoid anything related to it. Got scarred for life by it in the 90's - too many bugs, no help from geeks and never went back. There is a  version of a logger written in python on here you can try altering. Just look at my code, improve on it and pythonise it.
Otherwise just be happy that microsoft still supports simple VB6 applications 20 years down the track.

The tuner version I have not yet tried on on the car as I am fixing a coolant leak. I probably will not release it because it requires the ST10 embedded code to be changed and I don't think anyone will be interested.  ME7.1.1 removed  the vszw iginition timing cell from being added , only the fixed value ZWAPPL from the flash seems to be still added to the timing - well  from what I could determine in IDA as a noob that is.
 Certainly for the camshaft control there were never two RAM cells for both cams that was incorporated into the timing , so that needs to be coded into the MPC.  There was a vswnws variable from memory, but the code doesn't refer tho that either.

You can emulate the entire flash with Moates Roadrunner. So I think it's pretty much a waste of time doing any realtime stuff.
It's only ever needed on the dyno anyway.

Hey,

i got the following problem, and dont know how to format it, or is the adresse a wrong one?

lamsoni, makes no sense...

(https://i.imgur.com/HY42AzL.jpg)

anybody an idea?

Wrong address by the look of it as both banks aren't similar.
Use IDA to load the file I posted here http://nefariousmotorsports.com/forum/index.php?topic=20649.0title=

Find code that uses the variable whose address you want in my file, and use a hex editor find the same code  in hex format(mask off RAM/ROM addresses) in your mpc.  I haven't done it myself, but can't think of an easier way if you don't have an A2L.

I am working on an ECU ME7.5.30 with ST10 and I need to register it but I can't find the RAM addresses of the variables, I have the A2L file of this ECU, can someone help me with this?

Open the a2l with notepad and search for the variable. For example nmot, tans etc to locate the address. Most of these abbreviations are in the myecu.ecu file from Me7logger. The one with r32logger is same but shorter. Simply change the ram address only, keeping exactly the same format for the variables you need, get rid of the rest. But first of all, make sure the logger connects with the myecu.ecu file it came with, you will get garbage logs but you wont waste time.  If it connects but crashes when it logs you may be lucky, if it cant connect at all you are screwed. Never tried it with anything but 7.1.1 VR6, thats what it was made for.

Thank you very much, I will try it and report here the result

Btw, there's a way to switch the baudrate.
There's a set baud function in the bootrom, all you need to do is call it and boom you're at the baud rate.
It gives 0 shits about what session you are in etc. I did it in the Porsche handler, since otherwise it's not possible without patching something in the full flash.
But Porsche is somewhat simple in that they all use the same bootrom as 551K RS4.

Of course you can't use the $2C array writing method then, you need to inject a handler.

I've since made a v2 of this logger using the custom handler info you gave. V2 is much cleaner but uses the standard method of baud change, as I didnt know of this handier system.
In V2 If the number of variables isn't too high it can achieve 50hz readings. I haven't shared it because I got slack and made it just for my ECU version and dot for decimal place.
The lack of setzi's scanner for finding RAM addresses is the Achilles heal for users without an A2L. I tried making one but finding all those patterns just got the better of me after a while.

Well, that's where my tool comes in...
It can find the vast majority of the addresses in any file for which a similar a2l exists.

The trouble with the handler method is that in the later ST10 files there are a bunch of different mpc flashes, so everything moves around.
Writing the detection to detect the location of everything (as the injected handler needs to know a lot of stuff) is a non-trivial task.
It's easy when you're working with just one ECU, but very difficult when you need to support everything.

I'd say the $2C method is much more portable in that regard. However $2C was completely bugged on many of the earlier C167 ECU's and it does not support RAM on Porsche, so there the handler makes much more sense.