|
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. not shure about your question for OS and HW. In general I'm looking at ME7.x ECUs withCan you please state OS and hardware? Thanks. 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 setupa 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.
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.
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(): Code: def setdppST(): Title: Re: Logging with KWP-2000 protocol Post by: 360trev on July 20, 2021, 05:39:14 PM Code: def makesegmentsST(): Code: def setdppST(): 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. Title: Re: Logging with KWP-2000 protocol Post by: prj on January 16, 2023, 06:28:57 AM I have documented the exploit of injecting own service handler into the ECU here:
https://github.com/prj/me7log This is the approach ME7Logger uses as well. Much more to come shortly. Title: Re: Logging with KWP-2000 protocol Post by: fragolas on January 16, 2023, 07:57:48 PM Nice work prj.
I have been using readmemorybyadress to log my me7.3.1, it's not the fastest way but it works. I don't think that writememorybyadress is supported on this ecu, never tested, so for me, the new service table and handler will need to be hardcoded to use this method. Enviado do meu M2102J20SG através do Tapatalk Title: Re: Logging with KWP-2000 protocol Post by: prj on January 17, 2023, 02:19:53 AM Hardcoding is possible too. You can make a new table and edit the place in ASW where the ptr is assigned.
Then take out the init routine, as you don't need it anymore. Also will probably need to change a few EXTS statements when reading the config for the handler. You will still need some way to write stuff to RAM. So if you want to hardcode a handler you will still need to make a custom one that has a subservice for that. Title: Re: Logging with KWP-2000 protocol Post by: R32Dude on January 17, 2023, 05:13:18 PM Very generous of you to give this info out prj. Thanks!
Title: Re: Logging with KWP-2000 protocol Post by: R32Dude on January 24, 2023, 06:01:41 AM So r12 always has the pointer to the 'data to send buffer' each time a kwp2000 service is called? Also, when the custom handler finishes and puts into r4 the number of bytes in the buffer,kpw2000 automatically knows that there is data to send and does it? The code for the handler is very short compared even to the likes of ReadMemoryByAddress, which you'd think would be a short one! Nice work prj. Title: Re: Logging with KWP-2000 protocol Post by: prj on January 24, 2023, 06:47:43 AM Yes, that is correct.
Unfortunately all the receive information does not get passed as parameters or on the stack, but is instead referenced directly to RAM variables. Also the return code is directly written to a ram variable. On most newer Bosch ECU's it is much better. They use a pointer to a structure that contains everything - the pointer to the buffer, the length of the received data, the length of the sent data, the maximum allowed length of the buffer and also the return code. So everything can be done just based on the structure, and then the function itself does not return anything. So your custom handler can be ECU-agnostic and you don't have to do any setup like here. And yes, the code is super short, and as optimized as possible to reduce CPU load with many variables. Here's another freebie, all the baud rates and their numbers: Code: internal enum KWP2000_VAG_BAUDRATE {This is can be specified as the second parameter for StartDiagnosticSession, if there is a positive reply then after that you can communicate on the new baud rate. 56000 is widely supported, also through clusters. 124800 is supported through very few clusters. But if you want to increase the speed of your logger, I would just do the $2C exploit. The ST10 is a little less sensitive to the CPU load, where it makes no sense to do it with the handler. For the $2C exploit just define a single dynamic DID with some "unique" memory address and then dump the whole RAM. Look where in the RAM the table is, then look where in the RAM there is a pointer to this table (iirc length was next to the pointer). Now just update the length and the pointer to a different spot and write your own custom table with as many variables as you like there. If you are getting high CPU load, just use the next identifier (F0 is the first dynamic one, just use F1, F2 etc). This works just fine, and it works exactly the same on all ECU's, it just causes higher CPU load because the $2C routine is much less optimized than my handler and you have to more aggressively split the requests (e.g. going over 40-50 variables per one DID at high baud rates and access timings is not the best idea). So on C167 the handler approach gives you notably better performance with lots of variables, especially if you make a super optimized handler. Title: Re: Logging with KWP-2000 protocol Post by: R32Dude on February 05, 2023, 11:31:44 PM Nice!
Thanks for sharing the info, I will update the R32Logger in the next few months. The reason I could only get 20 Hz is that I use the 2C service which is slow, but if I just send the tester present I can get just over 50Hz, so your code will help. Trying to find the service table in the ST10 for the moment, things are a bit different to the C167 7.1.1! Title: Re: Logging with KWP-2000 protocol Post by: prj on February 06, 2023, 04:02:04 AM Does your ECU support more than one memory entry per in a single $2C DID?
Title: Re: Logging with KWP-2000 protocol Post by: R32Dude on February 06, 2023, 05:27:07 AM From memory, it accepts up to 3 variables for all the DDLIs, any more and an error occurred.
The logger does exactly what you describe, changes original pointer to a new location with the longer than normal list of variables. I just used the info in the setzi excel file. I also could not get direct memory writing/reading to work, but I also never figured out how to get 3/4. 2C was a good alternative to those locked services. Speed wise, a loop with 2F, just a few variables and no data processing seems to max out at 20Hz, but the tester present signal gets to 50Hz. P setting are zeroes except for P3min which I think was 20ms. So it seems to me that 2F is a slow command. Title: Re: Logging with KWP-2000 protocol Post by: prj on February 06, 2023, 08:46:01 AM Now I am confused.
If you can't get WriteMemoryByAddress to work, how are you modifying the DID table? Title: Re: Logging with KWP-2000 protocol Post by: R32Dude on February 06, 2023, 05:49:33 PM It can be done, without $3D!
Title: Re: Logging with KWP-2000 protocol Post by: prj on February 07, 2023, 07:10:08 AM It can be done, without $3D! WriteDataByCommonIdentifier works I guess.Defining DDLI and then writing by it does not work on most newer ECU's. But that's a nice bypass you did. Direct read and write is available too, you just need to do security access. Title: Re: Logging with KWP-2000 protocol Post by: tao13 on March 08, 2023, 09:13:28 AM I made on arduino the kwp2000 with slowinit at 10400 and "Starting Diagnostic Development Session" with Adam help. THANKS ADAM for your code.
I tried to change log speed from 10400 ( 0x14 ) witch works ok, to 19200 (0x30), 38400 (0x50) ,57600 (0x64) but not work. Any idee? I tried withg slowinit at the same baudrate with diagnosticsession too, Not work. txBuf[0] = 0x03; // Message Length txBuf[1] = 0x10; // StartDiagnosticSession txBuf[2] = 0x86; // Development Session //0x86 txBuf[3] = 0x4D; // 38400 Title: Re: Logging with KWP-2000 protocol Post by: prj on March 08, 2023, 10:48:16 AM The response to the session is on old baudrate, only in case of positive response, do you switch to new baudrate.
"Not work" - it can not "not work". You either get positive response and switch or you get negative response. Also 0x4D is not 38400. Title: Re: Logging with KWP-2000 protocol Post by: tao13 on March 08, 2023, 02:17:18 PM Thanks PRJ, I will try to get a positive answer from ecu, sincerly i don;t exactly what i must to get from serial portbut i will try.
With baud rate i'm wrong i wrote a bad value for 38400 must be 0x50 I have your code from your few posts ago. I will try and i will inform here if i will make to work. PS : after few minutes i reedit this post; I changed the baud rate in dev session I received rxBuf[0] == 0x50 but after this i remaining in a continously loop in accessTimingParameters after made checksum. I tried to change 0x14 in 0x50 in byte 6 from accessTimingParrameters , because i thinked this is again the baudrate txBuf[0] = 0x07; //Message Length txBuf[1] = 0x83; //AccessTiming Parameters txBuf[2] = 0x03; //setTimingParametersToGivenValues txBuf[3] = 0x00; //P2min txBuf[4] = 0x01; //P2Max txBuf[5] = 0x00; //P3min //txBuf[6] = 0x14; //P3max txBuf[6] = 0x50; //P3max txBuf[7] = 0x00; //P4min First ideea was my mc33290 chip doesn't support more than 10400, but, i found in datasheet it can do 56000! Please tell me in this diagnostic development session can i find the dtc and can i delete them? PS: i tried after starting session and acces timing parameter to read dtc ReadDiagnosticTroubleCodes (0x13) and ReadDiagnosticTroubleCodesByStatus (0x18) txBuf[0] = 0x03; txBuf[1] = 0x18; txBuf[2] = 0x00; txBuf[3] = 0xFF; SendDataChksum(4); I received negative response 0x7F with 10 code - general reject for ReadDiagnosticTroubleCodesByStatus and 11 code for ReadDiagnosticTroubleCodes - not supported. The same response if i tried with only 2 bytes and with 8 bytes txBuf[0] = 0x01; txBuf[1] = 0x18; SendDataChksum(2); and txBuf[0] = 0x07; txBuf[1] = 0x18; txBuf[2] = 0x00; txBuf[3] = 0xFF; txBuf[4] = 0x00; txBuf[5] = 0x00; txBuf[6] = 0x00; txBuf[7] = 0x00; SendDataChksum( 8 ) Some advice please Title: Re: Logging with KWP-2000 protocol Post by: tao13 on March 13, 2023, 11:15:56 AM PRJ, please some help!
Let me know if ReadDiagnosticTroubleCodes works with me7.5 on KWP2000! Did i made something wrong in my code? I StartDiagnosticDevelopmentSession with byte 1 - 0x10 and byte 2 - 0x86 (Development Session). Must i initialise in other mode for read and clear dtc? Edit message AFTER 2 hours! After some search i found in Tony nefmoto software in constant definition file can work with next??? i saw i have a positive response from these command. SAEJ1979_ShowDiagnosticTroubleCodes = 0x03, SAEJ1979_ClearTroubleCodesAndStoredValues = 0x04, Edit message AFTER another 2 hours! I received positive response for serviceid 0x18 , but here......must find how substract the real dtc codes (maybe some help will be good) 58 8 1 6 68 15 23 64 6 0 64 2 38 61 6 87 61 6 0 68 1 13 62 1 18 62 Positive Res�onse to Tester Present! After another 2 hours found DTC#1 (High Byte) DTC#1 (Low Byte) statusOfDTC#1 : DTC#m (High Byte) DTC#m (Low Byte) statusOfDTC#m Now remaining to transform in real code Thanks in advance Title: Re: Logging with KWP-2000 protocol Post by: tao13 on March 14, 2023, 02:08:10 AM Something is strange. i tested on 2 ecus , different boot version.
I receive some strange bytes . With my projet (send to ecu [0x18 ; 0x00 -status ; 0x00 -high byte ; 0x00 lowbyte]) received: 11:04:56.381 -> DTCs: 11 11:04:56.413 -> 58 B 15 23 64 2 43 34 0 10 34 6 0 64 6 0 68 6 0 64 1 2 32 2 38 61 6 87 61 1 13 62 1 18 62 11:04:56.509 -> P1523 11:04:56.509 -> P0243 11:04:56.509 -> P0010 - WRONG 11:04:56.509 -> P0600 - WRONG 11:04:56.541 -> P0600 - WRONG 11:04:56.541 -> P0600 - WRONG 11:04:56.541 -> P0102 11:04:56.541 -> P0238 11:04:56.573 -> P0687 11:04:56.573 -> P0113 11:04:56.573 -> P0118 11:04:56.573 -> Positive Response to Tester Present! and with VCDS i have the same number of DTC - 11 but 3,4,5,6 DTC looks ok 11 Faults Found: 17931 - Crash Signal from Airbag Controller P1523 - 35-00 - Implausible Signal 17956 - Boost Pressure Regulation Valve (N75) P1548 - 35-10 - Open Circuit - Intermittent 17939 - Camshaft Timing Adjustment P1531 - 35-10 - Open Circuit - Intermittent 18034 - Powertrain Data Bus P1626 - 35-00 - Missing Message from TCU 18057 - Powertrain Data Bus P1649 - 35-00 - Missing Message from ABS Controller 18058 - Powertrain Data Bus P1650 - 35-00 - Missing Message from Instrument Cluster 16486 - Mass Air Flow Sensor (G70) P0102 - 35-10 - Signal too Low - Intermittent 16622 - Manifold Pressure / Boost Sensor (G31) P0238 - 35-00 - Signal too High 17071 - ECM Power Relay Control Circuit P0687 - 35-00 - Short to Plus 16497 - Intake Air Temp. Sensor (G42) P0113 - 35-00 - Signal too High 16502 - Engine Coolant Temp. Sensor (G62) P0118 - 35-00 - Signal too High Any suggestions please? PS: P0600 what i receive is ""Serial Communication Link (Data Bus) Message Missing"" , and appear when the real DTC is something like "Missing Message from " : TCU , ABS, AIBAG, but i don't know how VCDS knows interpret them , maybe use other protocol. |