3 registered members (jarofjam, cp07, jaaps2),
194
guests, and 2
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums69
Topics113,611
Posts1,341,241
Members1,804
|
Most Online731 Jan 14th, 2020
|
|
|
DIY Re-mapping?
#1135088
24/11/2010 14:35
24/11/2010 14:35
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
I'm hoping flea/neil can jump in here.. In short, how do companies do it, software wise? I take it even with OBD, there's no industry standard piece of software for accessing fuel/ignition maps? Do they just do it with trial and error, hitting the ECU with random data and seeing what comes back? I would imagine it's far easier with removable chip-based ECUs as you can dump the chip and examine the contents but where do you start with OBD type ECUs? I know from playing with the Punto 1.2. 16v ECU (with help from Neil) that getting in in the first place aint exactly easy, even more so if there's no documentation relating to the data protocol. I'm not looking for a full blown tutorial here but if anyone knows how these guys go about it and wouldn't mind sharing, it'd be very appreciated. I'm doing some web design for a race engine builder at the moment and I'm hoping he'd let me play on his dyno at some point - obviously though, being race orientated, he maps standalone ECUs so not much point in asking him! Oh and of course, if I get anywhere with this, I'll share my findings, gratis
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1135100
24/11/2010 14:50
24/11/2010 14:50
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
|
|
|
Re: DIY Re-mapping?
[Re: TimC]
#1135124
24/11/2010 15:14
24/11/2010 15:14
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
Do you really think they are going to tell you how to do it? And besides, it's not just the knowledge, it's the experience that matters... Um...yes. Like you say, it's experience that matters. I'm not asking for the experience, I'm looking for a starting point...
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1135408
25/11/2010 00:25
25/11/2010 00:25
|
1NRO
Unregistered
|
1NRO
Unregistered
|
I've known people have success with products from this lot. http://www.moates.net/
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1135522
25/11/2010 09:46
25/11/2010 09:46
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
Cheers mate. From reading around, there appear to be quite a few options out there. Most important part is making sure whatever software you're using to do the actual mapping can calculate the checksum for your type of ECU. Found this site, which caters more to diesels but has useful info: http://free-tuning.com/WinOLS seems to work with the 20v NA ECUs but I'll keep looking. Hardest part, apart from the mapping itself, is making sense of the map dump and figuring out which maps do what. Some are recognisable but others...that's where experience/research/trial and error comes in! However, I'm not put off buy this! What I'll prolly do is buy the KWP2000+ or Galleto box and "listen" to what it sends out to the ECU - then maybe Neil can add map dumping/uploading to startrek Will also look into writing diag support for the VIS (no promises!)
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1135889
25/11/2010 18:42
25/11/2010 18:42
|
TurboJ
Unregistered
|
TurboJ
Unregistered
|
If it's OBD then no live map just JTAG flashing. For live map on non OBD you need to buy a Master Kit and/or eeprom emulator and software to live map. Its not difficult. The hard part is finding all the hex locations and what they do. C&D, Tuner Pro, Map3000 etc but these are really for companies NOT DIY. You have to pay to unlock the location of the maps or find them yourself or know a mate who knows a mate that has the DAMOS file. WinOLS is the one There is a tutorial for a guy from Brazil who tell you how to live map the 20VT in WinOLS. (jagwar)
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1136142
26/11/2010 10:10
26/11/2010 10:10
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
Nice, cheers mate!
|
|
|
Re: DIY Re-mapping?
[Re: barnacle]
#1136667
27/11/2010 03:48
27/11/2010 03:48
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
well, woj's post has an interesting idea regarding the maps - disassembling the code and using the diag protocol info to trace which parts of the eprom the diag code calls to return the info. gonna look into this over the weekend and see if I can determine the 18fd maps - then eventually move on to the 20v! regarding map flashing via port, that kwp2000+ box says it supports doing that with the 20v na ecus - are they wrong or are you talking the turbo ecus? regarding getting it wrong, yeah, already got my eye on a couple of ecus on fleabay just incase
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1136677
27/11/2010 07:44
27/11/2010 07:44
|
Joined: Dec 2005
Posts: 33,563 Berlin
barnacle
Club Member 18 - ex-Minister without Portfolio
|
Club Member 18 - ex-Minister without Portfolio
Forum Demigod
Joined: Dec 2005
Posts: 33,563
Berlin
|
If the kwp2000 box can do it 20v, it's talking about the VIS ecu. The 20V and VT ECUs are effectively identical, bar the code being different. I don't know which 20v you have - the clue's on the cam-cover.
Disassembling code is, um, not for the faint-hearted. My belief from looking into the Weber/MM unit for the 16vt is that it's been written in a high-level language - probably C - and compiled to machine code. That gives you a certain style which you can expect, the way calls to other routines etc are implemented, but doesn't make it as obvious what any particular routine actually does.
I started from the reset vector; identified which of the vectors were in use (which identifies the processor variant) and then followed the main reset to the initialisation code... which tests the main memory and in fact contains a classic C 'off by one' addressing error...
The biggest problem I had was that because each disassembly run generated the code differently, it couldn't cope with comments so I ended up trying to manage several different files of notes. Tricky, and I never finished it.
And that's for the 8-bit twenty-year old simple processor in the MM ecu. I'm not even sure what the processor is in the Bosch ecus.
As Woj said - a couple of year's playing to get where he has - I'm not surprised...
|
|
|
Re: DIY Re-mapping?
[Re: barnacle]
#1136704
27/11/2010 10:33
27/11/2010 10:33
|
Taz
Unregistered
|
Taz
Unregistered
|
IIRC the reason why one of our main Live MAP tuners on here does this, is because he was so disgusted with the service he had from others that he pretty much did it from scratch. A LOT of cost outlay, a LOT of trial & error on his part, a lot of self testing. He may make it "appear" to look easy, but I can assure you the changes can appear to be subtle, but the influence on your engine are massive. Not saying don't give it a go, but don't expect to be remapping your car to +50hp in one session HTH
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1136782
27/11/2010 13:37
27/11/2010 13:37
|
GrahamL
Unregistered
|
GrahamL
Unregistered
|
Most important part is making sure whatever software you're using to do the actual mapping can calculate the checksum for your type of ECU.
The checksum on the 20v/20vt ECU is easy enough to calculate, if you compare a couple of different firmware versions you'll see where it is... it's just a 16 bit, byte sum from $0000 to the byte before the checksum ($feff iirc). For the 20v ECU (not sure about the VIS variant) you'll ideally want to use an eprom emulator, or you could cycle through a few UV erasable eproms for testing changes. I just used a stack of proms when developing the original Gtec and binned them at the end, but then I wasn't making that many changes or fine tuning things to the level you'd need for proper live mapping, otherwise you could easily go through 100's of chips. I didn't try a flash chip but it's probably possible to find a pin compatible one with suitable specs and use that, it may even be possible to rig up in system erase/programming, with the engine off, if your programmer supports that option. Disassembling and understanding the code is gonna take a LONG time. I looked at the 20vt code for a few days and didn't get very far, but far enough to see it would take at least months and probably a year or more to understand it in detail. This is why every tuning chip I've seen only makes changes in the maps (data tables) , but never to the actual code. It's at least 10x and maybe 100x more difficult and time consuming to make useful changes in the code section compared to directly in the maps. And you don't have to understand a line of assembly language to re-map via the tables alone. <edit> BTW the microcontroller in the 20v/20vt ECU's is Intel 8051 based, if you're looking for tools.
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1136794
27/11/2010 14:19
27/11/2010 14:19
|
nedge2k
Unregistered
|
nedge2k
Unregistered
|
Thanks guys. Yeah I fully realise this is not for the faint of heart and the chances are, I'll only end up changing the maps and not the code - if I even get that far - but I want to understand this stuff, always have, so I'm gonna give it a go. That being said, I get the feeling that changing parts of the code may be a necessary evil, especially if you want to add extra functionality and/or remove limitations. Regarding the cost, I'm willing to outlay a certain amount but I'm not gonna go nuts as I could get a DTA S60 at cost, less the VAT through work so... Neil, cheers for heads up on techedge! Graham, CPU was gonna be my next question, thanks! Regarding code disassembly, yeah, sounds like what the MM guys did is the equivalent of "minifying" javascript - makes it a right pita to decipher, no comments, var and funtion names 1 char etc.! I have no experience of machine code but like I say, really wanna learn this stuff so gonna give it a go and see what happens See you in a couple years
Last edited by nedge2k; 27/11/2010 14:20.
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1136796
27/11/2010 14:24
27/11/2010 14:24
|
TurboJ
Unregistered
|
TurboJ
Unregistered
|
|
|
|
Re: DIY Re-mapping?
[Re: ]
#1136806
27/11/2010 15:02
27/11/2010 15:02
|
GrahamL
Unregistered
|
GrahamL
Unregistered
|
The code does look like compiled C, but even considering that it's very messy. Probably done on a very old, non-optimised compiler and also looked to be patched all over the place (no doubt by different people over the years), with redundant and duplicate code fragments. The fact that it's running on a crappy old intel processor doesn't help at all. I've disassembled and modified 100's of compiled C programs from object code on various different processors and the code in the 20vt ECU is some of the worst I've seen, so I wouldn't recommend it as a way to learn reverse engineering. You won't find any comments in object code and very rarely proper variable/function names, unless they've accidentically left a debug compiler option on or it's a large/complex application with it's own debug/diagnostic system built in. If you use a good disassembler like : http://www.hex-rays.com/idapro/it'll create a level of numbered labels, which makes things a bit easier at least.
|
|
|
Re: DIY Re-mapping?
[Re: barnacle]
#1137869
30/11/2010 00:18
30/11/2010 00:18
|
GrahamL
Unregistered
|
GrahamL
Unregistered
|
Indeed, I've seen self modifying, trace encrypted code that was easier to follow, haha. (Only a slight exaggeration ). Again it's more 16v related (the IAW4W6 is similar to the ECU of the 16v coupes I think?), but there's a load of info with commented firmware code at: http://www.sonic.net/~mikebr/efi/ecu_hdwr.html http://www.sonic.net/~mikebr/efi/ecu_code.html and the code at: http://www.sonic.net/~mikebr/efi/stuff/efi_base_source.html
|
|
|
Re: DIY Re-mapping?
[Re: barnacle]
#1137924
30/11/2010 09:17
30/11/2010 09:17
|
Joined: Dec 2005
Posts: 33,563 Berlin
barnacle
Club Member 18 - ex-Minister without Portfolio
|
Club Member 18 - ex-Minister without Portfolio
Forum Demigod
Joined: Dec 2005
Posts: 33,563
Berlin
|
As far as I can see, the hardware is similar, but the code completely different. None of the parameters are anywhere near similar - I think that this is for a V8 with wasted-spark ignition. It may be that the code fragments are analogous, but finding where they are... I may decide that life's too short. Example: to return values to a tester or the widget:
1) grab the requested code byte and save it
2) multiply it by two
3) add it to an offset value
4) use this new offset to get a 16-bit address
5) grab a single byte from this new address
6) output the byte
All very well and good, because it means that the variables don't need be in the same place or in adjacent locations; it can return some from the ram and some from the EEPROM (e.g. error counts). But it appears that requesting some values just returns a fixed value from the EPROM and that some return the wrong values - there are two values that return the VAE for example... You spend half your time trying to work out whether they actually meant it, or it was just a cockup... very frustrating, and life may just be too short. On the other hand, it might be nice to rewrite the code (perhaps using the megasquirt code) using the same hardware...
|
|
|
|