DIY Re-mapping?

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

Hmm...do people use this?

http://www.lioliosracing.gr/main.php?id=153

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...

Ok, may have found the mother load!

http://cgi.ebay.co.uk/KWP2000-ECU-Remapp...ht_23953wt_1008

anyone used one?

Says it'll do both ME3.1 and ME7.3.1 (VIS and non-VIS 20v NA)

Um...yes.

Like you say, it's experience that matters. I'm not asking for the experience, I'm looking for a starting point...

I've known people have success with products from this lot.

http://www.moates.net/

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!)

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)

Nice, cheers mate!

Oh! Just found this:

http://www.fiatforum.com/cinquecento-seicento/253576-iaw-ecu-live-mapping-tech-info.html

No, not related to coupes but useful nonetheless, especially for my punto (18FD)

Nedge, Woj has covered the basics pretty well.

Whether you're feeding in numbers via the port - which the coupe ECUs can't (don't know about the VIS) - or by using a romulator the critical thing is knowing what you're changing and how much you're changing it by. And of course, keeping a copy of the original code safe, just in case...

You're not going to see map reading/dumping on Startrek - it's not possible. Only an ECU with EEPROM (not EPROM) has the possibility to be programmed remotely.

As you've noticed, finding out what the various maps are is the tricky bit. I've had a *play* with the 16VT code and it's clear where some of the maps are - you can tell from the 'shape' of the numbers - but it's not easy to tell which parameter you're dealing with or what the parameters mean. And if you get it badly wrong, it might just stop, or it might stop... permanently.

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

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...

As an added courtesy, the techedge tools won't work in 64-bit linux or windows...

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

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.

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

Just get a MS3X

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.

Ah, it looks like the techedge stuff does work OK in a win2000 virtual instance running under VirtualBox on Linux - I think the same thing is available for Windows.

Neil, just a side note for the 16v stuff, have you looked at http://rp-lab.com/hp.shtml

Yeah, seen the site, Alexis. I like the thought that you can stick two widgets onto an F40... but they don't have any details for giveaway that I can find.

I'm keen to see some public reverse-engineered info here.

What is instructive is how feeble the processors are doing this task - the 8051 is a notoriously slow processor; eight bits only and up to ten cycles per instruction. Hmmm. But then, it doesn't have a lot to do if it's got sensible timers...

I take it back about the 16vt code being written in C - having investigated in a bit more detail, it looks more as if it's been written by at least two and possibly more people, and perhaps with some chunks of code just dragged in... different ways of doing the same thing, apparent bugs, and huge swathes of the eprom unused for anything... nasty nasty code.

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

Thanks, Graham. I found that site years ago, lost it, and have been looking ever since. I agree entirely with his assessment of the code...

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:



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...