NefMoto

Technical => Data Logging => Topic started by: setzi62 on November 05, 2010, 04:40:15 AM



Title: Logging with KWP-2000 protocol
Post by: setzi62 on November 05, 2010, 04:40:15 AM
I was wondering which method should be used for data logging using a KWP2000-protocol connection.
Can't have a look how VCDS (turbo-button) or ECUx are doing it, but maybe somebody knows more details?

Increasing the measurement rate by setting up higher communication speed is clear.
But which service is best used to read out measurement values?
You can read data using the service readDataByLocalIdentifier or read RAM contents
using readMemoryByAddress (if allowed by the ECU) or use whatever method to retrieve
memory contents.

I know that some ECUs support the readDataByLocalIdentifier with *localIdentifiers*,
which reports measurement groups in a similar form as done with KW1281. This would be relatively
easy to use but seems to be not working for most ECU's if I'm not wrong.
Most ECUs support dynamically defined identifiers by memoryAddress, allowing to read also
RAM cells, but this could be slow since it's reading only a limited number of bytes
per service.

Also could read RAM in blocks and then filter out the measurement values. This
could make sense, if a lot of measurement values are lying at adjacent addresses.
It's clear you need a mapping table to show which addresses hold the values you want
to measure, and this table will be specific for each ecu sw-version.
Here it is unclear to me how to generate such a table, where to start gathering
information about the addresses?

And finally, could it cause problems when reading without being somehow synchronized to
the engine control process?  I mean, is it possible to get wrong results when retrieving
values that are currently under update?


Title: Re: Logging with KWP-2000 protocol
Post by: spen on November 09, 2010, 01:51:14 PM
I'd go for read32BitAddress with the following absolute addresses.

(http://i272.photobucket.com/albums/jj172/spen0007/ramcells.jpg)



Title: Re: Logging with KWP-2000 protocol
Post by: iznogoud on November 09, 2010, 02:58:09 PM
The question about "race conditions" is an interesting one. I think there must be a 'trigger" somewhere in the algorithm.

Can you please state OS and hardware? Thanks.


Title: Re: Logging with KWP-2000 protocol
Post by: ArgDub on November 09, 2010, 10:13:29 PM
for speed, definitely readDataByLocalIdentifier with dynamicallyDefinedLocalIdentifier, using readDataByLocalIdentifier with 1byte header each request message is only 4 bytes long.


Title: Re: Logging with KWP-2000 protocol
Post by: spen on November 10, 2010, 01:48:28 AM

For speed, the can bus has to be the way to go?


Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 10, 2010, 03:03:25 AM
I'd go for read32BitAddress with the following absolute addresses.

(http://i272.photobucket.com/albums/jj172/spen0007/ramcells.jpg)


thanks a lot for the address table, that's a good starting point for me.
Will try to find some matches in other images for these variables.
I don't know a service with 32bit address on the ME7.x, so I guess you mean the
service readMemoryByAddress(sid=0x23)?

P.S. can't see the ramcells.jpg in your post here, seems to be filtered by the firewall.


Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 10, 2010, 03:07:44 AM
The question about "race conditions" is an interesting one. I think there must be a 'trigger" somewhere in the algorithm.

Can you please state OS and hardware? Thanks.
not shure about your question for OS and HW. In general I'm looking at ME7.x ECUs with
ERCOS on it. The logging application could run on any platform.
If "regular" mechanisms to read values are used like the official measurementGroup reading,
I believe the ECU will take care to eliminate race conditions.
But how is the situation when using inofficial mechanisms for reading engine process variables?
It could come out that this in fact is no problem, since the KWP2000 messages are handled
by the ecu in a task that's scheduled on a regular basis and thereby somehow synchronized
to the rest of the engine process. At least that's what I hope ...



Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 10, 2010, 03:11:43 AM
for speed, definitely readDataByLocalIdentifier with dynamicallyDefinedLocalIdentifier, using readDataByLocalIdentifier with 1byte header each request message is only 4 bytes long.
yes, this would allow the fastest reading of small ram portions.
But also processing timing in the ecu comes into place (messages handled only each 10ms)
so that the number of bytes in a request probably do not affect the number of messages
per second.
Then, only 10 dynDefLocalIdent's are available and I could associate only a single memory
location with each dynDefLocalIdent. That could limit the number of variables being logged
in parallel. But on the other side, can log up to 253 sequent bytes in one read and I could
use this service on any ecu tested so far. Many pro's and con's.


Title: Re: Logging with KWP-2000 protocol
Post by: spen on November 10, 2010, 03:53:10 AM
I don't know the service names which bosch use.  I know there is a routine to read an address though.

Just a crazy idea,  we could upload a function, and add it as a process ID for the ecu to complete and then end comms.  Our new function would then broadcast a set frame of preamble + addresss data we define (n addresses) + crc check when the k line is empty.    Then we switch our datalogger to 'sniff' mode and reap the frames?  Very low overhead, as long as we don't saturate the K line and / or drive the other controllers too hard with interrupts.

Still not as fast as the can bus though!


Title: Re: Logging with KWP-2000 protocol
Post by: Rick on November 10, 2010, 05:58:47 AM
Spen,

would the use of CAN not rule out certain ECU's?

Rick


Title: Re: Logging with KWP-2000 protocol
Post by: spen on November 10, 2010, 11:51:47 AM
I think even cars without esp still have canbus coming out of the ecu.  Have a look at your wiring diagram for the c ecu, it should be labelled can hi, can lo, or maybe Chi Clo.

CAN is better than KWP2000 for us (c and d ecu users).  Our cars won't take KWP2000 over the k line.  My ecu will talk KWP2000 on a bench :(  but not in the car.  I think you verified this with your hybrid ecu?

I dount our cars have CAN at the OBD socket.  Mine has the infotainment CANBUS but not the management can bus.  Infotainment bus!  It links the TV tuner to the RNS-D, nothing more!  My DIS is clk/data lines!





Title: Re: Logging with KWP-2000 protocol
Post by: Tony@NefMoto on November 10, 2010, 12:19:29 PM
My data logging software using ReadMemoryByAddress to do the data logging. ReadDataByLocalIdentifier and ReadDataByCommonIdentifier don't appear to work on the ME7. The message handlers are hooked up, but there are no local or common identifier defined, so you can't read anything besides the ECU identification data. You can use DynamicallyDefineLocalIdentifer by memory address, but it is not as fast as using ReadMemoryByAddress. Also, you are required to be in a Development diagnostic session to use ReadMemoryByAddress, while DynamicallyDeifineLocalIdentifier only requires a Standard diagnostic session.

Requests for ReadMemoryByAddress are fulfilled synchronously in one loop, so you don't need to worry about having half the memory being read from the previous ECU update or anything. But you do need to worry about how often and how much data you are requesting be read. My ECU crashed at 5000RPM while doing a data logging test on the street. Engine shut off and wheels locked up, then the engine restarted a second later, but I nearly lost control of the car when it happened. Turns out if you ask for too much data to be read when the engine is running at a high RPM, the watch dog timer goes off and resets the ECU. I now test data logging before driving by hitting the rev limit in the driveway, and I have also reduced how much data I read with each request.

The data logger I plan to release will require a user to supply a memory layout file specifying the location, data type, offset, and scale of the different variables to log. On the ME7 as far as I can tell, the only generic way to data log is with the slow KWP1281 protocol. With the KWP2000 protocol since common and local identifiers aren't defined, you have to do everything by memory addresses, which change with each ECU. I believe this is why APR ultimately discontinued work on ECUx.


Title: Re: Logging with KWP-2000 protocol
Post by: Rick on November 10, 2010, 02:10:55 PM
I think even cars without esp still have canbus coming out of the ecu.  Have a look at your wiring diagram for the c ecu, it should be labelled can hi, can lo, or maybe Chi Clo.

CAN is better than KWP2000 for us (c and d ecu users).  Our cars won't take KWP2000 over the k line.  My ecu will talk KWP2000 on a bench :(  but not in the car.  I think you verified this with your hybrid ecu?

I dount our cars have CAN at the OBD socket.  Mine has the infotainment CANBUS but not the management can bus.  Infotainment bus!  It links the TV tuner to the RNS-D, nothing more!  My DIS is clk/data lines!


Spen,
very interesting that you can't use KWP over  OBD.  Have you tried Tony's software in your car?  Do you know why it doesn't work in car?  I've not looked at the wiring diagram yet, but is it due to the other modules on the Kline not liking KWP2000?

If so, I will run a cable straight from the ECU plug to the OBD socket, and have an isolation switch which disconnects everything from the Kline apart from the ECU and OBD socket.  That should work as that's how it is on the bench.  Pain in the arse having to bench flash each time.

Rick


Title: Re: Logging with KWP-2000 protocol
Post by: ArgDub on November 10, 2010, 05:39:50 PM
DynamicallyDeifineLocalIdentifier allows to define a LocalIdentifier made of blocks of non consecutive memory. The document don't specify what is maximun length of a LocalIdentifier, but suppose that its 100 bytes, then you can define a LocalIdentifier of 100 consecutive bytes or a LocalIdentifier of 100 bytes at non consecutive addresses. I think this is more economic in terms of message length than read 250 bytes to use only a few


Title: Re: Logging with KWP-2000 protocol
Post by: Tony@NefMoto on November 10, 2010, 10:31:59 PM
There are 10 dynamically defined local identifiers.

Each dynamically defined local identifier can have a max of three entries from what I could determine from the assembly code. Each entry can be used to read a maximum of 255 bytes of memory it seems. But a KWP2000 message has a maximum of 253 data bytes after the service ID and local identifier in the response. So each local identifier read using a dynamically defined local identifier can essentially read a maximum of 253 bytes spread over three different memory ranges.

Read data by local identifier requests take the service ID and the local identifier as data for a total of two bytes of data in addition to the header. The response includes one byte local identifier and then the read data.

Reading memory by address, you can read a maximum of 254 bytes from one memory range.

Read memory by address requests takes a three byte memory address and a one byte memory size as data for a total of four bytes of data in addition to the message header. The response just includes the read data.

Ultimately if you have 30 different memory regions you want to read, then it may better to use dynamically defined local identifiers. If you want to read many many different memory regions, then you may be better off using read memory by address. This is because you have to reset and redine dynamic identifiers if you want to change them.

And like I said, ReadMemoryByAddress requires a Development session, and ReadDataByLocalIdentifier requires a Standard session.


Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 11, 2010, 05:56:34 AM
Just a crazy idea,  we could upload a function, and add it as a process ID for the ecu to complete and then end comms.  Our new function would then broadcast a set frame of preamble + addresss data we define (n addresses) + crc check when the k line is empty.   
Starting an own process/task on the ecu would be a hard job. Need to setup
a task table and code in ram and then find a way to start the task periodically.
Probably an alarm is free for this use. But conflicts with the running tasks that already
use the serial port could not be avoided.
What can be done is: you can load own code and table into the external ram and then
link it in by redirecting a pointer. So your code gets called whenever a message comes
in and works as an additional message handler for your own logging message.
The code can work on a table and collect all memory locations in one go.


Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 11, 2010, 06:03:55 AM
On the ecu's I inspected only one memory section could be defined for reading with dynDefLI's.
Or I am too stupid to define multiple sections? Shouldn't it be done like this:
2C F0 04                            - clear
2C F0 03 01 10 38 00 00     - define 1st section
2C F0 03 02 10 38 10 00     - define 2nd section
21 F0                                 - read
And on some ECU's the readMemoryByAddress is NOT supported, even after
securityAccess & turning on debugSession. Seems like the list of different communication
implementations on ME7 is endless ...
So a "general" data logger most probably needs to support different methods
for reading the memory.


Title: Re: Logging with KWP-2000 protocol
Post by: ArgDub on November 11, 2010, 11:17:11 AM
Tony, seems that developer of ecux found a way to bypass the three entries restriction. I've just checked that it can pull at least 67 values (8-16bit mix at non consecutive address) with a single readDataByLocalIdentifier. Also, noted it doesn't use DynamicallyDeifineLocalIdentifier, it defines LocalIdentifier writing directly to ram.

It's funny that whatever baud rate you choose, it never change timing nor baud rate, so reading 67 values it achives 12 samples per second at default 10400 bauds, and 14 sps if you read one value.

Guillermo


Title: Re: Logging with KWP-2000 protocol
Post by: ArgDub on November 11, 2010, 11:21:33 AM
Forgot to add it uses development session.


Title: Re: Logging with KWP-2000 protocol
Post by: Tony@NefMoto on November 11, 2010, 12:37:10 PM
Tony, seems that developer of ecux found a way to bypass the three entries restriction. I've just checked that it can pull at least 67 values (8-16bit mix at non consecutive address) with a single readDataByLocalIdentifier. Also, noted it doesn't use DynamicallyDeifineLocalIdentifier, it defines LocalIdentifier writing directly to ram.

It's funny that whatever baud rate you choose, it never change timing nor baud rate, so reading 67 values it achives 12 samples per second at default 10400 bauds, and 14 sps if you read one value.

Guillermo

Thanks for looking into that. The dynamically defined local identifier entries are stored in RAM, so it is possible you could use WriteMemoryByAddress and manually write them into RAM without using DynamicallyDefineLocalIdentifier. Writing the entires straight into RAM would allow you to bypass the three entry limit per local identifier. The three entry limit is only enfored when defining identifiers.

But this trick is even less portable across ECUs, because you need to find where the local identifier entries are stored and make sure to not to use RAM used by anything else. You could find the location of the local identifier entries by reading RAM, defining local identifiers, and reading RAM again. I am not sure how you can confirm how much RAM is free to use if you want to use more than the standard three entries per identifier. Also, by doing it this way you lose the ability to run in a Standard diagnostic session.

I am planning on releasing my data logger based on ReadMemoryByAddress before I work on trying any new techniques. But it's pretty cool to be hearing some new ideas on the subject. ;D


Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 12, 2010, 03:02:10 AM
Yeah, thanks for the information that you all gave in this thread, that was really what
I hoped to find. This presents again a good starting point for my own experiments  ;)

Guillermo, did you log the serial interface to find out what happens, and would you
share such a log?


Title: Re: Logging with KWP-2000 protocol
Post by: ArgDub on November 12, 2010, 10:16:38 PM
setzi, I would like to hear about those experiments ;D

Attached are two logs, first RPM and IAT were logged, in second 68 variables were logged. I wrote an explanatory note next to messages but there are many question marks for you guys.

Edit:
ECU 06A906032HS


Title: Re: Logging with KWP-2000 protocol
Post by: Tony@NefMoto on November 14, 2010, 01:16:35 PM
The first write of 8 bytes is manually defining a dynamically defined local identifier. The five writes of 61 bytes are all going to unused RAM regions. I believe this is manually writing the dynamically defined local identifier entries.


Title: Re: Logging with KWP-2000 protocol
Post by: setzi62 on November 15, 2010, 09:02:54 AM
It's like Tony said, the data table of the local identifier (describing ram address +
number of bytes for each variable to be read) is written into unused ram and
the data pointer in the local identifier table is redirected to the new data table.
For the 68 variables log the communication speed should have been 57600 baud.
I did some small updates in the excel file comments about this.

At all, the used logging method is a nice trick to get over some limits of the ecu functionality.

Just for curiosity: when playing with dynDefLI's, I saw two things:
- could use 3 memory regions per ddli only if the first two regions each just contain one byte.
- with a Cbox image for the definition of a ddli the memory address had to be
  given in swapped order (low byte first, the middle and finally last high byte), strange??


Title: Re: Logging with KWP-2000 protocol
Post by: prj on January 20, 2013, 05:51:51 AM
Using some specs and some data in this thread I implemented a data logger.

I wanted to try readByMemoryAddress, as that seems a bit more portable, and hoped to use it on a few other ECU's as well.
However, as I see it:
1. readMemoryByAddress only takes a single address and then a length in bytes, I can not give it an array of addresses.
2. The maximum update rate I got out of my ECU on my bench is about 17hz using this method.

So unless I am doing something wrong, it is my understanding that I have to read out whole big blocks of RAM.
If I read two different blocks I will get about 8-9 samples per second.
No idea if I ever get a reply to this, as it seems that most people who have understanding of these things have left this forum for greener pastures, but here is to trying...


Title: Re: Logging with KWP-2000 protocol
Post by: prj on January 20, 2013, 06:12:25 AM
I think I missed the accessTimingParameters service...
Will try it, and probably increase the sample rate :)


Title: Re: Logging with KWP-2000 protocol
Post by: prj on January 20, 2013, 11:18:05 AM
Yup, that allowed me to get 50hz...
So if I use the dynamic identifier hack I can get 50hz with arbitrary addresses, but this is ECU specific and we already have ME7Logger for that.
ReadMemoryByAddress should work on the diesel ECU's as well, so I need to get some of them and test.


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on January 20, 2013, 10:17:05 PM
No idea if I ever get a reply to this, as it seems that most people who have understanding of these things have left this forum for greener pastures, but here is to trying...

I am definitely interested. In particular, i'd also like to try to reproduce ME7L functionality (even if it isn't general!) so it can be built as some sort of portable library for use in other platforms, as well as being able to redirect the output somewhere useful (like a domain socket to a local process, or tcp socket to a remote host).

Do you have sample code anywhere in your repo?

I might try to rewrite it in C

i goddamn hate vb with a passion.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on January 21, 2013, 06:17:02 AM
Pretty sure ME7L is already written in C.
It's not hard to get the logging working, but for ME7 there is already ME7Logger and I am doing this mostly to get it to work on some Diesel ECU's, and maybe newer ECU's like MED9 and EDC16.
Not sure if they will work on K-Line or need a CAN interface though.


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on January 21, 2013, 02:49:17 PM
Pretty sure ME7L is already written in C.

I'm pretty sure setzi isn't going to give me the source code :(


Title: Re: Logging with KWP-2000 protocol
Post by: prj on January 21, 2013, 03:56:20 PM
This thread contains all the relevant data, and also there are KWP2000 specs posted on this forum as well.
It literally took me 2 days from knowing nothing about KWP2000 to getting a working logger.

Of course, nothing even closely as polished as ME7Logger, and of course it does not have the binary processor that ME7Logger has.
But it's not exactly rocket science.

That said, there is nothing you will accomplish functionality wise by making your own logger.
ME7Logger already uses the best possible method to log ME7, period.


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on January 21, 2013, 04:51:04 PM
ME7Logger already uses the best possible method to log ME7, period.

And its closed source, which means I can't extend it to do what I want it to do. Which means I am forced into making my own logger.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on January 21, 2013, 05:05:29 PM
Well, make one then.
The complicated part is detecting where the variables are in the bin, not making the logger itself.
And well, finding a bit of free RAM you can safely overwrite, and where the pointer the dynamic table is (unless it's always the same of course, which would make sense).

There is an XLS file in this very thread that shows exactly how ecuxplorer operates.
ME7Logger does _exactly_ the same thing, the only difference is, a higher baud rate is used and the AccessTimingParameters service is used to reduce the inter-byte and inter-message minimums to 0, and achieve the 50hz rate.

setzi62 took ecuxplorer's method and improved it, but the logger it is not original at all.
What is really good about ME7Logger is ME7Info - that is a much finer and more original piece of engineering, and this is what makes the package really good.


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on January 21, 2013, 05:25:51 PM
What is really good about ME7Logger is ME7Info - that is a much finer and more original piece of engineering, and this is what makes the package really good.

Agreed. Thankfully that part of it works just fine; there's really nothing i need to add to it.

Hopefully I can make a library in C that is crossplatform and extensible for logging.

I'm not sure its really possible to make it truly crossplatform, so ill initially just concentrate on cygwin/mingw and msvs

I really want to avoid using cmake etc.


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on March 28, 2014, 03:27:31 AM
Hi guys,

Been poking around a bit with logging MED9.1 over CANBUS.

The information in this thread is really good, especially the traces in the spreadsheets and I’ve had a go at replicating this on MED9.1 over CANBUS. Up to now I’ve been logging using VCDS but I wanted to see how the RAM logging works. prj, I see you looked at something similar here (http://nefariousmotorsports.com/forum/index.php?topic=3110.0title=). How did you get on? This might be a bit niche, even for this forum ;D, but if anyone has played with this I’d really like to hear from you! All the services and codes I mention below are described in the KWP2000 protocol.

1)   What service are you using to read the RAM? I tried #23 ReadMemoryByAddress but it was rejected. Instead I used #2C DynamicallyDefineLocalIdentifier and read this with #21 ReadDataByLocalIdentifier.

2)   If you are also using #2C DynamicallyDefineLocalIdentifier, have you seen that only the last entry can have a size > 1 byte?

Valid examples (accepted by ECU)
One memory address:
{0x00, 0x08, 0x2C, 0xF0, 0x03, 0x01, 0x0F, 0x80, 0x00, 0x00}
Two memory address:
{0x00, 0x0E, 0x2C, 0xF0, 0x03, 0x01, 0x01, 0x80, 0x00, 0x00, 0x03, 0x02, 0x0F, 0x80, 0x00, 0x10}
Three memory address:
{0x00, 0x14, 0x2C, 0xF0, 0x03, 0x01, 0x01, 0x80, 0x00, 0x00, 0x03, 0x02, 0x01, 0x80, 0x00, 0x10, 0x03, 0x03, 0x0F, 0x80, 0x00, 0x20}

Invalid examples (rejected by ECU)
Two memory address:
{0x00, 0x0E, 0x2C, 0xF0, 0x03, 0x01, 0x0F, 0x80, 0x00, 0x00, 0x03, 0x02, 0x0F, 0x80, 0x00, 0x10}
Three memory address:
{0x00, 0x14, 0x2C, 0xF0, 0x03, 0x01, 0x0F, 0x80, 0x00, 0x00, 0x03, 0x02, 0x0F, 0x80, 0x00, 0x10, 0x03, 0x03, 0x0F, 0x80, 0x00, 0x20}

3)   Do you have the RAM address and scaling of some common variables (RPM, requested boost, actual boost etc)? I’d like to see if I can actually read them, but I don’t have the skill to disassemble myself and find them ??? I’ve attached my bin if it helps.

4)   If there is a size limit of just one byte for all except the last entry in the DynamicallyDefineLocalIdentifier, how do you work around this for 16bit variables (two bytes)? Define two consecutive memory locations (one right after the other) and read one byte from each, effectively reading two byte?

5)   I was able to define at least 17 entries in a single DynamicallyDefineLocalIdentifier. I didn’t try any more than this, but it seemed at least it’s not restricted to just three like the thread suggest on ME7.1

6)   I also found the equivalent RAM tables where this resides in MED9.1 The addresses are 0x80 4334 and 0x80 38CC. For example, if I define a DDLI like this KWP2000 {0x00, 0x08, 0x2C, 0xF0, 0x03, 0x01, 0xAF, 0x80, 0x11, 0x22} it will populate the RAM tables like this:

RAM address - Contents
0080 4334 - 00 01 00 00 00 80 38 CC <- one entry in the DDLI, points to 0x80 38CC
0080 38CC - 00 AF 00 00 00 80 11 22 00 00 <- contains the size and address. In this case, size 0xAF starting at 0x80 1122

7)   I saw 10 DDLI’s in the RAM
0080 4334 - 00 01 00 00 00 80 38 CC
0080 433C - 00 00 00 00 00 80 39 6C
0080 4344 - 00 00 00 00 00 80 39 84
0080 434C - 00 00 00 00 00 80 39 9C
0080 4354 - 00 00 00 00 00 80 39 B4
0080 435C - 00 00 00 00 00 80 39 CC
0080 4364 - 00 00 00 00 00 80 39 E4
0080 436C - 00 00 00 00 00 80 39 FC
0080 4374 - 00 00 00 00 00 80 3A 14
0080 437C - 00 00 00 00 00 80 3A 2C

8)   I can see that ecuxplorer and setzi62’s ME7Logger write to the RAM tables directly #3D WriteMemoryByAddress but unfortunately when I try this on MED9.1 it is rejected. Has anyone been able to write to the RAM on MED9.1?

9)   Also attached is a log where I define the DDLI and then dump the RAM. This helped me to find the RAM tables that the DDLI lives in.

As always, thanks!


Title: Re: Logging with KWP-2000 protocol
Post by: Aurélien on March 28, 2014, 07:51:56 AM
1) 0x2C and 0x21, just like you.

2) I don't remember this. I remember doing a log with rl_w and nmot_w. I will check.

3) I don't have a definition matching your file so I made a quick search in ida :

0x7FD830 : nmot_w
0x802554 : ldtv_w
0x7FEE0B : zwist

4) If this is the case, yes.

5) It's restricted to 20.

6) Cool. :)

8) I never tried but with 6) you can probably try !


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on March 28, 2014, 09:42:44 AM

4)   If there is a size limit of just one byte for all except the last entry in the DynamicallyDefineLocalIdentifier, how do you work around this for 16bit variables (two bytes)? Define two consecutive memory locations (one right after the other) and read one byte from each, effectively reading two byte?


This seems like a bad idea, since you sample the two bytes before and after the value has changed.


Title: Re: Logging with KWP-2000 protocol
Post by: Aurélien on March 28, 2014, 10:15:45 AM
This seems like a bad idea, since you sample the two bytes before and after the value has changed.

I don't think so.
It would be the case if you do in 2 request.
But there we are talking about one single request that is asking lo byte and hi byte :)


Title: Re: Logging with KWP-2000 protocol
Post by: B234R on March 28, 2014, 11:20:46 AM
@Basono

At which security level (seed&key) did you try use service #23 ReadMemoryByAddress?


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on March 29, 2014, 05:11:07 AM
1) 0x2C and 0x21, just like you.

2) I don't remember this. I remember doing a log with rl_w and nmot_w. I will check.

3) I don't have a definition matching your file so I made a quick search in ida :

0x7FD830 : nmot_w
0x802554 : ldtv_w
0x7FEE0B : zwist

4) If this is the case, yes.

5) It's restricted to 20.

6) Cool. :)

8) I never tried but with 6) you can probably try !


Auré, thank you!

If anyone can confirm the single byte size limit it would be nice to know. Maybe I've got it wrong?

Reading two consecutive bit's of memory was just a suggested workaround. I'd prefer not to do it, much better just to be able to specify size and address.

@Basono

At which security level (seed&key) did you try use service #23 ReadMemoryByAddress?

I was using diagnostic session 86 (development session) with key = seed + 0x11170. Any other suggestions? Also note that #35 RequestUpload worked and I used that to dump all the the RAM at once (32kb's worth)

Using Auré's suggestion for nmot_w, I logged this last night on the way home. It does indeed change as the rpm's change, from about 11 @ 760rpm to about 47 @ 3000rpm. Is this an 8 bit value or 16 bit value? I just logged one bytes worth but would like to know if it's bigger.

I got sample rates of about 40 samples per second. That's with just the default VW TP2.0 timings. I'm sure it could be faster if you changed the timers. Probably my coding is pretty rubbish  ;D





Title: Re: Logging with KWP-2000 protocol
Post by: prj on March 29, 2014, 03:51:16 PM
20 definitions is the limit, but if I recall it correctly, then each definition signifies a memory range!
So you can define 20 memory RANGES that you can log simultaneously.

This is more than enough considering many variables are placed sequentially after one another.

To find the addresses of the variables you have to parse the table that contains all of them. Look at the MED9 FR, it lists a lot of variables in a certain order. All you need to do is find where this list is stored, parse it, and voila, you have all the variables required.


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on March 30, 2014, 12:51:03 PM
Look at the MED9 FR, it lists a lot of variables in a certain order.

Thanks prj!

That list of variables, are you refering to TKMWL ???


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on March 31, 2014, 01:34:43 PM
Using Auré's suggestion for nmot_w, I logged this last night on the way home. It does indeed change as the rpm's change, from about 11 @ 760rpm to about 47 @ 3000rpm. Is this an 8 bit value or 16 bit value?

Whoops. It was staring me in the face :-[

The w in _w is for word. So nmot_w is 16 bits. Answered my own question.

Logged nmot_w again (two bytes this time!) and multiplied by 0.25 (scaling factor). I get the rpm in high resolution ;D


Title: Re: Logging with KWP-2000 protocol
Post by: Aurélien on April 01, 2014, 09:31:26 AM
20 definitions is the limit, but if I recall it correctly, then each definition signifies a memory range!
So you can define 20 memory RANGES that you can log simultaneously.

This is more than enough considering many variables are placed sequentially after one another.

To find the addresses of the variables you have to parse the table that contains all of them. Look at the MED9 FR, it lists a lot of variables in a certain order. All you need to do is find where this list is stored, parse it, and voila, you have all the variables required.

Agreed.

BUT, it's not that easy. First not all interresting variable are listed, second the list is indirect.




Title: Re: Logging with KWP-2000 protocol
Post by: Aurélien on April 01, 2014, 09:34:40 AM

I got sample rates of about 40 samples per second. That's with just the default VW TP2.0 timings. I'm sure it could be faster if you changed the timers. Probably my coding is pretty rubbish  ;D


What hardware are you using ? Lawicell ?
Also, C ? C++ ? C# ?



Title: Re: Logging with KWP-2000 protocol
Post by: Basano on April 08, 2014, 03:14:45 AM
 :D no, nothing as fancy as that.

Arduino with Sparkfun CANBUS shield and the Arduino IDE language (very similar to C).

Cheap and cheerful!


Title: Re: Logging with KWP-2000 protocol
Post by: dream3R on April 08, 2014, 10:41:59 AM
Nice, I started in Arduino, the Uno has limited RAM but worked fine.

Chipkit is nice if you want more power ;)


Title: Re: Logging with KWP-2000 protocol
Post by: MIL_on on April 08, 2014, 10:41:13 PM
did anyone else start implementing ME7Logger on Arduino?  Thats what i am just in...
the great thing about it would be that you are able to display every var you want on a display, log them via SD-Card without Laptop (maybe not so important) and connect external sensors and view everything in ECUxPlot!


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on April 16, 2014, 01:37:02 PM
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.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on April 16, 2014, 01:48:29 PM
Most people use VCDS for MED9.
The patch I don't like. This involves modifying the binary instead of just logging the car.

You should check where that variable comes from and see if it is possible to modify it.
Another approach is, since you know the variable address, then if it is not populated often, maybe it is possible to WriteMemoryByAddress on that variable before starting to log.

Or, just do what ME7Logger does and fill the DDLI structure directly via WriteMemoryByAddress?


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on April 17, 2014, 01:02:09 AM
Most people use VCDS for MED9.

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.

The patch I don't like. This involves modifying the binary instead of just logging the car.

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.

You should check where that variable comes from and see if it is possible to modify it.
Another approach is, since you know the variable address, then if it is not populated often, maybe it is possible to WriteMemoryByAddress on that variable before starting to log.

Or, just do what ME7Logger does and fill the DDLI structure directly via WriteMemoryByAddress?

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!)



Title: Re: Logging with KWP-2000 protocol
Post by: prj on April 22, 2014, 01:24:35 PM
No easy way then besides making an automatic patcher to patch binaries.
That's pretty easy to do though.
I have so many ideas what to do, but I just do not have time when I have a carpark outside the shop needing tuning.

To make this accessible, one would need to implement this with a easy to get cable as opposed to standalone MCU setup.
For example ELM327, BMW K+DCAN or ask Ross-tech for specs and implement it with the VCDS cable.

The more interesting part is to parse the variable structure found in the ECU, so that the variable config can be auto generated, like ME7Logger does.


Title: Re: Logging with KWP-2000 protocol
Post by: Basano on April 28, 2014, 02:18:25 AM
Thanks,

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


Title: Re: Logging with KWP-2000 protocol
Post by: melodic on August 12, 2014, 09:08:55 PM
I have an interesting idea.
Take the arduino due (it has 2 canbus). Read needed groups by OBD can bus and transfer they to the dashboard instead song name. Also write logs to SD card. Maybe log G-sensor and GPS or anyone else. To control we can use cruise buttons.


Title: Re: Logging with KWP-2000 protocol
Post by: dream3R on January 01, 2016, 09:39:19 PM
I'd like to reignite this if interest just as a hobby.


Title: Re: Logging with KWP-2000 protocol
Post by: dream3R on January 01, 2016, 09:41:36 PM
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!)



With the Simos FR and comparing the Audi Diag DB there is $cmds missing from the FR for sure, here not so sure.


Title: Re: Logging with KWP-2000 protocol
Post by: kuebk on September 01, 2016, 01:39:47 PM
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?




Title: Re: Logging with KWP-2000 protocol
Post by: ozzy_rp on September 02, 2016, 03:30:57 AM
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?

Try to use 0x35 command

Here line from Diagnostic Service Config with supported command:
DiagCom_ServiceTable_t <0x35, 0xFF, 0xFFFB, 8, sub_8007E8B2, sub_8007E880, off_8002ED18> ; requestUpload


Title: Re: Logging with KWP-2000 protocol
Post by: dream3R on September 02, 2016, 12:27:29 PM
Sounds like uds that?


Title: Re: Logging with KWP-2000 protocol
Post by: kuebk on September 02, 2016, 01:04:50 PM
Try to use 0x35 command

Here line from Diagnostic Service Config with supported command:
DiagCom_ServiceTable_t <0x35, 0xFF, 0xFFFB, 8, sub_8007E8B2, sub_8007E880, off_8002ED18> ; requestUpload


I'm already using 0x35/0x36, but is there any other way?

Sounds like uds that?

It's KWP.


Title: Re: Logging with KWP-2000 protocol
Post by: elRey on May 06, 2017, 08:55:46 PM
edit: my post may violate license of me7logger. removing it for now.


Title: Re: Logging with KWP-2000 protocol
Post by: de_F on October 31, 2018, 06:42:26 AM
I'm already using 0x35/0x36, but is there any other way?

It's KWP.


Sorry for resurrecting this old thread,

Service 35 RequestUpload seems to work on MED17 and as long as I aim for an upload within 0x40000h and 0x7FFFF I get my response as requested.

The RAM tables on MED17 for example are possibly located at 0xC0000000 or 0xD0000000 ect (32bit address). according to A2L's floating around.
It looks like the standard KWP protocol can only handle 24bit addresses, so up to 0xFFFFFF.

I understand you got this working kuebk to make your logger over 0x35 RequestUpload / 0x36 TransferData. But for the moment I keep on getting answer 52 canNotUploadFromSpecifiedAddress (so my addressing is definitely wrong as I am aiming for a blocked/protected address)

Any pointers or possibly just a way to calculate address 0xC0000000 so my request passes ?


Title: Re: Logging with KWP-2000 protocol
Post by: kuebk on November 01, 2018, 01:55:36 AM
Memory regions are covered in detail in A2L.


Title: Re: Logging with KWP-2000 protocol
Post by: de_F on November 03, 2018, 12:33:46 PM
Thanks for the heads up. Should work with 0x400000 and 0x500000 then. I'll give it a shot in the next few days.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on May 27, 2021, 05:55:06 AM
Hi guys,
I've been working on a logger for my 7.1.1 ST10 using all the great  info on this thread.

Being a bricklayer, its been a freaking hard five weeks learning this stuff, I'm getting close but got stuck for a while.
I can get all the general info off the ecu, but the more advanced commands seem to be unavailable.
When I ask for :
0x10 0x85 (startDiagnosticSession, developmentSession),  I get an error back:
0x7F,0x10,0x11 (servicENotSupported).
This is after the 0x27 0x01 key was accepted.

I get a similar error (0x7F,XX,0x12) when I try reading,writing ram and dynamicallydefininglocalvariables  in mode 0x10,0x86 (which does get accepted)
I believe some codeword in the ecu must be of the wrong value, keeping those commands hidden, even though the security key was accepted.
 From plenty of reading of the 9.1FR, I think sy_tkdlima in the MED9.1 is the culprit for that ECU, but can anyone help me out with ME7 or 7.1.1 devices? I can't easily find any codewords  in the few ols I checked that fit the bill, and the ME7 FR didn't have anything that stood out to my insipid brain.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on May 27, 2021, 09:12:33 AM
You don't need any special session for DDLI, it's open.
The only reason ME7Logger asks for dev session is so that it can use WriteMemoryByAddress.
If you do not use the exploit and simply use the first 20 var DDLI, it'll still be plenty fast enough, and you won't need to do anything special.
Same goes for MED9.

MED17 only goes through RequestUpload on TP2.0/K but it's mega slow because for every ram cell you have to send 3 commands, so it's a waste of time. Need to patch stack and implement something like DDLI.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on May 27, 2021, 10:51:02 PM
Thanks for that, I just tried making one DDLI without having entered any special sessions and it worked!
 I haven't been able to make a DDLI with more than 3 memory variables as yet. I get the 0x12 error when I try. Sometimes I get an error when two variables, which work individually, are both put in one DDLI, with the index of the second changed to 02 -  but it might just be my vb6 program doing something wrong with the longer strings- I need to monitor the port to see if the packet looks legit.
It would be nice to get 20 variables defined and not have to do the trick.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on May 28, 2021, 01:03:15 AM
Look at the FR, there is one identifier that supports up to 20 variables, the rest support a max of 3 variables at a time.
Use the 20 variable one.

Less than 20 variables:
1. Define
Loop:
2. Read

More than 20 variables:
Loop:
1. Define
2. Read


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on May 31, 2021, 04:34:13 AM
Played with defining ddlis today. It looks like the ME7.1.1 ST10  still has the limitation of 3 for all of them, including F0, which has 20 in the MED9.1.
Tomorrow I will see how quickly one reading takes, but I get the feeling trying to extract 20 or so variables with 7 ddlis might be a bit slow. I need to get into dev mode to increase the baud from 10400,I believe the command is 0x10 0x86 0x64 for 57600 baud, although I could not find in in the 9.1 FR.  I'll give it a go tomorrow.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on May 31, 2021, 09:49:15 AM
I mean even if it's 3 on each of them, just edit the array in the binary where it has 3 on each and change the array size for the first one to be 30 and 0 on the rest.
And go to town...
I've not looked at ME7, but MED9 has an array which defines the size for each block.

I change the MED9 one to 47, and the rest to 0, although you can read 42 before overflowing the CAN receive buffer.
Still faster than 20 though.
Obviously the sum of all of them still has to add up to the same number or you will overflow the memory region allocated to DDLI.
ME7Logger gets around that on ME7 by moving the buffer somewhere else. That's why it needs WriteMemoryByAddress.

All that is done (copied from ECU Explorer by APR) is define a a few magic memory locations with DDLI, then scan for those locations.
After that scan for the pointers to those locations.
Then use WriteMemoryByAddress to redirect the pointers and modify their size in an arbitary way.
After that you don't even call DDLI to add or remove something, you just dump all the stuff using WriteMemoryByAddress.

All this stuff is super old though. For the ME7.1.1 ST10 you are better off defining your own custom measuring blocks in the binary and then simply reading those out with $21 with a high baud rate.
Yes you will have to flash if you need to add something, but it'll be fast enough.

Also I don't remember needing dev mode to change baud, but my memory is hazy on that point.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 01, 2021, 06:10:12 AM
Wow, great info, thanks. Looks like I had better learn some minimal IDA so I can find the array definitions in the flash and change them as you said. Hopefully its not in the MPC code.
I managed to get 25 samples per second just reading one DDLI with the 3 locations. Good enough for me - if I can do the mod for more variables that is.
I used the Timing parameters as used by Me7Logger which almost doubled the speed, but still cant get into mode 10 86  to change baud rate as yet. Need the algorithm for 27 03  key. Basano's MED9.1 algorithm doesnt work on the ME7.1.1, there is no equivalent to the 0x0001170 key in the bin file that I could find by comparing his bin to mine.  Looks like IDA is calling me again.

Luckily, I copied the EEPROM before fooling around, as I got locked out permanently for too many wrong tries.


Title: Re: Logging with KWP-2000 protocol
Post by: prj on June 01, 2021, 01:06:19 PM
You won't get locked out permanently, it just sets a timer, which will reset after a while with ignition on.
I'd do a search for 3 3 3 3 3 3 3 in the binary first before IDA.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 08, 2021, 06:25:24 AM
Thanks again prj, I had a quick look and found quite a few in the file. I haven't played with it as yet, but its a good backup if a generic logger doesn't work for me. I also looked for a similar string of numbers starting with a $14 $3 in a MED9 file and it showed up instantly.
I spent 3 days making a procedure to dump memory and it finally worked quite well. I just used ddli F0 to copy chunks of 128 bytes RAM to a file and looked for ddli F1 which I defined before scanning.
The memory region with the ddlis is around $0F42XX . Nothing in the $380000 to $390000 region like ME7 has.
I also noted that ddli F6 to F9 are dodgy. They only work for a few seconds if that and seem to get overwritten quickly and stop working all together. F0 to F5 don't give any probs and I can find them in the memory dump, but not the others.Weird!
I also found the table that points to them, the one me7logger alters, but it doesn't point at quite the right memory location. I'm thinking it must a small error in the dumping program, but gave up for the day because it looks OK.
Also noted that to define ddlis with variables longer than one byte, the next variable has to be incremented by the number of bytes of the previous one. So if the first variable (01) is two bytes, then the next variable needs to be named 03 not 02. There is no mention of that in any commonly available documents.
I'm thinking of using the memory allocated for the 10 ddlis for one big ddliF0. Hopefully 27 or 30 variables in one swoop. It avoids looking for an unused RAM location like ME7logger does (not sure how to find such a location with 100% certainty).
 If the F6 to F9 ddli data actually do get overwritten, I may just have to find some free RAM in any case. If I get the program to work  well, I'll post it up on Nefmoto for other people also unfortunate enough to have ST10s

If anyone reading this has of a copy of an ALS file for a  022906032KG they can spare please PM me. Even just the complete list of RAM variables from the ALS will do. I purchased a 032CE ECU for this project as I found the ALS on here, but I don't have the time for a few months to replace the 032KG ECU in the car with the 032CE and it will take weeks for me find them by comparing maps to test the program in the car.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 09, 2021, 06:03:58 AM
Its working!  Writing to the pointer table and the ram locations it points to does the trick. I just managed to get 20 ram variables in one go, I'll try more tomorrow.

 Setzi could have easily modded  his logger in 10 mins for the ST10.

 Oh yeah I meant A2L file in previous post.


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on June 09, 2021, 05:15:54 PM
Any chance I can convince you to write a me7logger workalike (that supports both C16 and ST10) and publish the source? :)


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on June 09, 2021, 05:16:55 PM
edit: my post may violate license of me7logger. removing it for now.


This is why abandonware is cancer.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 10, 2021, 04:40:21 AM
Any chance I can convince you to write a me7logger workalike (that supports both C16 and ST10) and publish the source? :)

All I can do for now with certainty the ME7.1.1 ST10, because I can test it out in front of me, and I have an early version on the bench and a later one in the car. 
If I was a proper programmer like many on here I could study ME7logger with IDA and implement it in my logger, but I can't, as my skills are weak at assembler. But I did notice that the principle is exactly the same in both although some of the commands he used
did not seem to work on the ST10.
Making it work on all ME7s, not just a few is the challenge I would face, and not having an ecu on bench is a massive disadvantage.
Here is a screenshot of the logger; well its the bells and whistles one I needed to make, still just for testing, but most of it will disappear for the final version. It works with a blue dumb cable.  The source code will be released for sure.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 18, 2021, 04:44:09 AM
The logger is still going well. I've just been ironing out a few things. I will probably limit it to 40 variables but 50 gave it no problem on the bench. The logger scans for a  large chunk of free RAM (00)  far away from data and writes the new RAM variables there. It scans for the original pointer and redirects it to the new address. I'm using the RAM in the lower regions  as the 380000 RAM takes about 2 minutes to lose its memory after powering down, making testing tedious.
Unfortunately, I still haven't managed to increase the baud rate.
The command 108663, which is apparently for 56000, is accepted by the ECU but then all communication stops. I tried sending $00,$01,$F1 $55 $70  but I just get echos back and eventually get disconnected. Its as if its waiting for some special character or something from the computer. There is nothing in the me7 FR and the there are no specifics in the MED9 FR I could find about the special baud command.The 1086 is well documented everywhere but 1086XX is an enigma.
Also tried getting into the weaker security access level  3/4  to see what it offers but after having tried adding all sorts of numbers to the seed  to make the key, and getting rejected, I gave up. A few I tried  were $40,$00011170,KLOGIN, SLOGIN. Is there a simple way of finding it in the bin file?   Or would a scan through the RAM reveal the key?

Next is the boring task of converting the numbers into values and saving them. I'm now remembering why the last program I wrote was back  in 96, with VB3....


Title: Re: Logging with KWP-2000 protocol
Post by: prj on June 18, 2021, 08:58:05 AM
Stupid question, but after you switch to new baud, are you sure you are also changing the parameters of the port to accommodate the new baud rate?
I implemented some of this stuff about 10 years ago and I am 100% sure I did not have any issues switching baud rate.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 19, 2021, 05:35:46 AM
Stupid question, but after you switch to new baud, are you sure you are also changing the parameters of the port to accommodate the new baud rate?
I implemented some of this stuff about 10 years ago and I am 100% sure I did not have any issues switching baud rate.

Yeah, I change the setting straight after receiving the 5086. Mind you, the VCDS Turbo button also freezes up on these ecus. Im not sure if vcds uses the same method. BTW  Do you know if security level 3/4 opens doors to anything more than level 1/2 does?
 


Title: Re: Logging with KWP-2000 protocol
Post by: prj on June 19, 2021, 02:08:49 PM
Security question is odd - if it lets you $2C random memory areas and WriteByMemoryAddress also works then what else do you want to accomplish?
Baud can be changed without any security access IIRC. You have some issue in your code.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 20, 2021, 05:57:58 AM
I don't use any security for the logger! - so long as I dont try to change the baud rate that is, cause the108663 command for 56000 needs sec level 1/2 which the forum helped me crack.
 Without sec level  1/2 first, I get error 33. It might be an st10 issue that c166 dont have. I dont have a ME7.1.1 c166 to try so wouldnt have a clue if  all 7.1.1s need sec access or not to change baud.  Perhaps its ME7 that dont need security to change baud?

Sec level 3/4 i dont know much about, that's why I asked!
Why have 2 levels of security? What does it allow that 1/2 doesnt? It might be handy to know...

 So, atm, if I leave it at 10400, I have no need for any seed/key for the logger.
10400 might be quick enough - got to see final samples per sec after the conversion and saving of 40 variables to a file. A quick test indicates that it will be the ECU that will be the bottle neck, as I can process 35 variables and save them at about 500Hz.
 What is a regarded as a reasonable sample rate for tuning? Is 10Hz enough?


Title: Re: Logging with KWP-2000 protocol
Post by: prj on June 20, 2021, 09:59:46 AM
Changing baud rate does not need security access.
Dev session does.

You can request the default KWP session, then you should be able to switch baud.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 26, 2021, 06:41:36 AM
I gave up on baud rate, I just can't get it to work.
On the bright side, I changed the ecu in the Mk5 R32  car and took the first log.
I posted a snipped done at WOT. I don't know how to tune as yet, but at a glance all the numbers seem to have been converted properly?
There are too many significant figures for realistic accuracy, but will drop it to 2 decimal places next time. Hopefully it is compatible with Ecuxplot, I cant test that as I only have Win7 32 bit laptop ATM.
Can anyone see something that doesn't look right?


Title: Re: Logging with KWP-2000 protocol
Post by: Blazius on June 26, 2021, 09:08:13 AM
I gave up on baud rate, I just can't get it to work.
On the bright side, I changed the ecu in the Mk5 R32  car and took the first log.
I posted a snipped done at WOT. I don't know how to tune as yet, but at a glance all the numbers seem to have been converted properly?
There are too many significant figures for realistic accuracy, but will drop it to 2 decimal places next time. Hopefully it is compatible with Ecuxplot, I cant test that as I only have Win7 32 bit laptop ATM.
Can anyone see something that doesn't look right?


does not work in ecuxplot for me


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on June 26, 2021, 10:31:43 PM
ecuxplot looks for certain headers to decide what format the log is.

That log doesn't have any of the things ecuxplot looks for to detect ME7Logger files, if thats what you intend to be compatible with.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on June 27, 2021, 04:59:37 AM
ecuxplot looks for certain headers to decide what format the log is.

That log doesn't have any of the things ecuxplot looks for to detect ME7Logger files, if thats what you intend to be compatible with.

I see, so out of the pic below which lines does Ecuxplot always require? Anything else it looks for?


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on June 27, 2021, 10:23:03 AM
It looks for ME7-Logger


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on July 07, 2021, 06:35:03 AM
Can someone please test the attached file for ecuxplot compatability.
I made it look more like some csv files I found on here. Some had  quotation marks around the descriptions so I put those in too.


Title: Re: Logging with KWP-2000 protocol
Post by: Blazius on July 07, 2021, 11:08:15 AM
Can someone please test the attached file for ecuxplot compatability.
I made it look more like some csv files I found on here. Some had  quotation marks around the descriptions so I put those in too.

It works, however the filter doesnt work possibly because you didnt log pedal pos% ?Good job.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on July 08, 2021, 05:06:45 AM
Awesome Blazius, thanks for checking!  I borrowed a 64 bit win 7 pc to test it myself but EcuXplot only worked once and now shows the circular watchglass no matter who's csv I download from here. Weird.

I'm all done... I think.  Did the last of the coding today. Works in the car, tested 40 mins of logging, can be paused at the touch of the spacebar, doesn't care when disconnected briefly, reconnects by pressing a key if a big disconnection occurs( neither actually occured during testing), doesn't overwrite files and on the bench logged over 1 million reads of 40 variables no problem (except excel couldn't handle all the data). I tested it with XP, Win7 32 & 64 and Win10 64.

The R32Logger will soon be uploaded, all thanks mostly to the info on this thread- all of those legends present and past who posted the vital info.
R32Logger does all I need for playing with the motor, but I decided to share it for those hobbyists in the future who want to put turbos on their BUB motors.
Hopefully it will work on other ST10s too but there are no guarantees.
As requested by Nyet its got provisions for testing on c167s,  with slow init only. It might work on others too as long as they are little endian
Main problem is that there is no Me7Info.exe for the ST10. Im not man enough to tackle that job. Luckily Gremlin posted some files with the A2L for my ECU in them so I don't need such a program. alternatively, someone could easily add blocks to the code, instead of RAM variables so it becomes like a better VCDS if they really want.


Title: Re: Logging with KWP-2000 protocol
Post by: BlackT on July 08, 2021, 05:29:19 AM
Great work man  :D :D Well done


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on July 08, 2021, 03:20:26 PM
fantastic, great work!


Title: Re: Logging with KWP-2000 protocol
Post by: nyet on July 08, 2021, 03:22:35 PM
Main problem is that there is no Me7Info.exe for the ST10.

You might start with 360trev's swissarmyknife tools (dont have the link handy)


Title: Re: Logging with KWP-2000 protocol
Post by: 360trev on July 17, 2021, 05:26:34 AM
Just catching up on this now.Nice Job!

I can auto-detect tonnes of variables and maps now in most ME7.x firmwares. Let me know the ones you want and give me links to the bin files and I'll see what my latest version pulls. It can even instrument all the KWP2000 functions in a rom and pull out all of the LocalIdentifier table entries if they are present..

e.g.

ReadDataByLocalIdentifier() : 0x21 @ 037570
Address of subfunc() : 0x00838204 : seg=0x020C)

SEGC            @ ROM:0X838204 RAM:0X2706224 File-Offset:0X38204 (seg=0x020C [segadr=0x830000] val=0x8204)
Searching for 'XXXXxxxxXXXXxxxxF0xx5c2x20xx5c1x00xxdcxxa9xx'...
1) found reference to sig @ byte_offset=0x3825c
2) found reference to sig @ byte_offset=0x384be
Matches=2

The offset we care about is: 0x3825C segm: 0x206 valu: 0x2C54
LIT             @ ROM:0X81AC54 RAM:0X26E8C74 File-Offset:0X1AC54 (seg=0x0206 [segadr=0x818000] val=0x2C54)

--
        Idx: 0x2F addr: 0x00F27A entryType: 0x0208      nmot_w     ; engine speed                                                   : Location: Memory        Type: Data
        Idx: 0x32 addr: 0x00F32C entryType: 0x0208      ml_w       ; filtered air mass flow                                         : Location: Memory        Type: Data
        Idx: 0x34 addr: 0x381B50 entryType: 0x0208      ti_w       ; injector                                                       : Location: Memory        Type: Data
        Idx: 0x35 addr: 0x00F330 entryType: 0x0208      rl_w       ; relative air charge                                            : Location: Memory        Type: Data
        Idx: 0x36 addr: 0x00F2A6 entryType: 0x0208      wdkba_w    ; throttle angle                                                 : Location: Memory        Type: Data
        Idx: 0x37 addr: 0x813532 entryType: 0x0108      mshfm_w    ; mass air-flow HFM                                              : Location: Calibration   Type: Data
        Idx: 0x39 addr: 0x380E66 entryType: 0x0208      vfzg_w     ; vehicle speed                                                  : Location: Memory        Type: Data
        Idx: 0x3A addr: 0x813534 entryType: 0x0208      usvkk_w    ; primary O2 Lambda probe LSU voltage (corrected)                : Location: Memory        Type: Data
        Idx: 0x3B addr: 0x381964 entryType: 0x0208      ushk_w     ; primary O2 Lambda probe voltage                                : Location: Memory        Type: Data
        Idx: 0x3C addr: 0x813532 entryType: 0x0108      nsol_w     ; idle setpoint speed                                            : Location: Calibration   Type: Data
        Idx: 0x3E addr: 0x381B8E entryType: 0x0208      tvu_w      ; battery voltage                                                : Location: Memory        Type: Data
        Idx: 0x3F addr: 0x380ECA entryType: 0x0208      upwg1_w    ; throttle pedal voltage PWG potentiometer 1                     : Location: Memory        Type: Data
        Idx: 0x40 addr: 0x380ECC entryType: 0x0208      upwg2_w    ; throttle pedal voltage PWG potentiometer 2                     : Location: Memory        Type: Data
        Idx: 0x41 addr: 0x3819C6 entryType: 0x0208      wped_w     ; normalized angle acceleration pedal                            : Location: Memory        Type: Data
        Idx: 0x42 addr: 0x381E32 entryType: 0x0208      fr_w       ; lambda controller output                                       : Location: Memory        Type: Data
        Idx: 0x43 addr: 0x384EA4 entryType: 0x0208      frao_w     ; multipl. mixture adaptation factor higher load                 : Location: Memory        Type: Data
        Idx: 0x44 addr: 0x384EAC entryType: 0x0208      frau_w     ; multipl. mixture adaptation factor of the lower mult. section  : Location: Memory        Type: Data
        Idx: 0x45 addr: 0x381B78 entryType: 0x0208      fra_w      ; multiplicative mixture adaptation factor                       : Location: Memory        Type: Data
        Idx: 0x46 addr: 0x384EB2 entryType: 0x0208      rkat_w     ; additive correction (per time) of the mixture adaptation       : Location: Memory        Type: Data
        Idx: 0x47 addr: 0x38185E entryType: 0x0208      rkaz_w     ; additive correction (per ignition) of the mixture adaptation   : Location: Memory        Type: Data
        Idx: 0x48 addr: 0x381B7A entryType: 0x0208      rka_w      ; additive adaptive correction of the relative fuel amount       : Location: Memory        Type: Data
        Idx: 0x4B addr: 0x384F68 entryType: 0x0208      dmvad_w    ; delta motor torque from loss torque adaptation                 : Location: Memory        Type: Data
        Idx: 0x4C addr: 0x381D7A entryType: 0x0208      mdverl_w   ; resistant torque of the engine                                 : Location: Memory        Type: Data
        Idx: 0x4D addr: 0x384E5E entryType: 0x0208      fho_w      ; correction factor: altitude                                    : Location: Memory        Type: Data
        Idx: 0x4F addr: 0x384E6C entryType: 0x0208      pu_w       ; ambient pressure                                               : Location: Memory        Type: Data
        Idx: 0x50 addr: 0x38211A entryType: 0x0208      lamsoni_w  ; lambda actual value                                            : Location: Memory        Type: Data
        Idx: 0x51 addr: 0x382190 entryType: 0x0208      lamsons_w  ; required lambda referred to lambda sensor fitting location     : Location: Memory        Type: Data
        Idx: 0x52 addr: 0x384FA0 entryType: 0x0208      lamsonh_w  ; pseudo lambda actual value measured w/nernst probe behind cat  : Location: Memory        Type: Data
        Idx: 0x53 addr: 0x384F9E entryType: 0x0208      lamsolh_w  ; pseudo lambda setpoint behind cat                              : Location: Memory        Type: Data
        Idx: 0x54 addr: 0x382078 entryType: 0x0208      wnkwas_w   ; Angle of camshaft to crankshaft in the working cycle           : Location: Memory        Type: Data
        Idx: 0x55 addr: 0x381F66 entryType: 0x0208      wnwue_w    ; camshaft overlap angle of inlet and outlet valve opening       : Location: Memory        Type: Data
        Idx: 0x58 addr: 0x380ED2 entryType: 0x0208      msdk_w     ; air-mass flow through throttle valve                           : Location: Memory        Type: Data
        Idx: 0x59 addr: 0x00F388 entryType: 0x0208      dlahi_w    ; I-portion of the LRSHK                                         : Location: Memory        Type: Data
        Idx: 0x5A addr: 0x381D80 entryType: 0x0208      miist_w    ; indexed engine torque high pressure phase actual value         : Location: Memory        Type: Data
        Idx: 0x5B addr: 0x381D1E entryType: 0x0208      mifa_w     ; indexed engine torque driver request                           : Location: Memory        Type: Data
        Idx: 0x5C addr: 0x381D38 entryType: 0x0208      mrfa_w     ; relative driver request torque from FGR and pedal              : Location: Memory        Type: Data
        Idx: 0x5D addr: 0x381D70 entryType: 0x0208      miopt_w    ; optimal indexed moment                                         : Location: Memory        Type: Data
        Idx: 0x5F addr: 0x813532 entryType: 0x0108      mizsol_w   ; indexed resulting target torque for ZW intervention            : Location: Calibration   Type: Data
        Idx: 0x62 addr: 0x813532 entryType: 0x0108      mimax_w    ; maximum achievable indexed moment                              : Location: Calibration   Type: Data
        Idx: 0x64 addr: 0x380EE8 entryType: 0x0208      miasrs_w   ; indexed engine target torque ASR (for rapid intervention)      : Location: Memory        Type: Data
        Idx: 0x65 addr: 0x380EE6 entryType: 0x0208      miasrl_w   ; indexed engine target torque ASR (for slow intervention)       : Location: Memory        Type: Data
        Idx: 0x66 addr: 0x380EF2 entryType: 0x0208      mimsr_w    ; indexed engine target torque MSR                               : Location: Memory        Type: Data
        Idx: 0x68 addr: 0x381B38 entryType: 0x0208      nskup_w    ; target speed F1 gearbox (CAN signal)                           : Location: Memory        Type: Data
        Idx: 0x69 addr: 0x381CB8 entryType: 0x0208      dmar_w     ; delta torque anti-jerk                                         : Location: Memory        Type: Data
        Idx: 0x6A addr: 0x381C76 entryType: 0x0208      dmllri_w   ; desired torque change from the idle speed control (I-)         : Location: Memory        Type: Data
        Idx: 0x6B addr: 0x381C80 entryType: 0x0208      dmllr_w    ; desired torque change from the idle speed control (PD-part)    : Location: Memory        Type: Data
        Idx: 0x6E addr: 0x385056 entryType: 0x0208      ftead_w    ; charcoal canister charge                                       : Location: Memory        Type: Data
        Idx: 0x6F addr: 0x384654 entryType: 0x0208      msndko_w   ; norm leakage air mass flow through throttle blade              : Location: Memory        Type: Data
        Idx: 0x74 addr: 0x83738A entryType: 0x0248      DCLA_TriggerEvent1()                                                        : Location: Firmware      Type: Function
        Idx: 0x75 addr: 0x837418 entryType: 0x0248      DCLA_TriggerEvent2()                                                        : Location: Firmware      Type: Function
        Idx: 0x76 addr: 0x837466 entryType: 0x0248      DCLA_TriggerEvent3()                                                        : Location: Firmware      Type: Function
.. etc..


Title: Re: Logging with KWP-2000 protocol
Post by: 360trev on July 17, 2021, 05:28:14 AM
Obviously this LIT dump varies from firmware to firmware as the LIT table is optional by manufacturer and not all ME7's have it present.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on July 17, 2021, 06:02:11 AM
Hi Trev!

Give this a go please.

Cheers.


Title: Re: Logging with KWP-2000 protocol
Post by: 360trev on July 17, 2021, 07:35:47 AM
Hi Trev!

Give this a go please.

Cheers.

Ahhh Its an ST10 dump. I didn't see that. First time I've ever even looked at a rom file. They are still based on the same C16x instruction set but very different composition. I will take a look and update my model to support ST10's too.

Succeded loading romfile #1 (0x100000 bytes).

SHA-256 of romfile #1: 6eaf0ab3c17dd1b27299a41ea0d5f22bba32072b43f9e5413559fa25330c8351
Loaded Primary ROM in 1Mb Mode

-[ DPPx Setup Analysis ]-----------------------------------------------------------------

>>> Scanning for Main ROM DPPx setup #1 [to extract dpp0, dpp1, dpp2, dpp3 from rom]

Searching for DPPx 'e600xxxxe601xxxxe602xxxxe603xxxx'...
1) found reference to sig @ byte_offset=0xe230

dpp0: (seg: 0x023f phy:0x008fc000) calibration data segment 0, constants
dpp1: (seg: 0x003c phy:0x000f0000) calibration data segment 1, constants
dpp2: (seg: 0x00e0 phy:0x00380000) external RAM
dpp3: (seg: 0x0003 phy:0x0000c000) Int. RAM, XRAM, SFR

Note: dpp3 is always 3, otherwise accessing Int. RAM, XRAM, SFR is not possible

-[ EEPROM Analysis ]-----------------------------------------------------------------

>>> Scanning for basic EEPROM extraction parameters
EEPROM Number of Pages: 128 (2048 Bytes)
EEPROM Chip Select Pin: P6.3

-[ Basic Firmware information (Primary ROM) ]-----------------------------------

>>> Scanning for BOOT ROM Version String [info]
Not found
>>> Scanning for ROM String Table Byte Sequence #1 [info]---------[ ROM #1 ]----------------------


-[ Free Space Analysis ]-----------------------------------

Searching for free space in firmware...

 1) Unused bytes @ 0x003908 - 0x004000 : length    1,784 (0x6F8   ) bytes
 2) Unused bytes @ 0x005786 - 0x00C000 : length   26,746 (0x687A  ) bytes
 3) Unused bytes @ 0x00D024 - 0x00E000 : length    4,060 (0xFDC   ) bytes
 4) Unused bytes @ 0x034F6C - 0x0DFFFA : length  700,558 (0xAB08E ) bytes
 5) Unused bytes @ 0x0F4722 - 0x0FB508 : length   28,134 (0x6DE6  ) bytes
 6) Unused bytes @ 0x0FF4D3 - 0x0FFFFE : length    2,859 (0xB2B   ) bytes

Discovered 764,141 bytes (746.0 KBytes) unused in firmware [72.9%].

Largest free chunk region : 0x34F6C, length  700,558 bytes.

--


So your firmware has a whopping 73% unused space, that's quite some record ! :)


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on July 17, 2021, 07:58:25 AM
Would the MCP be of any use? Its about 832k. Not sure how much of that is actually code.


Title: Re: Logging with KWP-2000 protocol
Post by: 360trev on July 17, 2021, 08:45:41 AM
Would the MCP be of any use? Its about 832k. Not sure how much of that is actually code.

Ahh.. so is this not the full dump? Send the full set of files and I will see what it can do. On standard C167 based firmwares it can even analyze eeprom's and find the checksum functions and gpio pins, etc. As for ST10's well its a different skew built with different toolchains, etc. I'm guessing I'm going to need to teach it some new smarts and treat it like my support for PPC and Tricore that I'm currently building preliminary support for.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on July 18, 2021, 01:45:40 AM
Its the full dump of the 29F800 flash that you get from a tool like galletto, and has all the maps just like the others do.
But the ST10 has stacks of other code that you need more specialized tools to extract, like MPPS or ST10 flasher.
 From memory at least 3/4 of that 832kB has code in it. I know very little about processors but I'd be very interested to know what is in that code and why it needs that much of it, when the C16x seems to get away with just a tiny amount.
I will post the MCP in about 18 hours as I have it on another computer.


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on July 18, 2021, 08:11:55 PM
Here it is.
The first 32kB of the file  go into the memory area 0-$8000 of the ST10
The rest of the file is from $18000 .


Title: Re: Logging with KWP-2000 protocol
Post by: prj on July 19, 2021, 02:44:52 AM
The intflash has the majority of important stuff in it. Almost all of it is code. That's why most of the flash is empty.


Title: Re: Logging with KWP-2000 protocol
Post by: 360trev on July 19, 2021, 05:16:50 AM
The intflash has the majority of important stuff in it. Almost all of it is code. That's why most of the flash is empty.

Yes thanks Prj, I can see that. Including even the vector table !

Q. Do you have a good memory map layout document for ST10's to hand so I can virtualize the references easily into my own built dissassembler? If not don't worry I will work it out..


Title: Re: Logging with KWP-2000 protocol
Post by: prj on July 19, 2021, 05:39:07 AM
Code:
def makesegmentsST():
idc.AddSeg(0xE000, 0xE800, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xE000, "XRAM0")
idc.AddSeg(0xF600, 0xFE00, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xF600, "IRAM")
idc.AddSeg(0xFE00, 0x10000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xFE00, "SFR")
# idc.AddSeg(0x10000, 0xE0000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x10000, "INTFLASH")
idc.AddSeg(0xE0000, 0x100000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xE0000, "XRAM1_IND")
idc.AddSeg(0x380000, 0x390000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x380000, "XRAM1_DIR")
# idc.AddSeg(0x800000, 0x900000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x800000, "EXTFLASH")
return

Code:
def setdppST():
idc.SetSegDefReg(0x0000, "dpp0", 0x23F)
idc.SetSegDefReg(0x0000, "dpp1", 0x3C)
idc.SetSegDefReg(0x0000, "dpp2", 0xE0)
idc.SetSegDefReg(0x0000, "dpp3", 0x03)

idc.SetSegDefReg(0x10000, "dpp0", 0x23F)
idc.SetSegDefReg(0x10000, "dpp1", 0x3C)
idc.SetSegDefReg(0x10000, "dpp2", 0xE0)
idc.SetSegDefReg(0x10000, "dpp3", 0x03)

idc.SetSegDefReg(0x800000, "dpp0", 0x23F)
idc.SetSegDefReg(0x800000, "dpp1", 0x3C)
idc.SetSegDefReg(0x800000, "dpp2", 0xE0)
idc.SetSegDefReg(0x800000, "dpp3", 0x03)
return


Title: Re: Logging with KWP-2000 protocol
Post by: 360trev on July 20, 2021, 05:39:14 PM
Code:
def makesegmentsST():
idc.AddSeg(0xE000, 0xE800, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xE000, "XRAM0")
idc.AddSeg(0xF600, 0xFE00, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xF600, "IRAM")
idc.AddSeg(0xFE00, 0x10000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xFE00, "SFR")
# idc.AddSeg(0x10000, 0xE0000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x10000, "INTFLASH")
idc.AddSeg(0xE0000, 0x100000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0xE0000, "XRAM1_IND")
idc.AddSeg(0x380000, 0x390000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x380000, "XRAM1_DIR")
# idc.AddSeg(0x800000, 0x900000, 0, 0, 0, idc.scPub)
idc.RenameSeg(0x800000, "EXTFLASH")
return

Code:
def setdppST():
idc.SetSegDefReg(0x0000, "dpp0", 0x23F)
idc.SetSegDefReg(0x0000, "dpp1", 0x3C)
idc.SetSegDefReg(0x0000, "dpp2", 0xE0)
idc.SetSegDefReg(0x0000, "dpp3", 0x03)

idc.SetSegDefReg(0x10000, "dpp0", 0x23F)
idc.SetSegDefReg(0x10000, "dpp1", 0x3C)
idc.SetSegDefReg(0x10000, "dpp2", 0xE0)
idc.SetSegDefReg(0x10000, "dpp3", 0x03)

idc.SetSegDefReg(0x800000, "dpp0", 0x23F)
idc.SetSegDefReg(0x800000, "dpp1", 0x3C)
idc.SetSegDefReg(0x800000, "dpp2", 0xE0)
idc.SetSegDefReg(0x800000, "dpp3", 0x03)
return

Thx prj!


Title: Re: Logging with KWP-2000 protocol
Post by: R32Dude on May 11, 2022, 05:51:21 AM
Would anyone know the optional numbers XX in the 1086XX command to get faster baud rates?
I spent the day with ida but didnt get very far. I found the baud rates in hex, and the S0BG commands, but cant figure out much else.