|
elRey
|
 |
« Reply #60 on: May 06, 2017, 08:55:46 PM »
|
|
|
edit: my post may violate license of me7logger. removing it for now.
|
|
|
|
« Last Edit: May 07, 2017, 04:04:38 PM by elRey »
|
Logged
|
|
|
|
de_F
Newbie
Karma: +13/-0
 Offline
Posts: 22
|
|
« Reply #61 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 ? |
|
|
|
« Last Edit: November 03, 2018, 01:00:37 PM by de_F »
|
Logged
|
|
|
|
kuebk
Jr. Member
Karma: +3/-0
Offline
Posts: 47
|
|
« Reply #62 on: November 01, 2018, 01:55:36 AM »
|
|
|
Memory regions are covered in detail in A2L.
|
|
|
|
|
Logged
|
VAG immo solutions (clone, immo off, repair) MEDC17, SIMOS, SDI, BCM2, ELV, DQ/DL/VL gearboxes, INVCON, MED9.x crypto
|
|
|
de_F
Newbie
Karma: +13/-0
Offline
Posts: 22
|
|
« Reply #63 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.
|
|
|
|
|
Logged
|
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #64 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.
|
|
|
|
« Last Edit: May 27, 2021, 08:25:32 AM by OZZIE1 »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #65 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.
|
|
|
|
|
Logged
|
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #66 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.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #67 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
|
|
|
|
|
Logged
|
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #68 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.
|
|
|
|
« Last Edit: May 31, 2021, 06:19:57 AM by OZZIE1 »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #69 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.
|
|
|
|
« Last Edit: May 31, 2021, 09:55:11 AM by prj »
|
Logged
|
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #70 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.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #71 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.
|
|
|
|
« Last Edit: June 01, 2021, 01:07:54 PM by prj »
|
Logged
|
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #72 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.
|
|
|
|
|
Logged
|
|
|
|
R32Dude
Full Member
Karma: +45/-10
Offline
Posts: 248
|
|
« Reply #73 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.
|
|
|
|
« Last Edit: June 09, 2021, 08:06:36 AM by OZZIE1 »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #74 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?  |
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
