Nice, I started in Arduino, the Uno has limited RAM but worked fine.

Chipkit is nice if you want more power

Hi all,

I’ve managed to modify the MED9.1 assembly code to allow me to specify ram locations larger than one byte for logging.

(The below explanation makes a lot more sense if you read the last couple of pages of this thread first)

Earlier in this thread I described a problem that I encountered when specifying DDLI’s (DefineDynamicLocalIdentifier) for logging. If I specified a block of memory locations, only the last location could have a size larger than one byte. All the other memory locations had to be one byte in size otherwise the command would fail. I tried a few combinations of the command, but never found a way around it. I don’t know if it’s my ecu or a general MED9.1 issue. If I wanted to log a 16 bit variable (two bytes) I specified the memory location (size one byte) and then the next consecutive memory location (again size one byte) and put them together to get the full 16 bits. Also, if your variables lay close together in memory, you could read a chunk of memory and parse it for what you want. Hmmm.

However I thought it would be neater when defining the DDLI to simply specify a memory location and size thereof. This is similar to how ME7Logger works and I don’t see why it couldn’t work here.  You’ve got twenty locations in the first DDLI and I didn’t want to waste them.

The mechanism of ME7Logger is really well described at the start of this thread. I began by defining a few random DDLI and then dumping the contents of the RAM (since the DDLI’s should live in RAM like ME7). Dumping the RAM was surprisingly simple – exactly the same as reading the flash, use the same KWP commands you’d use to retrieve the flash, but just specify the start location to be 0x800000 instead of 0x000000. After that I had a snapshot of the RAM. Search through that for the random DDLI’s previously defined and you can see the locations where they are written to. Then disassemble with IDA and look at the cross references that refer to those RAM locations. That gave me an entry point into the code that handles the DDLI definition.

After many dead-ends and puzzlement, I reached a section in the assembler that I’m reasonably sure checks the size of the DDLI’s. Basically it compares the size to another variable. I simply replaced the CMP operation with a NOP. Now when I specify a block of memory locations in a DDLI, I can specify the size of each location (no longer restricted to one byte for the prior locations) and the command is accepted. Once the command is accepted, the ecu happily works with the size parameter and outputs the expected data.

Attached are the before and after bins so you can see the change I’m talking about if you are curious. It’s a very small change (replace CMP with NOP).

I’d love to hear from anyone logging on MED9.1 to see if you faced a similar issue and how you’ve worked with it.

I use VCDS as well. I have the genuine article and it’s helped me more times than I can count. I worked on the ram logging because a) it was interesting b) I was looking at variables that aren’t present in the measuring blocks that VCDS reads (like rl_w and the PID variables)  c) the sample rate was a bit faster.


Yes. If you are a pro and working on many vehicles, patching binaries is a bit impractical. I’ve got the one car which I tinker with day in and day out. I think you can choose how to log as circumstances allow and what is appropriate . Ram logging via DDLI works very nicely without any patches at all. The patch allows me to make the most of the DDLI’s in my scenario. ymmv.


Read and WriteMemoryByAddress doesn’t work on my MED9.1. I’ve tried all sorts of variations, diagnostic levels and security access. I even tried defining a DDLI and then using WriteDataByLocalIdentifier to indirectly write the memory. No joy. Attached is an extract from the FR showing what services are described. I’d loved to be proved wrong, but even in the Funktionsrahmen, WriteMemoryByAddress isn’t mentioned (having said that, #34 RequestDownload isn’t described either, but that definitely works!)

Thanks,

I've got some ideas I will post up soon :-)

I'd like to reignite this if interest just as a hobby.

Does anyone have experience with EDC17 logging over KWP2000?
ReadMemoryByAddress is not supported by this ECU, dynamicallyDefineLocalIdentifier (reading by memory address) should be supported (as FR says) but actually its not.

> 23 40 73 50 02 01 01
< 7F 23 11
> 2C F0 03 01 02 40 73 50
< 7F 2C 11

I had success with requestUpload/transferData but are there more efficient ways to read RAM?

Sounds like uds that?