NefMoto

Hi All,

I posted this in Noobs but it may be better off here. I am using Testo/ediabas to log data for my mini. However I am only getting 1 data set per second, which is terrible! I have the K+DCan cable and am happy enough using it but I just wanted to get faster logging speed.

I have read about RAM reading. Or even a RAM routine that outputs data on the Kline, but could never get more info on it, so any help would be much appreciated please.

This is a VAG focused forum, I doubt you will get much help here,  I dont know how many meddled with that car/ecu.
Might better off posting in a general tuning forum I guess.

It's a total wasteland out there; this is the only forum I know of that has anything about DIY logging

You need to reverse the comm stack and see if there is something that outputs data faster.
It's probably KWP2000, you need to check which services are active.

If it has e.g. $2C then you can use $2C for fast data transfer.

It is possible it only has $21 and running a slow ass baud rate on top of that. Well then there's not much you can do apart from rolling your own logic in the ECU.

I think it does use KWP but could only find reference to that in this http://wiki.bavariantechnic.com/index.php?title=EMS2K so 9600 baud which isn't ideal and only clear adaptations seem to be supported.

I posted in the noob bit first as although I'm fairly savvy I'm still getting my head around aspects like $2C or $21, what they are what they do how they function etc.

Im willing to try and learn whatever, even custom ECU code, just need some help to get started really.

If you were savvy you would have looked up the standards, found their ISO documents and started reading.

If even doing this is too difficult, then you can forget about getting anything done.
The learning curve is pretty brutal on this, you better be pretty good with at least programming/software development. RE knowledge comes in handy too.

Right, so its been a while since i started this and started posting.

I am struggling to find anything on the standard BMW communication area and the code in IDA which controls this - so i am currently struggling to modify an exist telegram response.

What i am trying however, is to copy data from certain RAM addresses, such as pedal, STFT, RPM etc, into other empty addresses so i can use the Read Memory tool in Tool32 to then read all of these items in one request - therefore higher response time.

I have modified a subroutine with a jmps to the location, and this is what i have so far, but i cannot work out why it is not responding or changing anything? i guess i need to find a sub that runs on repeat and place this code in the middle rather than the end?

Any advice would be much appreciated please:

PS i have no reference material other than C167UM and ISM to go by - nothing BMW/SiemensVDO related.

loc_58F12:                              ; CODE XREF: sub_2DB1A:loc_2F260↑J
58F12                 mov     r9, Engine_RPM_LSB
58F16                 mov     word_C994, r9
58F1A                 mov     r8, Engine_RPM_MSB
58F1E                 mov     word_C996, r8
58F22                 mov     r9, STFT_LSB
58F26                 mov     word_C998, r9
58F2A                 mov     r8, STFT_MSB
58F2E                 mov     word_C99A, r8
58F32                 mov     r9, Air_Mass_MSB
58F36                 mov     word_C99C, r9
58F3A                 mov     r8, Air_Mass_LSB
58F3E                 mov     word_C99E, r8
58F42                 mov     r9, Pedal_Position
58F46                 mov     word_C9A0, r9
58F4A                 mov     r8, Maybe_Throttle_Angle
58F4E                 mov     word_C9A2, r8
58F52                 mov     r8, [r0+]
58F54                 mov     r6, [r0+]
58F56                 jmps    2, loc_2F264

Thanks!

Why do you think you need to do this though?

Have you looked at:
1. What comms standard it uses?
2. Which services are available on this standard?

Why are you editing random asm code, chances are you don't need to touch the ECU at all and it's enough to write a tool that will pull all the info and very quickly.

So I have the BMW standard programs such as tool32 and using TestO for pulling data, which works fine. Fairly sure it uses BMW-FAST but not sure, a request is as follows:

STATUS_IO_ENGINE1
status_lid_10             = B8,13,F7,02,21,10

;STATUS_ANA_ENGINE2
;STATUS_IO_ENGINE2
status_lid_11             = B8,13,F7,02,21,11

;STATUS_ANA_ENGINE3
status_lid_12             = B8,13,F7,02,21,12

;STATUS_ANA_ENGINE4
status_lid_13             = B8,13,F7,02,21,13

;STATUS_ANA_ENGINE5
status_lid_14             = B8,13,F7,02,21,14

;STATUS_ANA_O2_HEATER
status_lid_15             = B8,13,F7,02,21,15

;STATUS_ANA_ENGINE7
status_lid_16             = B8,13,F7,02,21,16

;STATUS_ANA_FUEL_TRIM
status_lid_17             = B8,13,F7,02,21,17

;STATUS_ANA_ENGINE9
status_lid_18             = B8,13,F7,02,21,18

;STATUS_ANA_INJ_TIME
status_lid_19             = B8,13,F7,02,21,19

;STATUS_ANA_EWS
;STATUS_IO_EWS
status_lid_20             = B8,13,F7,02,21,20

;STATUS_ANA_MAN_TEST
;STATUS_IO_MAN_TEST
status_lid_21             = B8,13,F7,02,21,21

Certain requests are great at getting some data, but nothing as an all-in-one solution. I.e. if I want Air mass, STFT and pedal position, that's 3 different calls, (engine 4, engine 7 and Fuel Trim) so getting back responses every 1 or 2 seconds which isnt ideal.

I cannot find any documentation on the BMW usage of the SiemensVDO unit with the C167 chip, so cannot find where the responses come from in the program, but have identified a lot of the locations of the data in RAM which is accessible with a standard BMW request.  Ideally I could customise one of those responses to pull back what I want, rather than the original request. But again struggling to locate this in the code.

Sent from my VOG-L09 using Tapatalk

So the answer is you know nothing about the underlying protocol, the BMW stack abstracts everything for you.
To get anywhere, you need to learn about diagnostic protocols.

What you're doing now is a waste of time and you won't ever get anywhere.

1. Write your own tool that uses either a J2534 interface or a KKL interface and establish comms. Most likely the comms stack is ISO14230-3 over ISO14230-1 (KWP over K).
2. Find the service distributor in the ECU and see which services are implemented.
3. Learn how these services work and how to request data.

Only after you have accomplished this and made 100% sure that it is not possible to have rapid data transfer (which I've never seen be the case with BMW), should you go into the ECU and try to patch some kind of services.

If you disregard this advice you will fail.
If you do not have a strong programming background you will also fail.

Chances are there's also a way to pull the data through EDIABAS. That takes someone who has a clue about protocols about 5 minutes to find out.
Long story short, get the ISO docs and start learning and stop posting until you have. Otherwise it is impossible to offer any advice.

Ok, thanks for the brutal advice.

Regarding advice for now then whilst I read, is there any you can give for your point 2)? A particular set of instructions that I can look for to identify this area?

I'll read up on the ISO standards, but finding info on the ECU code is the difficult part...

Sent from my VOG-L09 using Tapatalk

So I can see by the KWP standard that this uses the 21 service to request each of those Status requests which give information set by BMW.

What I can do, potentially, is use the 2C service to define/change an identifier to give me the information that I want in the same way BMW would?

To do this I need to find that service section of the ECU to make sure that is fully supported?

I'll be honest making my own tool would be a stretch right now, but I know RomRaider has that capability so I will look into that.

Apologies for being a noob at this but it's why I'm asking as for the mini there's very limited info. I am very willing to learn though.

Sent from my VOG-L09 using Tapatalk

You need to do it in this exact order.
Services will mean very little to you if you do not have a tool capable of using them.

Besides, you do not even need 2. You can just do 1. and then test which services are available.
Your starting point is studying the ISO standards.

$2C if available instantly solves all your issues.
Even $21 if the ECU supports fast baudrate will run very fast.
$21 in some BMW implementations can (breaking the spec) accept multiple parameters. If it does not, and there is no other way, it can be patched to do this.
$2C BMW has also often their own idea of using etc.

But as I said before, none of this is "forum asking" material. If you continuously refuse to read and use the specifications, you will not get very far.

So i managed to use the Tool32 software and an EMS2K/TMode PRG to send telegrams to the ECU - i can get responses to KWP commands the same was the normal PRG does, $21 and $23 work great, however when trying $2C i get an 7F 2C 12 error.

I believe means that using 2C is not available for this ECU (subFunctionNotSupported?) however some places show the error as invalid format? I tried using the 2C xx 04 command but got the same response. Unsure if its a security type issues, I also tried this in various levels of diagnostic mode & seed key access - is there a specific one that need to be used please? BMW gives seeds for: 1 = breakdown, 3 = dealer, 5 = End of line, 7 = programming, 9 = development; and Diagnostic Modes for 0x81=Standard, 0x83=EOL, 0x86=Development, 0x85=Programming at 9.6k, 0xFF=Programming at 62.5k;  The main ones i tried were 7 & 9 and 85 & 86.

I noticed using the PRG that the initialiserung job sets the baud at 9.6k, i changed the code to 10400 and it still works, but can't get a decent response when using 3+ LID requests.

Additionally I tried using $21 with extra parameters however no response each time.

So does this mean next steps are to either modify current LIDs (which i believe are stored in RAM but i found code in IDA which seems to list the RAM locations of those values, attempted to modify but made no difference and cannot find a reference to those tables in any functions)
or to patch the way the data is delivered?

If $2C was not supported you would get 0x11 most likely and not 0x12.

That's what i thought given $2C is a service not a sub function and as i said some places show it as an input issue - could it be the way i am trying to assign the LIDs? I am using 03 for RAM due to knowing where the values are, but it still provides an error.

What i am entering is B8 13 F7 08 2C 25 03 01 01 00 C4 50 for the 1 byte pedal position value held at #00C450

What may/may not also be weird is when going through the LIDs, so 21 00, 21 01 etc i get error 12 for 21 1A - so does this mean my initial error 12 is due to the inputs i am providing and not the lack of ability to do it?

is there a way of identifying the CommonIdentifier and LocalIdentifiers that already exist to try instead of RAM?

So i got it working! for some reason F0 is the only location i found that allows code to be written to? and it needs to be done in one go after starting a diagnosticSession FF.

So thanks everyone for the help, now just need to play with the parameters i want to log to find the best way!

Hello
If I understand the protocol and KPW correctly but with a different baud rate?
I would like to communicate with to make a logger but based on a microcontroller
for the moment I use the 9141-2 protocol but this one is much too slow

here is the data that goes through the K-LIN cable during a log with special software for the Mini to be able to log

init
TX: B8 13 F7 02 21 18 67
RX: B8 F7 13 0C 61 18 64 00 00 00 00 00 00 00 00 00 4D
TX: B8 13 F7 02 21 14 6B
RX: B8 F7 13 10 61 14 00 00 00 00 0C 0C 00 00 00 7A 7A 7A 7A FF C6
TX: B8 13 F7 02 21 13 6C
RX: B8 F7 13 1A 61 13 65 54 5E 2B 5E 2A 00 32 00 05 10 41 10 B1 10 00 00 00 00 53 00 53 64 64 D3
TX: B8 13 F7 02 21 17 68
RX: B8 F7 13 0E 61 17 00 00 00 00 00 1C 00 1B 33 33 00 00 23
TX: B8 13 F7 02 21 18 67
loop....

I think there is software that already does this, search for x4code.