These things have been done before by quite a few guys, but as far as I am aware, none shared until now.

I decided to try to a MED17.5 DataLogger using information and knowledge gained from NefMoto.
I just want to make clear that this is an ongoing project that does not yet work. I am not a programmer, this is only based on what I learned on the go here at Nefmoto and with some guidance aswel.
I am just sharing my progress so others might one day use it aswel if I get it to work.

First I went into the Keyword Protocol 2000 book that can be found here on NefMoto and looked for which services can be used to log data from an ECU.
By reading some NefMoto threads I found multiple ways which have been used to log by the guru's.

page14 in the KWP book (SSF 14230-3) gives a table with all the possible service identifier hex values, which I placed in brackets :

- read data by local identifier (21) ,
- read memory by address (23)
- Request upload (35)
-...

so first things first, we need to get communication between our ECU and our OBD tool. I did this on the bench, by reading the KWP and by checking how other tools did this. I found the following :

Tx 200 7 01 C0 00 10 00 03 01  / our tool (Tx) uses ID200, message of 7 bytes, asking the ECU to use CAN ID 300 (as seen in red)
Rx 201 7 00 D0 00 03 40 07 01  / reply from the ECU (Rx) acknowledging this with a 7 byte response asking the OBD tool to use CAN ID 740 (also red)

Ok we now have communication. Now we set packet & timing parameters. I just copied these.

Tx 740 6 A0 0F 8A FF 32 FF  /set parameters
Rx 300 6 A1 0F 8A FF 4A FF  /acknowledge parameters

in order to make service requests and log data, we need to open a session. Using the same table as before I found that there were a few options that allowed to use service 21 , but in order to use service 23 or 35, I needed to open either a Development session or a Programming session. The second would not be very useful as a datalogger for obvious reasons.

The request for a development session is made by sending the query 10 (start diagnostic session) followed by 86 (development session)


Tx 740 5 15 0 2 10 86  / we send a request, that is 2 bytes long, requesting to start (10) a development session (86)
Rx 300 1 B6 
Rx 300 6 1A 0 3 7F 10 33 / we get a 3bytes reply 7F Negative response (yellow) to 10 start the session (red) because of 33 Security Access denied.

Ok that is a bit of a pickle. But again, using some info found on Nefmoto, we work on passing the security access (service 27) in order to get into a development session.

Using a combination of seeds and positive responses to the seeds, we calculate the required key to unlock this service. On MED17.5 it turned out to be rather easy, just add 0x16248h to the seed and you will get a positive reply on level 03.

Tx 740 5 15 00 02 27 03  / 2bytes long request to access security level 03
Rx 300 1 B6 
Rx 300 8 2A 00 06 67 03 83 07 0F  /a positive reply adds 40h to the requested service (so 27+40=67, this is a positive reply) for level 03 and the SEED 83 07 0F 1F
Rx 300 2 1B 1F 
Tx 740 1 BC 
Tx 740 8 26 00 06 27 04 83 08 71  / our reply for service 27, on (03+1=04), adding SEED + Key as mentioned above.
Tx 740 2 17 67 
Rx 300 1 B8 
Rx 300 6 1C 00 03 67 04 34  / positive reply (27+40=67) on (03+1=04) , 34 means security access allowed.

ok so after passing the security, lets try to open a development session again.

Tx 740 5 18 00 02 10 86  / we send a request, that is 2 bytes long, requesting to start (10) a development session (86)
Rx 300 1 B9 
Rx 300 5 1D 00 02 50 86 / we get a reply that is 2 bytes long, positive reply 10+40=50 (red) and acknowledges a development session (86) (green)

Ok we are in the development session now. lets carry on, we want to log data so we first try with service 23, just read memory by address directly, that would be easy...

Tx 740 8 19 00 05 23 00 00 00 10  / we send a 5byte long request, as per KWP protocol for service 23, to set the pointer at address0x00 00 00 and read 0x10h bytes
Rx 300 1 BA 
Rx 300 6 1E 00 03 7F 23 11 / our reply is not what we hoped for. 3bytes long 7F NEGATIVE, service 23, because 11 Service not supported...

ok next, lets try using service 21, read data by local identifier. while we are still in the diagnostic session. We look up the KWP command to read a local identifier and I picked 02 just to try.

Tx 740 5 19 00 02 21 02  / we send a 2 byte command for session 21 , trying to read local identifier 02
Rx 300 1 BA 
Rx 300 8 2E 00 1A 61 02 01 C8 00  / we get a positive reply from the ECU (21+40=61) confirming local identifier 02 and the data
Rx 300 8 2F 21 85 75 16 FF 00 19 
Rx 300 8 20 FF FF 25 00 00 25 01 
Rx 300 8 11 78 25 02 79 25 00 00 

Great, this seems to work. Now we need to define our own DDLI in order to put the pointer towards the variables we want to log. Lets give it a try. Using the KWP book, we find that we need to use service 2C to make a DDLI table that points to our variables, then we just need service 21 (which we just proved works) to read our table and done ! or so I thought...

Tx 740 8 29 00 08 2C F0 03 01 FF  / here we send a request, as per KWP protocol for service 2C, put in DDLI F0, FF bytes from location 0x7FAB00
Tx 740 4 1A 7F AB 00   / not the most useful request on MED17, but good enough to test the response.
Rx 300 1 BB 
Rx 300 6 1E 00 03 7F 2C 11 / not the expected response sadly … again that dreaded 7F NEGATIVE, service 2C, 11 Service not supported …

dead end at least in development session (86) ...

ok, so lets move to our next option, lets upload the data via session 35 RequestUpload. looking it up in the KWP protocol, we find how to send the request for this :

Tx 740 8 29 00 08 35 04 00 00 00  / 8bytes request for service 35, read from 0x40000h using 00 no compression or encryption, read 40h bytes
Tx 740 4 1A 00 00 40 
Rx 300 1 BB 
Rx 300 5 1E 00 02 75 FF  / we get a 2 byte positive reply (35+40=75) with a maximum data length of FF (hex)
Tx 740 1 BF 
Tx 740 4 1B 00 01 36  / good news so lets send the 1 byte request to upload it (36)
Rx 300 1 BC 
Rx 300 8 2F 00 41 76 60 00 00 00  / 0x41h byte long positive response (36+40=76), which counts as the first byte and the requested 0x40h data
Rx 300 8 20 00 00 04 00 00 00 00 
Rx 300 8 21 00 FC FF 07 80 00 00 
Rx 300 8 22 00 00 00 00 00 00 00 
Rx 300 8 23 00 31 30 33 37 35 32 
Rx 300 8 24 30 38 32 35 AF AF AF 
Rx 300 8 25 AF AF AF AF AF 02 00 
Rx 300 8 26 00 00 17 61 E6 E6 60 
Rx 300 8 27 04 00 00 00 00 04 80 
Rx 300 5 18 FB FF 7 80 

So we just found we are able to read the data from the MED17.5 Ecu without encryption or compression at location 0x40000h (which is where our OBD read files start)


Hope you enjoyed the read. When I find time I'll keep on working to get some progress towards this next step.

Basically this is pretty generic to read data from any KWP compatible module.
The problem is often what addresses are allowed to read and what data is stored there.
Very often you want to read the flash (or important parts of flash) and the eeprom. These are often blocked ...

I don't have an MED17.5 ECU to play with but perhaps I could get a used cheap one from Ebay and help you guys out a bit...

Using the information here I could easily write the code in C which does this in a couple of hours...

Trev

I implemented this in my logger.

RequestUpload, TransferData etc is way too slow. You need to send 3 commands for every ram cell.
This means you get reasonable rate with like 6-7 ram addresses, after that it's too slow to be useful.

I patched the stack and implemented my own service, that gets reasonable speed.
Unfortunately without patching the speed is horrible on MED17 TP2.0. UDS supports $23 which is 1 command per ram cell so you can get around 20 variables before it starts to get really slow. Or again, it is possible to patch the stack to get more speed.

Then you need to find out how the 0xD0000000 is mapped.

Thanks but how can I read it too slow since there are only 3 bytes for address?)

My commercial tool logs MED17 both UDS and TP2.0, and has full RAM definitions for the majority of ECU's.
You are looking at a 100 EUR initial investment or 50 EUR if you have an active subscription... This gives you perpetual license for one car for full ram logging using a custom stack on both TP2.0 and UDS, so you get over ten times faster speed.
It also works with almost any J2534 device, so if you have e.g. PCMFlash already then you don't need to buy anything extra beyond just the license.

Considering the price point, and the amount of effort involved in making a workable tool (comms stack patching, A2L finding or ram cell finding etc), then I think unless you want to do this for a commercial reason, it is a giant waste of time. It took me years to get to this point.
Yes, what I provide is not free, but I don't think it ever will be, since the newer ECU's are so different and there are so many different types, that you can't easily make a ME7Info type of program to dump a (limited) set of variables directly from the bin. It's literally a full time job maintaining and expanding a such tool.
And if you need to sit in IDA and find them (because you do not have a matching A2L), then most likely it's easier to just pay 50 EUR and get to tuning, instead of wasting your time.

Sorry if it reads like an ad, but I literally made this whole thing because there did not exist any reasonable option, and besides my tool there still doesn't.
Link: https://docs.vehical.net/logger_getting_started

Yes, it is flushed in real time every row, and the file is not hard locked.
This was done specifically so that if someone wants to make some kind of UI, they can do that.
Sure, I attached. But it is possible to customize the header order and format in the options of the program.
Of course, immo is completely irrelevant.