|
gt-innovation
|
 |
« Reply #105 on: November 19, 2016, 03:32:59 AM »
|
|
|
Hi guys,
I have t two tunes that Daz did for me , one for petrol and one for E85. Can somebody help me merging the two together? Feel free to PM
What is that have to do with the multimap thread? Moreover i find offensive the use of ddillinger's name to ask for help.do you see anyone giving out for free that kind of service?sorry if i am beeing rude but search the forum as all the info is here...Philadot has a code released for that and you did not even bother to check...Use the search button on the forum. |
|
|
|
|
Logged
|
|
|
|
|
_nameless
|
|
« Reply #106 on: November 19, 2016, 04:36:19 AM »
|
|
|
What is that have to do with the multimap thread? Moreover i find offensive the use of ddillinger's name to ask for help.do you see anyone giving out for free that kind of service?sorry if i am beeing rude but search the forum as all the info is here...Philadot has a code released for that and you did not even bother to check...Use the search button on the forum.
I wouldn't even waste my time with a response. |
|
|
|
|
Logged
|
If you are in the market for a tune and would like the ease of downloading and flashing a dyno tested tune for a fair price check out https://instatune.sellfy.store/ |
|
|
|
nubcake
|
|
« Reply #107 on: December 05, 2016, 02:41:18 PM »
|
|
|
Hi guys,
I have t two tunes that Daz did for me , one for petrol and one for E85. Can somebody help me merging the two together? Feel free to PM
Hi. If you still need it - I can do that for you, but it won't be free. What car do you have? Can you flash/log the car on your own? Are you familiar with bootmode flashing? |
|
|
|
|
Logged
|
|
|
|
Khendal
Full Member
Karma: +9/-8
 Offline
Posts: 226
|
|
« Reply #108 on: December 08, 2016, 03:31:11 PM »
|
|
|
So i am trying to port this code to the 1.8T in my Cupra BAM with sw number 362999
So far i came up with the following..
s4 code uses the following functions i matched them with ida with my own.
S4 Cupra
FD86.2 : S_fgrsv FD6C.12
FDF2.5 : FDD2.5
FD86.3 : S_fgrwb FD6C.13
FD22.0 : B_Mil FD24.0
Fd22.1 : Ecpl FD24.1
FDB0.1 : B_stend FD9A.1
FD4E.11 : FD44.6
FD9A.13 B_st FD84.7
byte_F9B3 : wkrma byte_F9D5
I think i also found all the calls for krkte - lamfa etc and figured out the way that Philadot is calculating the address table.
I also found out that there is not enough space for all the mapsets in the same memory location that is free on all s4 me7 but my main problem is that when i press the set button ecu seems to reboot while car is working..stalling for 1 sec and then is back up again...Is there any difference in the memory stack that causes this problem ? how can i figure out what is causing this since if i am logged with me7logger the session stops also..
Has anyone else tried to port this code to his own 1.8T ?
I have also a Cupra 225 BAM i'm new here and new about ecu tuning... have you found some info about this car? have you a xdf file? any advice?  |
|
|
|
|
Logged
|
|
|
|
|
IamwhoIam
|
|
« Reply #109 on: December 09, 2016, 01:30:09 AM »
|
|
|
LULZ
|
|
|
|
|
Logged
|
I have no logs because I have a boost gauge (makes things easier)
|
|
|
trichard3000
Full Member
Karma: +6/-1
Offline
Posts: 57
|
|
« Reply #110 on: June 29, 2017, 09:47:07 PM »
|
|
|
Is there a memory location (or set of locations) I can access via logging that shows the active value(s) for things that get re-mapped in this bin?
For example, if I can read one or more of the currently active LDRXN values (and these are different between map sets) then I can programmatically detect which map set is currently active.
I've been away for a while but I'm finally swapping my Green Giant injectors for EV14s and I'm revisiting this multi-map file. I've been using it happily for a few years now! :-)
Thanks for any help or info anyone can provide!
Edit: removed a comment about using xdf memory locations because I realized the difference between offsets in the bin file and actual RAM locations. :-)
|
|
|
|
« Last Edit: June 29, 2017, 10:23:41 PM by trichard3000 »
|
Logged
|
|
|
|
trichard3000
Full Member
Karma: +6/-1
Offline
Posts: 57
|
|
« Reply #111 on: July 11, 2017, 06:30:04 PM »
|
|
|
I tried to do some RAM dumps using my old python code but I'm running in to some issues (mainly do to with having little-to-no idea what I'm doing). :-)
I haven't found LDRXN maps copied straight in to RAM anywhere yet but I also can't seem to access all of RAM yet, either. Can someone confirm that I'm at least looking for something that should exist? Or do I need some IDA Pro wizardry to even have a shot at this?
Really what I'm looking for is the ability to log the RAM location that tells the MIL how many times to blink. in a perfect world, there's also a place to write a byte (or a few) directly and change maps bypassing the whole check for 0mph/clutch/stalk selector.
I'd be happy just to know the selected map set in my logs, though. Anyone out there know if this is theoretically possible with this bin?
Thanks!
|
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #112 on: July 12, 2017, 04:45:07 AM »
|
|
|
Really what I'm looking for is the ability to log the RAM location that tells the MIL how many times to blink.
try 0x383F42, I think this was the ram location for map number in Mbox. Don't know if Philadot has used different locations on different files. You can add this adress to me7logger and make sure to set offset to 0 and factor to 1 |
|
|
|
|
Logged
|
|
|
|
trichard3000
Full Member
Karma: +6/-1
Offline
Posts: 57
|
|
« Reply #113 on: July 12, 2017, 07:40:52 AM »
|
|
|
try 0x383F42 Thanks! I'm using an M box anyway so all good there. On my bench rig this address returns a value of 1, so far so good. My car is somewhat taken apart at the moment so as soon as I get it up to to point where I can do map selection, I'll give this a test. Any idea if there's a RAM location(s) to write to (with checksums, I assume) from a KWP2000 session that causes all the maps to adjust accordingly? I imagine there's a place in Phila_dot's routine that can be poked. My thinking is along the lines of: With an embedded computer, the car can watch for things like empty water/meth reservoir and back off to a safer tune. Or simply allow the user to do map set changes from a GUI instead of the stalk. Again, I'm very happy for the above info! Thanks again for your help! |
|
|
|
|
Logged
|
|
|
|
TijnCU
Hero Member
Karma: +60/-4
Offline
Posts: 690
flying brick
|
|
« Reply #114 on: July 12, 2017, 12:39:21 PM »
|
|
|
The switching routine is just using a batch of preset values in ram that point to the corresponding maps, the function is switched by conditions like clutch + cruise switch. If you are thinking about embedding some gui you should be more than capable of writing your own routines. I wouldnt know how to write to ram by just using kpw protocols, this would be much more complex than actual coding changes like these map switching functions. I am sure that if you really grasp how this would be done, you would not have asked for a simple ram adress that is easy to locate in a disassembly. No hard feelings for as far as implementing your idea: just writing 0,1or 2 to 0x383F42 should be sufficient to have all the maps switch over to the corresponding set. In my opinion it is easier to write these safety monitoring functions you suggest in this actual ecu by using voltage signals. No need for external computers at all and you can keep full switching functionality aside from safety maps. |
|
|
|
|
Logged
|
|
|
|
trichard3000
Full Member
Karma: +6/-1
Offline
Posts: 57
|
|
« Reply #115 on: July 12, 2017, 07:18:06 PM »
|
|
|
Understood on all counts. I don't have IDA Pro and I haven't found another way to do dissembly without it. Plus it's been a long time since I've done any assembly code (6502!) I'd probably be able to hack my way through it but since I'm just an amateur, I have a hard time justifying 20% the cost of my car just for hacking. :-)
Instead, I'm going the other way. I'm limiting myself to what I can do externally with Python. The GUI I'm talking about would be hosted on an external device. Think of something like a OBD tester but with persistent logging and some extra features to help with tuning, etc. I'm using a Raspberry Pi as my platform with a small touchscreen.
I've been running this multi-map bin for a few years so I want to integrate with it's capabilities. I already have some code that reads and writes to the ECU over KWP so it's the old, "when all you have is a hammer, everything looks like a nail."
I'm sure there are many other, better ways to accomplish what I'm trying but I'm having fun so I'm happy. If I come up with anything cool, I'll share.
Thanks again for sharing all the great info!
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #116 on: July 13, 2017, 06:14:52 AM »
|
|
|
I'll respond here when I have a moment
|
|
|
|
|
Logged
|
|
|
|
fknbrkn
Hero Member
Karma: +177/-18
Offline
Posts: 1401
mk4 1.8T AUM
|
|
« Reply #117 on: July 13, 2017, 06:52:31 AM »
|
|
|
the part with a possibility writing ram with kwp2000 very interesting for me
|
|
|
|
|
Logged
|
|
|
|
trichard3000
Full Member
Karma: +6/-1
Offline
Posts: 57
|
|
« Reply #118 on: July 13, 2017, 11:49:06 AM »
|
|
|
the part with a possibility writing ram with kwp2000 very interesting for me
I don't want to hijack this thread. I was mainly looking for ways to interact with the custom multi-map features Phila_dot added, like reading the map set number. Even just this has value to me when logging persistently. Let's take the KWP2000 stuff over to the "Communication Protocols" sub or take a look at this thread in Data Logging: http://nefariousmotorsports.com/forum/index.php?topic=4212.0title= There's Python code there that exposes some of the basic KWP read/write stuff. (Only tested on my M-box and generally buggy.) It's not a substitute for disassembly (easier to spell right on PC vs phone!) in any way, much more important for logging. |
|
|
|
|
Logged
|
|
|
|
trichard3000
Full Member
Karma: +6/-1
Offline
Posts: 57
|
|
« Reply #119 on: July 13, 2017, 04:23:34 PM »
|
|
|
For what it's worth, I was able to directly read and write values to 0x383f42 (via KWP) and that value stayed persistent after a power cycle. Even though my rinky-dink code wrote and returned the values 0x1, 0x2 and 0x3, for some reason when I use my logger on the same address, I'm getting 16, 32, and 48 instead. Any known reason why this would happen or am I just losing a nibble somewhere in my code? Can't confirm that maps are changing on my bench rig (or I haven't figured out a way yet) so more results to follow.
|
|
|
|
|
Logged
|
|
|
|
|
