|
prj
|
 |
« Reply #2220 on: March 13, 2023, 03:56:51 AM »
|
|
|
I made a visual basic macro in excel to extract four bytes from each subroutine.
When the first two bytes are C2 F4, I calculate the RAM address from the next two.
This is done by extracting and removing the DPP number from the two address bytes.
(The two highest bits in the two-byte address if I remember correctly. C167 can be a bit annoying.)
Most will have DPP number 2 and some DPP number 3.
DPP2 is probably 0xC0. 0xC0 multiplied with 0x4000 is 0x300000
DPP3 is probably 0x03. 0x03 multiplied with 0x4000 is 0xC000
You then add 0x300000 to the remaining address (lowest 14 bits) for the values using DPP2, and 0xC000 for the ones using DPP3.
This should give you addresses like 30xxxx and Fxxx.
96FB: 1011 0000 0001 0110 1111 1011
DPP: 10 = 2
16FB: 0011 0000 0001 0110 1111 1011
Assuming DPP2=C0: 16FB+300000=3016FB Why not go one step further and since the DID's are going to mean the same thing across softwares, make a map between DID <-> A2L RAM ID on known software, and then you have these ram cells on every ECU? Btw, this is the same thing ME7Info does for ME7Logger, just much less advanced. |
|
|
|
|
Logged
|
|
|
|
rkam
Full Member
Karma: +4/-0
 Offline
Posts: 55
|
|
« Reply #2221 on: March 13, 2023, 04:15:04 AM »
|
|
|
I believe there could be some difference between models and years, so I would normally link to data for the actual units diagnose part number in Vida SQL tables.
But I have converted the A2L I have to excel, and on some old hard drive in my house I believe there is a spreadsheet comparing data from both A2L and Vida or DHA.
|
|
|
|
|
Logged
|
|
|
|
rlinewiz
Jr. Member
Karma: +12/-1
Offline
Posts: 42
|
|
« Reply #2222 on: March 13, 2023, 06:03:06 AM »
|
|
|
I made a visual basic macro in excel to extract four bytes from each subroutine.
When the first two bytes are C2 F4, I calculate the RAM address from the next two.
This is done by extracting and removing the DPP number from the two address bytes.
(The two highest bits in the two-byte address if I remember correctly. C167 can be a bit annoying.)
Most will have DPP number 2 and some DPP number 3.
DPP2 is probably 0xC0. 0xC0 multiplied with 0x4000 is 0x300000
DPP3 is probably 0x03. 0x03 multiplied with 0x4000 is 0xC000
You then add 0x300000 to the remaining address (lowest 14 bits) for the values using DPP2, and 0xC000 for the ones using DPP3.
This should give you addresses like 30xxxx and Fxxx.
96FB: 1011 0000 0001 0110 1111 1011
DPP: 10 = 2
16FB: 0011 0000 0001 0110 1111 1011
Assuming DPP2=C0: 16FB+300000=3016FB
yes I always have set DPP properly, and started ignoring what IDA is saying and converting from the hex directly. I got about 600 variables before giving up and starting to write a simple .NET app to do it for me, much like your method but also taking into account the bitwise operations, and duplicate variables with differing masks. i realize this sort of work will not help the end user, but will be very helpful reference for anyone wanting to edit the bin assembly [edit] i noticed the code analysis is setting DPP2 to random values in weird places, even though its set properly at the top, so at the beginning of these functions i forced DPP2 back to C0 and all the ram values lined up properly [edit edit] also anyone else who is trying to figure this out at such a low level, do note that any time you see an 'extp' before a lookup, it changes DPP2 for the next instruction. #0C1h sets DPP2 to 0x304000, #0C2h sets DPP2 to 0x308000. This allows lookups into the 305000 and 30A000 ranges |
|
|
|
« Last Edit: March 13, 2023, 10:13:19 AM by rlinewiz »
|
Logged
|
2005 S60R M66-Swapped // Self-tuned @ 22psi
[[forever coding for the OpenMoose project]]
|
|
|
|
prj
|
|
« Reply #2223 on: March 13, 2023, 08:35:48 AM »
|
|
|
I believe there could be some difference between models and years, so I would normally link to data for the actual units diagnose part number in Vida SQL tables.
But I have converted the A2L I have to excel, and on some old hard drive in my house I believe there is a spreadsheet comparing data from both A2L and Vida or DHA. VIDA is completely irrelevant in this case. You know that identifier X is RAM ID Y. All you need is a single A2L. Then you can map at least some RAM IDs on every other ECU from same family. Regardless, I did get C167 to work in my generator tool... Seems like I will have to implement the Volvo specific protocol anyway for ME9 P01, and it should work for ME7 too. But probably free protocol like on ME7 isn't going to happen, since I'd still need to add defs for every single ECU by hand... So not sure there is much point to even bother with ME7, since you guys got most of the ME7 ECU's already very well covered with an opensource tool. Getting my ECU's tomorrow finally, so going to start working on them... |
|
|
|
|
Logged
|
|
|
|
rkam
Full Member
Karma: +4/-0
Offline
Posts: 55
|
|
« Reply #2224 on: March 13, 2023, 11:31:22 AM »
|
|
|
I have only one A2L for ME7 file F1EBI.bin
This is variant 288 in Vida and it has quite a few identifiers that differ from the 1753 variant for QKHJ.
54 08644074 G
55 08644074 H
67 08658507 G
68 08658507 H
145 08689198 A
205 09202858 A
206 09202903 A
207 09202904 A
253 09488048 A
272 09496652 A
273 09496653 A
274 09496654 A
275 09496656 C
288 09497085 A F1EB1.bin A2L
292 09497803 A
293 09497804 A
294 09497805 A
348 30641539 B
349 30641540 B
350 30641541 B
351 30641542 B
352 30641543 B
353 30641543 H
354 30641735 B
356 30641745 B
357 30641745 H
358 30641746 B
359 30641746 H
360 30641841 B
374 30651320 B
375 30651321 B
379 30653031 B
380 30653032 B
454 30668566 A
659 30743290 AA
897 30771311 AA
1370 30785372 AB
1371 30785373 AB
1375 30785374 AB
1379 30785375 AB
1383 30785376 AB
1390 30785377 AB
1391 30785378 AB
1449 31219132 AA
1453 31219133 AA
1749 31219525 AA
1751 31219526 AA
1752 31219527 AA
1753 31219528 AA QKHJ
1754 31219529 AA
1668 31219530 AA
I haven't check the A2L yet.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2225 on: March 13, 2023, 06:06:37 PM »
|
|
|
I have the same A2L. The format is so old, that my A2L parser is not even able to process it... EDIT: Parser now processes it, but my disassembler chokes on it  I wanted to generate from F1EBI -> QKHJ for lulz and see what's going on. I know there's some 1mb A2L's around too. |
|
|
|
« Last Edit: March 13, 2023, 06:14:38 PM by prj »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2226 on: March 13, 2023, 06:58:03 PM »
|
|
|
Managed to get it to parse, but I think I need to find a 1mb A2L. The 512k is quite different, here's the result, I'm sure tons of them are wrong. [03:55:22] ######## SOURCE BIN ########
[03:55:22] Loading and parsing files...
[03:55:22] Removing bitfields...
[03:55:22] Code segments:
[03:55:22] 008000 - 0089BA Len: 0009BB
[03:55:22] 009000 - 00C229 Len: 00322A
[03:55:22] 022000 - 035DC6 Len: 013DC7
[03:55:22] 035E00 - 07C69E Len: 04689F
[03:55:22] DPP0: 0x0004
[03:55:22] DPP1: 0x0005
[03:55:22] DPP2: 0x00C0
[03:55:22] DPP3: 0x0003
[03:55:22] Parsing instructions...
[03:55:24] Got 7450 refs
[03:55:24] Matching refs to A2L...
[03:55:24] A2L addresses: 5357, with refs: 2285
[03:55:24] ######## TARGET BIN ########
[03:55:24] Code segments:
[03:55:24] 009000 - 00C3CB Len: 0033CC
[03:55:24] 030000 - 036CB0 Len: 006CB1
[03:55:24] 038000 - 0C46E2 Len: 08C6E3
[03:55:24] DPP0: 0x0004
[03:55:24] DPP1: 0x0005
[03:55:24] DPP2: 0x00C0
[03:55:24] DPP3: 0x0003
[03:55:24] Parsing instructions...
[03:55:27] Got 11937 refs
[03:55:27] ######## MATCHING ########
[03:55:27] Found 0 derived references via COPYTRACK in SOURCE.
[03:55:27] Found 0 derived references via COPYTRACK in TARGET.
[03:55:27] Total refs to match - Source: 32730 Target: 55913
[03:55:27] Running REFMATCH: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
[03:55:49] Matched 16693 references.
[03:55:49] Conflict resolution...OK
[03:55:49] cnt 246
[03:55:49] instrsum 187
[03:55:49] discard 25
[03:55:49] doublerefs 97
[03:55:49]
[03:55:49] Matched 1553 addresses via REFMATCH, out of them 564 single.
[03:55:49] Array fill... OK, Got 0 addresses.
[03:55:49] Fill...
[03:55:49] Matched 460 addresses via FILL.
[03:55:49] Total matches: 2013
[03:55:49] 2/2025 with same address.
[03:55:49] Writing ECU file: C:\Tuning\Tools\tsunami\ecus\tmp\70195Q8Z.ecu
[03:55:49] Writing ADR file: C:\Tuning\Tools\tsunami\ecus\tmp\70195Q8Z.adr
[03:55:49] Writing GEN file: C:\Tuning\Tools\tsunami\ecus\tmp\70195Q8Z.gen
[03:55:49] FINISHED, time: 00:00:26 |
|
|
|
|
Logged
|
|
|
|
rkam
Full Member
Karma: +4/-0
Offline
Posts: 55
|
|
« Reply #2227 on: March 14, 2023, 12:56:17 PM »
|
|
|
Linking A2L RAM addresses to the ones found through identifier table I get some strange result.
F1EBI.bin contains DiagID 09497085, but the identifier names fit the Vida tables with DiagID 31219528 and NOT 09497085.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #2228 on: March 14, 2023, 02:12:20 PM »
|
|
|
So V50 ME9 ECU only replies to a few services on KWP.
You can read and clear DTC, that's it. This is also seen in the service table, as there's those services and the rest is OBD services.
Everything else is on Volcano, so have to implement that crap.
There's also $1A, but it only responds a couple things:
0080: [ME(D)9] 5A 80 4D 45 28 44 29 39
0081: [f] 5A 81 03 97 66 FF
0097: [ME(D)9] 5A 97 4D 45 28 44 29 39
|
|
|
|
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #2229 on: March 16, 2023, 02:53:36 AM »
|
|
|
|
|
|
|
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #2230 on: March 16, 2023, 10:05:12 AM »
|
|
|
New version of VolvoTools. Added Mongoose JLR support. https://cloud.mail.ru/public/qHDs/RBR5724k3Moreover logger supports j2534 devices with one CAN on 6-14 pins. Flasher wants second CAN to shutdown ECUs on slow network CAN. Maybe it can be ignored if it can't open second. I'm not sure. P1 ME9 also should be supported. |
|
|
|
« Last Edit: March 16, 2023, 11:04:18 AM by prometey1982 »
|
Logged
|
|
|
|
|
prometey1982
|
|
« Reply #2231 on: March 18, 2023, 07:34:50 AM »
|
|
|
New version of VolvoTools. Added Mongoose JLR support. https://cloud.mail.ru/public/qHDs/RBR5724k3Moreover logger supports j2534 devices with one CAN on 6-14 pins. Flasher wants second CAN to shutdown ECUs on slow network CAN. Maybe it can be ignored if it can't open second. I'm not sure. P1 ME9 also should be supported. P1 doesn't support. But now should be supported all j2534 devices. Checked on DiCE, MongoosePro JLR and Openport 2.0. |
|
|
|
|
Logged
|
|
|
|
rlinewiz
Jr. Member
Karma: +12/-1
Offline
Posts: 42
|
|
« Reply #2232 on: March 19, 2023, 09:30:29 AM »
|
|
|
here's a map of all the A6 identifier - RAM variables for GPHJ
|
|
|
|
« Last Edit: March 19, 2023, 12:26:57 PM by rlinewiz »
|
Logged
|
2005 S60R M66-Swapped // Self-tuned @ 22psi
[[forever coding for the OpenMoose project]]
|
|
|
|
prj
|
|
« Reply #2233 on: March 19, 2023, 10:05:50 AM »
|
|
|
here's a map of all the RAM variables for GPHJ
Many of them, you could say most of them, but not all. Is all that stuff in the A6 table? I've not looked at Volvo ME7 before. If it is, I can write an autoparser and make a free protocol for Volvo ME7 as well. ME9 is done now, both P01 and P02, but that's not free. EDIT: Looked at it, and e.g. KR is missing. So detectors for some other stuff need to be written. Other than that, it's possible to make a ME7Info type thing. |
|
|
|
« Last Edit: March 19, 2023, 11:59:36 AM by prj »
|
Logged
|
|
|
|
rlinewiz
Jr. Member
Karma: +12/-1
Offline
Posts: 42
|
|
« Reply #2234 on: March 19, 2023, 12:26:35 PM »
|
|
|
yes its the entire A6 table taken from VIDA, if theres something missing its because there is no A6 lookup for it, certainly everything in the 6000C subroutine is used
|
|
|
|
|
Logged
|
2005 S60R M66-Swapped // Self-tuned @ 22psi
[[forever coding for the OpenMoose project]]
|
|
|
|
