Pages: 1 ... 7 8 [9] 10
Author Topic: ASM based map locator platform  (Read 42535 times)
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #120 on: June 24, 2018, 05:49:04 AM »

Hi,

I did a patch in order to support meg ecu. Fork is available here : https://github.com/jmarcgit/me7-tools
 I will do a pull request if you agree.

Anyway I'm struggling when defining some matchers. In example below I'm trying to catch 0x03AA address. Problem is there are very similar code around. There are pages of code like this. I don't think that relying on position will be reliable.

Code:
F6F5ECF9  MOV      0x0000F9EC,R5
00023216  E6F1BE03  MOV      R1,#0x03BE
0002321A  C2F41DF7  MOVBZ    RL2,0x0000F71D
0002321E  C2F5EAF9  MOVBZ    RL2,0x0000F9EA
00023222  DA060456  CALLS    0x06'0x5604
00023226  F6F5EAF9  MOV      0x0000F9EA,R5
0002322A  E6F1AA03  MOV      R1,#0x03AA
0002322E  C2F41DF7  MOVBZ    RL2,0x0000F71D
00023232  C2F5F0F9  MOVBZ    RL2,0x0000F9F0
00023236  DA060456  CALLS    0x06'0x5604
0002323A  F6F5F0F9  MOV      0x0000F9F0,R5
0002323E  E6F19203  MOV      R1,#0x0392
00023242  C2F41DF7  MOVBZ    RL2,0x0000F71D
00023246  C2F5F2F9  MOVBZ    RL2,0x0000F9F2
0002324A  DA060456  CALLS    0x06'0x5604
0002324E  F6F5F2F9  MOV      0x0000F9F2,R5
00023252  E6F18603  MOV      R1,#0x0386
00023256  C2F41DF7  MOVBZ    RL2,0x0000F71D
0002325A  C2F5F4F9  MOVBZ    RL2,0x0000F9F4
0002325E  DA060456  CALLS    0x06'0x5604
Logged
prj
Hero Member
*****

Karma: +266/-13
Offline Offline

Posts: 3358


« Reply #121 on: June 24, 2018, 03:11:11 PM »

This is abandonware for me at this point, as I just don't have time Smiley
Forking is alright, I should give someone access to the repo who wants to merge stuff and so on, if anyone is interested.
Logged
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #122 on: June 24, 2018, 04:41:50 PM »

I actually forked the nyet's fork. So I will pull my changes to him. I think nyet is still active on the project.

I know how time consuming this kind of work is. I appreciate the quality of your work.

I get great results (3 maps are already working) but I'm struggling with some maps (axes in fact) because I can't find unique matching patterns for them. I could implement a new search logic but I don't know how to solve this problem for now.
Logged
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #123 on: June 25, 2018, 04:23:01 AM »

I think I found a solution for my use case. Just look to the code below.
Code:
00054160  F6F5E682   MOV      0x000082E6,R5
00054164  F2F88087   MOV      R8,0x00008780
00054168  F6F8E882   MOV      0x000082E8,R8
0005416C  8A380170   JB       CC24.7,0x00054172
00054170  0D03       JMPR     CC_UC,0x00054178
00054172  E6F1FE0A   MOV      R1,#0x0AFE
00054176  0D02       JMPR     CC_UC,0x0005417C
00054178  E6F17E0A   MOV      R1,#0x0A7E
0005417C  F2F5E882   MOV      R5,0x000082E8
00054180  F2F43C87   MOV      R4,0x0000873C
00054184  E087       MOV      R7,#8
00054186  DA078059   CALLS    0x07'0x5980


00022DE6  F6F54E87   MOV      0x0000874E,R5
00022DEA  E6F18000   MOV      R1,#0x0080
00022DEE  C2F415F7   MOVBZ    RL2,0x0000F715
00022DF2  C2F53C87   MOVBZ    RL2,0x0000873C
00022DF6  DA07A658   CALLS    0x07'0x58A6

First block is the area processing a map. Second block is processing an axis used by the map. Map address is 0x0A7E and axis address is 0x0080. We see that the address 0x0000873C is used in both code sections.

So in order to identitfy my axis address I need first to lookup the table section, get the shared address (0x0000873C) and then process a lookup to the axis section using the shared address. I think this was discussed earlier to this discussion.

Looks very exciting and quite easy to implement.

Well I did it :

Code:
E6 F1 XX XX 0D 02 E6 F1 XX XX F2 F5 XX XX F2 F4 MMXX XX E0 87 DA XX XX XX F7 FA XX XX 8A XX XX XX 8A XX XX XX 8A|F6 F5 XX XX E6 F1 MMXX XX C2 F4 XX XX C2 F5 $$0 DA

This expression is just doing a lookup to the 0x0080 address of the above example. You can pipe as many expressions as you need. Each match can be reused in the following expressions using the $$n notation. For instance $$0 is inserting the address returned by the first expression evaluation result. I think this can support complex scenario. You can use several $$ notations in a single expression. Feedbacks are welcome. Github updated so you can test now with your own definitions.

« Last Edit: June 26, 2018, 12:46:32 AM by marcjero » Logged
nyet
Administrator
Hero Member
*****

Karma: +375/-42
Offline Offline

Posts: 8682


WWW
« Reply #124 on: June 26, 2018, 02:20:43 PM »

I actually forked the nyet's fork. So I will pull my changes to him. I think nyet is still active on the project.

I know how time consuming this kind of work is. I appreciate the quality of your work.

I get great results (3 maps are already working) but I'm struggling with some maps (axes in fact) because I can't find unique matching patterns for them. I could implement a new search logic but I don't know how to solve this problem for now.

I'm willing to maintain a canonical repo. Thanks for your PR!

https://github.com/nyetwurk/me7-tools/
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please 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 experience.
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #125 on: June 26, 2018, 02:37:56 PM »

You are welcome. This tool is amazing. And I can now lookup almost anything I need. I just have to learn the meaning of the tables. Smart MEG is using MAP when most ME ecus use MAF and german translation is not always great. Roll Eyes

I got an idea about another useful feature to add. When you have 2 similar bins with different xdfs definitions (addresses are different) it's pain to compare the tables using Tunerpro. I think it could be useful to automatically move the data from a bin to another bin when the identified addresses are different. Once done comparing or copying data in Tunerpro would be very easy because a single xdf will be required.
Logged
prj
Hero Member
*****

Karma: +266/-13
Offline Offline

Posts: 3358


« Reply #126 on: June 26, 2018, 02:41:50 PM »

Use WinOLS and that problem won't be there Smiley
For comparing you can use the demo and newer versions of OLS have xdf import.
Logged
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #127 on: June 26, 2018, 03:35:55 PM »

nice to know.

btw I have an idea about the design:
-define a second optional file field (call the first one master bin file)
-so when analysis is run : the 2 files can be processed at the same time and results are displayed using 2 columns
-when xdf export is run : it only applies to the master file
-when 2 files are selected, a "migrate data" button is enabled. When clicking to this button : a copy of the master file is done and then data from the second file are copied into the copy of the master file (simple address translation affair)

It's just a general design idea. Does it make sense for non winols users ?





Logged
nyet
Administrator
Hero Member
*****

Karma: +375/-42
Offline Offline

Posts: 8682


WWW
« Reply #128 on: June 26, 2018, 04:06:09 PM »

Does it make sense for non winols users ?

Just about everything OLS does that TunerPro doesn't would be useful, IMO. Most would say "just use OLS" but it would be nice if more things could be done without it.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please 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 experience.
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #129 on: June 26, 2018, 11:45:54 PM »

Just about everything OLS does that TunerPro doesn't would be useful, IMO. Most would say "just use OLS" but it would be nice if more things could be done without it.

Yes winols cost is about 1000$ and tunerpro is free, so it's not surprising to learn that winols is vastly superior.
 What do you think about my design proposal ?
Logged
nyet
Administrator
Hero Member
*****

Karma: +375/-42
Offline Offline

Posts: 8682


WWW
« Reply #130 on: June 27, 2018, 12:44:34 AM »

Yes winols cost is about 1000$ and tunerpro is free, so it's not surprising to learn that winols is vastly superior.
 What do you think about my design proposal ?

Yes, but I think it should be a separate tool.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please 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 experience.
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #131 on: June 27, 2018, 02:29:45 AM »

Yes it can be a different tool. It can be based on XDF files. I think it will be better then is to use the XML ids as XDF tables uniqueIds.(instead of addresses)
A single tool would make things simpler for users but will be harder to maintain.
Logged
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #132 on: July 01, 2018, 01:25:23 PM »

Hi,

I'm very confused about the content of the MEG 1.1 ECU. It looks like that most tables and axis are duplicated and available in 2 areas : The first one starts at 0x10000 and the second one starts at 0x18000
For instance the KZFW table offset is 0x2150. I was thinking  the address was 12150 but it happens that 1A150 is working too. Both adresses are containing the same data.

This happens for MEG1.1 bin files only. For MEG1.0 the 0x18000 region is empty. Do you know why these data are duplicated ?

Logged
prj
Hero Member
*****

Karma: +266/-13
Offline Offline

Posts: 3358


« Reply #133 on: July 01, 2018, 01:53:49 PM »

Because same ECU is used for 2 different cars, for example auto/manual and instead of only switching a few maps the entire cal area is duplicated, and the switch is done using DPP.
Logged
marcjero
Jr. Member
**

Karma: +0/-0
Offline Offline

Posts: 36


« Reply #134 on: July 01, 2018, 03:18:35 PM »

I guess then the 0x18000 are is for the Roadster and the 0x10000 area is for the Fortwo. Thanks.
Logged
Pages: 1 ... 7 8 [9] 10
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.022 seconds with 18 queries. (Pretty URLs adds 0.001s, 0q)