marcjero
Full Member
Karma: +4/-1
 Offline
Posts: 60
|
 |
« 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. 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
|
|
« 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  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
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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. 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 : 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
|
|
« 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 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
|
|
|
marcjero
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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.  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
|
|
« Reply #126 on: June 26, 2018, 02:41:50 PM »
|
|
|
Use WinOLS and that problem won't be there For comparing you can use the demo and newer versions of OLS have xdf import. |
|
|
|
|
Logged
|
|
|
|
marcjero
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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
|
|
« 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 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
|
|
|
marcjero
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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
|
|
« 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 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
|
|
|
marcjero
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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
|
|
« 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
Full Member
Karma: +4/-1
Offline
Posts: 60
|
|
« 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
|
|
|
|
|
