NefMoto

*Disclaimer* Im an amateur.  I dont know a lot about coding or C++.  This code is not optimized, complete, or functional. 

Working File:
https://github.com/randumbintelrally/ME7_Logger_Arduino
the configuration is too complicated right now and I have tested this enough on enough ECUs to know it will work on anything but mine.  Will continue working on it and updating

Theres a lot of discussion on here of people wanting to implement ME7logger onto Arduino or RPi.  Prj says its easy and the information is out there and it can be put together pretty quickly.  The thing thats lacking everywhere is code to do it, examples, and specifics.

Ive been wading through this mess longer than I care to admit and trying to wrap my head around it and make working sketches.  I figure there are other people who want this.  And if i fail at it and do nothing more than give someone the database to build something off of, maybe I save them sometime.

Application Layer Protocol for KWP2000 ISO 14230-3
https://forum.arduino.cc/index.php?action=dlattach;topic=334778.0;attach=174852

Init Sequence:
https://www.blafusel.de/obd/vag_kw2000.html

Wiring Diagram for KKL leads.:
https://www.drive2.ru/b/2368649/
Im using the LM339N wired as the diagram shows, but only using pins 3, and 8-14.  Im connecting to the corresponding serial pins on a Teensy-LC, RX = 0, TX=1.

Right now I know the sequences with ME7Logger goes:
KWP2000 Fast Init Attempt
KWP2000 5 Baud Init (address 0x11)
Read System Supplier ECU Software Number
Start Diagnostic Session

At this moment, this sketch will:
KWP2000 5 Baud Init, Read System Supplier ECU Software Number, and start a Diagnostic Development Session

I understand that its not a lot, but its proof of concept.

What works for me is getting a communication log, and annotating that, like done here:
https://jazdw.net/tp20

Then make sure you either have some hardware on your desk to talk to, or write a simulator.
I've done the latter. It's extra work, but it makes sure I don't knock anything over and debugging is simpler than
with real hardware.

i cant get the tp2.0 working on the me7.  I have an ECU on the bench.  right now the conversation goes

In:   55 EF 8F      Init Response
Out: 70               Inverse Response
In:    EE              Inverse Address
Out:  02 1A 94 B0     Read ECU Identification For System Supplier Software Number
In:    0C 5A 94 31 30 33 37 33 36 33 33 35 34 FD Positive Response
Out:  03 10 86 63 FC  StartDiagnosticSession DevelopmentSession
In:    03 50 86 63 3C  Positive Response

and then im not sure if its in or out:
21 F0 C4 E0 58 56 F7 84 F6 F0 0E 25 F2

Is it possible that the development session changes the baud rate?  im not sure what the 0x63  is

The speed does change with staring the development session.  Ive put a new one up that implements the changed speed.  Were through the first part of what ME7logger does in getting access to the system.  After this there are 2 readMemoryBy Address commands.  I believe they relate to this:
Found bootrom version 05.12/05.32 via readmem

then we need to do this:
Read pointer ... done
Store handler ... done
Verify handler ... done
Redirect pointer ... done

but the format stops the KWP2000 format its used up to here.

So another update:

The format change was due to the limitations of the Length in the header.  Once the message exceeds a certain length, the header becomes 0x00 and the the following byte is the transmission length.

Ive gotten through the configuration message.  The ECU is rejecting the tester present message.  Im working on the ECU on the bench, and just logging a single transmission. 

Ive written the following sketch to parse out the commands, addresses, and constant data blocks.

https://github.com/randumbintelrally/KWP2000_Sniffer

The idea is to be able to spy on ME7Logger and be able to duplicate its inputs.

I feel like im a few days away from having a working example of this.  Hopefully my optimism isnt short lived.

ME7Logger uses a hack (stolen from APR)
It finds the DDLI buffer in RAM and then redirects the pointer to a different (empty) RAM area.
Then fills that with WriteMemoryByAddress.

Your ECU does not have TP2.0, that's for sure.
Most likely it's TP1.6. The init is 3 bytes. If it even has CAN diags.

It is described in SAE J3054.
I am not sure I want to post it here, because the forum might receive a DMCA notice. But you can find it in some torrent files. Or you can buy it.

But TP1.6 and TP2.0 are CAN transport protocols.
They have nothing to do with a K-Line connection, which is what you seem to be using. So WTF? :)
Your data link layer is described in 14230-2.

prj,
I was originally trying to work through the CAN-BUS lines using an MCP2515.  My concerns were primarily speed.  I had trouble sniffing the ftdi232 lines originally, but ive managed to get it working on a second attempt.  Ive just about got the program cobbled together.

I just got frustrated with everywhere finding people wanting to do this, but there not being any code of anyones project.

Ill be posting more up soon

   

Step 1 is to implement ISO14230-2.
Step 2 is to implement ISO14230-3.

You are trying to do both at once.

I hate to say this but a open source C or python version of ME7Logger (to talk to a FTDI/CHxx) would be of much more general use, and would get more exposure for your project, and may attract more help, and would be easily portable to arduino if you architect it properly. Some FTDI/CHxx drivers would have to be C, of course, for tricky timing. Windows/Linux/OSX portability would be ideal, though OSX might be tricky.

In fact, if you can cobble together the right docs (no, avoid CAN and TPxx as prj suggests, stick to straight kline for now), I will try to spend some time on it. I do not have access to any ISO or SAE (14230, J3054 respectively) docs, however, so somebody else has to do the research or throw money at ISO.

And yes, prj, do not post any SAE docs here, nobody needs the hassle. ISO is maybe a bit "safer" to leak, but not by much.

PM me, though, if you want to discuss alternatives, depending on how much you trust me.

I might also add some sort of open-source ME7Info tool would be extremely useful; there are one or two projects that might provide a good start.

https://github.com/commaai/panda (https://github.com/commaai/panda)
Open source implementations and hardware of 14230 and 15765.

I use J2534 myself, so never needed to implement these.
I have implemented TP2.0 recently though, since it's non-standard. It was really 1-2 evenings of work.

Doing a "ME7Logger" implementation using J2534 is ridiculously easy. But I don't see any point.
The big work is in doing a "ME7Info". Well, I did it differently and I can find almost every variable in the bin if I have a similar A2L.
But I am not going to be implementing a parser for C167, there is no money in it for me. I have PPC VLE and TriCore, and I'm doing PPC ISA now, it takes a lot of time to adapt disassembling libraries to be able to do automatic variable matching.

The matching algo itself is the same though, it's architecture-agnostic. The big deal is disassembling and parsing the disassembly to generate the metadata. I've sunk months into this at this point.

I dont have my head wrapped completely around everything and I havent tested this on a vehicle to make the correlations and work out the bugs.  But im getting mostly positive responses from an ECU on the bench and its doing everything ME7logger does, except the ECU responses are longer at the end.  Maybe I need the tester present message but ME7logger gets a negative response on that so I havent included it.

This is a long way from done and needs to be entirely rewritten

Step 1:  Load K_Line_Spy_Config.ino onto the Teensy
Step 2:  Use FTDI chip to LM339 chip to access ECU. Attach RX line from Teensy to RX line on FTDI chip
Step 3:  Run ME7Logger configured for your ECU with Serial Monitor Open.  Run to take single sample.
Step 4:  Serial monitor will produce the tables from ME7logger to configure the arrays in the config.h file
Step 5:  Load the Version_1.ino file onto the Teensy with the edited arrays in Config.h

You should get out the raw hex that ME7logger receives.  Not done.  But more improvement.  Im going to e able to start checking it for the 2.7t tomorrow and finding my references.  Then I can hopefully start polishing it up into something functional.

Im sure there are ways I could get more help or exposure, but right now I know what I know because of this site and the problems I have that Im trying to solve.

https://github.com/randumbintelrally/KWP2000_Access
https://github.com/randumbintelrally/KWP2000_Sniffer

And it works.  Theres a lot of refinement left to do on the configuration side, but at least it can start communication, configure the memory, and then read it accurately.  Im getting a pcb made up and will be able to start testing it shortly.

https://github.com/randumbintelrally/ME7_Logger_Arduino

This is awesome! 

I'll be using this for the FIS control because the current method is IMO very clunky.  This seems more refined!  Well done!

Nice!

I confess I dont know much about arduino dev, but .h files should not have code.

And this you should never due, you're wasting a shitton of power


have the decency to make that a sleep.

So the list of issues:

1.  I dont get the .h .cpp correlation yet.  That needs to be worked out properly.

2.  The arrays to configure the memory space are slightly different between the me7.5 and me7.1.1.  I need to collect more data to get this more automatic.

3.  The while loop at the end is just there to stop the program during test configuration on the bench after taking a single sample.

4.  Theres no function for saving this data.  The board I designed will write to an sd card.  Theres also the possibilty to switch to a esp32 microcontroller the send data via bluetooth or Wi-Fi.

5.  Theres no readByLocalIdentifier functions so this is far from universal.

6.  The data needs to be stored in a way that it can be loaded into ECUxPlot.

Im sure theres more, but thats a starting point.  Im expecting the PCB next week and I'll continue developing then

.h files have prototypes only. They're included both by cpp that implements the function and cpp that calls the function.

This is so multiple files can share the same code w/o having literally copies of the code in each.

If i have time i will refactor your code and submit a PR.. but a word of warning, it would likely end up being a complete rewrite.




i dont get this part. on an arduino, if you exit(), does the program just restart?

This is csv. You'll also want to parse .ecu files for variable names and scaling.

c++ is really a bad way of doing this sort of thing, better to do it in an interpreted language like python or perl, which is why it would be ideal if cpp was used to just implement primitives that could be called from interpreted languages.

Your (setup) runs once.  Use it for allocating values at the start or starting Serial etc.
Your (loop) runs all the time.  It'll run through each line in here, process it and then do it all again until power is lost.

Arduino's don't sleep.  ESP's do.

I'll have a play with this later but have no comms with an ESP or Mega with a Passat or VR6 ECU.

Just checking, but do you have them running through a lm339 or 393 with the voltage dividers and pull ups?

Serial1 is the one running the K-line, Serial is running the USB.

Nyet, please do whatever you want with this.  Ive never claimed to be any kind of authority on this.  I just wanted to put something out that could be the base of something better, because i hadnt seen this from anyone. 

Right now, once its connected and configured, it just prints the data to the serial monitor.  I need it to store a csv file to an sd card thats formatted just like the output file from me7logger for ECUxPlot.

My purpose is simple.  I cant have a laptop in the car while racing, but i can mount a headless module and collect the data and look at it after races. 

It also give me the option to write RAM variables for multimapping.  I can change pedal maps and load tables for things like wet vs dry running.  Have more data and more ways to optimize the system doesnt hurt. 

Plus ive modularized it to be able to collect 8 analog sensors, (oil and fuel pressure, front and rear brake pressure, etc) and be able to compile other realtime data from GPS, an imu, my TPMS system, and cameras.

It's the board I had for FISBlocks so is just piggy'd onto the back of the OBD board, the same as this:
https://github.com/ibanezgomez/FISBlocks

Will it work with FISBlocks if I do it your way?

Im using 2 sets of 10k resistors to create voltage dividers on the logic levels.  The 12v goes through a 10k, and then another 10k to ground.  Between you get the 6V.  Same for the 3.3V to get 1.65.  Not in this schematic, theres a 1k pullup resistor on the teensy LC RX Line(TLC_RX)

Got this built and responsive but gets stuck at init 2. Seems to be the wrong response. Anyone got further?

Okay, changed the def for the arrays from Char to Byte and got it working.  Gets stuck at Accessing Timing Parameters.  Seems to be getting stuck in the loop:
while (Serial1.available() < (messageLength + 1)) {
    Serial.println("in while...");
    if (Serial1.available() == 0x3F) {

On the scope the Arduino transmits the correct timing chars but the ECU doesn't respond...

I can't directly help you as I dont use arduino, but download the source for my r32logger and see the VB 6 code I wrote to connect and change timing parameters. Not sure if that version had quite the correct parameters, but they worked regardless. There are a few unfinushed loggers on here but  hopefully you can get this one to work as it should, at least as a challenge.

Minor change in the Start Development Session:
    txBuf[0] = 0x03;  //Message Length
    txBuf[1] = 0x10;  //StartDiagnosticSession
    txBuf[2] = 0x86;  //Development Session
    txBuf[3] = 0x14;  //?? *Was 63

Changed Byte 4 to be 14, not 63 and it works!

I'm not sure what's going on here, but the last byte is a checksum.
In KWP2000 it's a simple unsigned 8 bit sum of all the bytes except for the checksum byte.

But not only the sum is wrong.
The length does not include the header. so the length of this message is 2. Also the packet is not just length, in this case you have a single byte header, where only the lower 0x3F are length, the upper ones are address format specifiers.
And if you want to get a packet over 63 bytes you have to send this differently.

If you add 0x02, 0x10, 0x86 together you get 0x98.

And here is the whole thing using fastinit:

I mean okay, you are just cobbling something together, but I really recommend to read this here:
http://www.internetsomething.com/kwp/KWP2000%20ISO%2014230-2%20KLine%20.pdf (http://www.internetsomething.com/kwp/KWP2000%20ISO%2014230-2%20KLine%20.pdf)

as prj points out, this is an example of extremely poor coding practice potentially leading to more and more bugs.

The length and checksum should be added as part of a function that constructs a message, sets up a header, calculates checksum.

It's not a full extract of the code, the checksum is sent last (not in that above).

Might be a good idea to post full info then.
I guess you want to change the baud rate.

But I mean if you just want the standard 10400 speed, then you can omit it.

Sorry, would have been clearer for all.  Was just in the excitement!  I'll read that doc though, seems very good!  Thanks as per.

This works fine for ME7.5 but not for ME7.1 (MK4 VR6).  Not even sure where to begin tbh.

Because it's a braindead copy of ME7Logger's handler.
But ME7Logger's handler is bootrom specific. But of course only one ECU was sniffed and then the result copypasted.

If you want a proper solution, you can use my handler:
https://github.com/prj/me7log (https://github.com/prj/me7log)
But you will need to either disassemble every bootrom or you will need smart heuristics to detect variable locations just using the $23 service and fill the handler info (this is what I did).

If you don't care super much about CPU load just use APR's exploit, it's same for every ECU.
But yeah, you're gonna have to use some braincells and understand what you are doing, and not just ctrl+c ctrl+v a ME7Logger sniff lol.

One step ,or should I say command , at a time.
Work on keeping connection alive number 1, then see what commands are rejected.Do the ARP hack before you attempt he one prj mentions.
Took me many months, mind you I'm a brick layer not a programmer(, or is it coder these days)?

You are giving the author too much credit.
They have no idea what they are doing. They simply sniffed what ME7Logger was doing and then sent exact the same data to the ECU.

As I said before, this is bootrom specific. So if you want to replicate it on just one bootrom, you can do it like that, but otherwise you're gonna have to understand what is going on.

Okay so real progress, got ReadByMemoryAddress working absolutely fine.  Assuming it needs authentication (works with an ECU on the bench with immo off, not on), got it filling 8 vars (for the 8 lines on FIS).

Made up 5 'cards' with individual variables for each one.  Got it cycling through the cards and getting a response for each variable. 

The DDLI is a bit over my head but at this stage I don't need it for FIS, it's not fast enough and it's a gimick more than required to have 50 vars at any one time. 

PRJ is right, if you read the doc the process is easy(ish) to understand.

ME7.5 doesn't seem to require Security Access for ReadMemoryByAddress and will read fine.  ME7.1.1 does?  You can see it in the ME7Logger trace too: it tries for a diagnostic session and gets 7F so then attempts to get Security Access (0x27 0x01) and is successful, then it retries a diagnostic session and is successful.

Since I'm not needing to write, does Security Access Level 2/3 work?  So it'll be 0x27 0x03 which gives me a seed.  I add 0x00011170 to it? (is this right?) then pass it back as 0x27 0x04 xx xx xx xx CS.

This fails.  I'll take a trace and check to see I'm writing the correct key back but is the addition correct?  How do you determine it?  MK4 VR6.

The defunct minimal linux logger has the code for level x01.
You may need to decompile to get the algo for x03.

What is on github does not.

https://github.com/NefMoto/NefMotoOpenSource/blob/e084bbee922b935f73e23497c3ab336f657ae7c5/Communication/KWP2000Actions.cs (https://github.com/NefMoto/NefMotoOpenSource/blob/e084bbee922b935f73e23497c3ab336f657ae7c5/Communication/KWP2000Actions.cs)
Have fun.