[IMINHELL]

Now I don't know if this is old news or if anyone's posted it earlier, imagine someone has and that I just missed it/couldn't find it.

Anyways,
I found a couple website that ate European based that peaked my interest and I want to know if this is something worthwhile/should look into more or not; and if it's doing what I think it's doing.

Swiftec
WINOLS

From what I've been able to find, both software's have the same capabilities and do the same basic things; which is to 'map' your ECU and supposedly find where the data we want/need to change to tune the car is located.
I don't know if I'm understanding that correctly though. It sounds straight forward but much of what I've found/read is based on tuning chips, not through the J3, OBD or anything like that.
Even still the process is similar and the software's to pull a .bin, write a tune and load it back are almost identical.

What I'm looking for is something I can decipher stock .bin's with, namely my own. I have the stuff from Craig and Clint, just no definition file for my car. I'll do the work myself just so I can get tuning on the fly working.

Do you guys think either of the linked software''s could get me on that path, making a definition file?

[cgrey8]

I've moved this topic over to the area that it best belongs in.

I don't know anything about either of those products, however have you tried running your stock BIN through trvfan's disassembler? He's been working on deciphering a LOT of what is in Ford BINs and even keeping up with what's what as it goes along. There's still some more work to be done, but from last I heard, it was doing a better job without a directive file than most of the other disassemblers do on Ford BINs...particularly older EEC-IV Bins.

If you haven't used it, I'd be curious to hear your take on it after giving it a try.

[vristang]

I looked over the swiftec site a little, and it lists Ford ecu's in a manner I'm not familiar with...

Ford

BOSCH EDC16C34
BOSCH EDC17_C10
BOSCH EDC17_CP42
DELPHI DCM3.5
MARELLI MJD6
MARELLI MJ8D
SIEMENS SID206
SIEMENS SID804

Does the above cover the common eec-iv & eec-v?

Did you get prices?

[Dave2302]

Hi,

Maybe I can be of assistance here as I am going through exactly the same thing at the moment, with EECV V6 24V Cosworth ECUs, and I have tried similair programs, which only work on Bosch Siemens or Marelli ECU's.
I doubt very much that either of these will de compile Ford EEC.

There is much help contained in my threads below about creating a def for European ECU's ;)

This type of ECU listed in the stuff in your links is NOT EECV and was only fitted to a handful of European Fords, predominantly Turbo Diesels.

TVRFANs dissassembler appears to do bits of my EECV's but tbh it's a bit above me, I dont understand what the outputs are telling me.

Creating your own def file takes hundreds of hours.
I have enlisted the help of a good specialist, (few and far between), and at the moment we can alter from Auto to Manual Trans, and the Cooling Fan Temperatures after a few weeks of spare time work. This is enough to get my car running on it's own ECU fairly well, once I've successfully re flashed it we plan to add to the def.
To create a full def is a helluva lot of work.
The reason for this is that almost all European EECVs put the different Parameters in different Locations within the ROM, unlike Bosch Siemens Marelli etc, so there will be no one software that will work with all.
Clint Garrity BE is good, providing you can get / create a def file, and the Moates Burn 2 will read all the bins you want to, but to reflash internal ROM via OBD you will need Mongoose Lead with FEPS, AFAIK you cannot reflash via J3.
Also you cannot reflash EECIV internal ROM at all, you will need a J3 Chip, (External ROM).

HTH

Regards Dave

[tvrfan]

(Thanks for vote of confidence Cgrey !!)

Dave,
My disassembler is designed for EEC-IV series only, and even then I still need to do some more work to get it to work better for the later multibank binaries, which I'm trying to do now.

Even then, there's no way to guarantee what software inputs and outputs connect to which physical devices/sensors, as different boards had different options. (or at least I haven't thought of any way - suggestions welcome !)

I thought EEC-V didn't use the 806x CPU so I haven't even looked at them. What I really need is good info on its base setup - for example the basic key for EEC-IV is the defined start point (0x2000 in bank , the interrupt vectors (0x2010 onwards), and some basic memory map details, and then it's possible to trace from there.

If the same info exists for EEC-V, I could try a version for it. Anyone got that base info ?If you want to post the binary, and you're sure it's an 860x CPU, I'll have a look at it. If it's not an 806x, then need a good guide to the CPU....and probably have to restart the whole thing.

.Def files - I have written a little tool which converts a .def file into a .dir (directive) and a .cmt (comment) file for my disassembler. It's currently very much in a test state, and could crash, but I can post it here if anyone is interested and doesn't mind it falling over (it won't break Windows as far as I know)

[cgrey8]

...Even then, there's no way to guarantee what software inputs and outputs connect to which physical devices/sensors, as different boards had different options. (or at least I haven't thought of any way - suggestions welcome !)...

The only way I could think of is to use a series of known EEC BINs where the physical I/O is known. Then compare unknown BINs to known ones looking for similar code patterns. Obviously this wouldn't work when there is no similar code pattern in the unknown BIN. But that might be one way to consider this.

...I thought EEC-V didn't use the 806x CPU so I haven't even looked at them...

EEC-IV are all 8061 single bank. There were 2 different pin-counts of the 8061, but the differences between the two were only physical processor pin count.

EEC-V are all 8065 multi-bank EECs. The early ones were only 2 bank. The later ones were 4 bank. And I believe it's safe to say all EEC-Vs are OBD-II supporting and can rewrite their stock tune since the ROM is actually flash. Although the speed to rewrite the flash just isn't practical as compared to just putting a Quarterhorse on the J3 port and writing to that.

The EECs that succeed the EEC-Vs are like the Spanish Oak, Black Oak, and whatever those other newer architectures are, most of which use a PowerPC processor. Although I believe the latest EECs Ford is using today have gone back to Intel technology. But the chip is actually Bosch? I'm fuzzy on those details. Regardless, all the newer EECs require flash reprogramming since they don't have a J3 port.

[tvrfan]

Well, in that case I've been stupidly assuming the wrong names for EEC-x !!
I thought the multibanks were also EEC-IV...and never bothered checking

The SAD disassembler (the latest version posted) will work for any 1, 2 or 4 bank EEC with an 8061 or 8065 CPU, in full (256K) or shortened binary formats (192K etc) and is therefore good for an EEC-V. It doesn't always get all the data structures though.

NB. There are some Australian SINGLE BANK 8065 EECs around as well. Don't know whether these are labelled as EEC-IV or EEC-V, but SAD can decode them too.

[decipha]

Sad doesn't work for my 4 bank bins

Like the 03-04 cobra for example

[sailorbob]

The Australian eec-v ecu's are 2 banks as a minimum, it's just that some of the early ones do not use much of bank 1 with the code and calibration data all being in bank 8.

[tvrfan]

Sad doesn't work for my 4 bank bins

Like the 03-04 cobra for example

Decipha - which binary is that ? I would really like to see what goes wrong....

There are some very clever programming/coding tricks in some of the later binaries, which can mess up the algorithms which try to sort code and data, I thought I had found most of them, perhaps this binary has a trick I haven't seen before ....

Sailorbob, I think the 6TAC, 6BDB (Ford Falcon Australia L6) are truly single bank 8065...

[sailorbob]

6TAC is definitely 2 bank. I haven't seen a 6BDB bin file so I cannot comment on that one but every other 6*** ecu bin file I've seen has been 2 bank.

[tvrfan]

OK, thanks Bob - I got my file from tiperformance.com.au.

That binary file to only have anything from 22000 to 2ffff in the file, and all the rest is 0xff. There's no bank swapping I can find anywhere in the code, and there does seem to be data from 0xc000, but looking at it again, there isn't a lot of data....perhaps they haven't dumped bank 1 properly ?

Bob, have you got a different version of this file ?

Decipha - found an AMZ2 file on web, which is supposed to be the 0304 Cobra - will have a look today and see if it works (or why it doesn't !)

[tvrfan]

OK - the AMZ2 does indeed fail to work. (file copy downloaded from this forum)

The reason is that my disassembler demands that the RESET START point is bank 8, address 0x2000, which I thought was a rule for all EEC binaries.

The AMZ2 appears to start in bank 9.
Bob, anyone, can you confirm this please ? [Thanks]

Therefore I will have to change the disassembler to hunt for the true RESET start point instead.
Thanks to decipha for pointing out a problem.

[sailorbob]

As above, the early ones do not use much of bank 1 with the code and calibration data all being in bank 8. Bank 1 only contains the ID_BLOCK data and BIN_CHIP_ID scalar.

[tvrfan]

Thanks again Bob, I now see there are two bytes set in bank 1. That all makes good sense.

I think for now at least I will continue to treat those as single bank, as they don't do any bank swapping in their code (as far as I can see).

Decipha - I did a quick fiddle in my disassembler code for the AMZ2 binary, and it does [mostly!] work and make sense starting at bank 9. I shall include the capability to begin in banks 8 or 9 in next release.

Bank Select Register (R11)
I see that the AMZ2 has R11 set to 0x11 in several places, whereas XDT2 sets it to 0x81.
Pretty sure the lower nibble = data bank, any clues as to what the next nibble (1 or 8) does ?
It doesn't make sense to be code bank from where it is in AMZ2.
I do see it's next to a STACK register setup .....hmmm.... could it be stack bank ?
Can the stack exist in any of the banks ? I guess it could ?
Ideas anyone ?

[sailorbob]

There should be more than two bytes in bank 1, the ID_BLOCK will contain the strategy name, Ford copyright notice and (in the case of Australian ecu's) the 'catch' code.

[Dave2302]

Hi tvrfan,

Here's a couple of my 24V V6 Cosworth bins, for you to see if it works correctly for them

Regards Dave

[mpaton]

OK - the AMZ2 does indeed fail to work. (file copy downloaded from this forum)

The reason is that my disassembler demands that the RESET START point is bank 8, address 0x2000, which I thought was a rule for all EEC binaries.

I believe that rule is correct. What you may have missed is that there appear to be many different ways of putting a download into a file. So the first part of any disassembly is to find out where the code for each bank begins and ends. This is made even more complex because there must have been some belief that it was possible for interrupts to arrive in any bank, so you will see interrupt vector code in many banks. So you need another way to decide where bank 8 lives in your file.

[tvrfan]

I believe that rule is correct. What you may have missed is that there appear to be many different ways of putting a download into a file. So the first part of any disassembly is to find out where the code for each bank begins and ends. This is made even more complex because there must have been some belief that it was possible for interrupts to arrive in any bank, so you will see interrupt vector code in many banks. So you need another way to decide where bank 8 lives in your file.

Yeah, I had thought about that. [Honest I did !]

What I was doing was to check for a first jump (at 0x2000) in each bank, and then check if it is a loopstop jump or not, and then making sure there is only one 'real' jump in bank 8 , which must be after the interrupt vectors (2020 for 8061, 2060 for 8065). This scan neatly catered for the differing formats and came up with a file to bank map. (some files have the first 0-2000 included for each bank, some don't, some are inconsistent)

All the binaries I have seen so far DO have loopstop jumps and I can understand why they must have full interrupt vectors in each bank, as the CPU could be anywhere when an interrupt occurs, so these are a good safety feature, even if not strictly required. This trick was happily working for all binaries until that AMZ2 came along, as it was assuming banks were always in fixed order in the file.

I have temporarily allowed the 'real' jump to occur in bank 8 or 9, to see if AMZ2 then worked - it did show code in its output, but haven't checked in detail if it's really bank 8 or 9. I find it very suspicious that the AMZ2 has its start in bank 9, unless we can find other examples out there..

If AMZ2 truly does have banks (or start) in a different arrangement, say 0,1,9,8 then I'm at a loss right now on how to tell this automatically. Of course Mr. Ford (or subcontractor) could have done something sneaky with the circuit board, or it could simply be the dump utility did the banks in the 'wrong' order. (that is, wrong as we understand it...)

As always ideas, suggestions welcome !

[408Way1]

Have you tested your program on the VEX1/WAY1? I am running a WAY1 if needed.

Is there anywhere I can get a copy of your program? I would be interested in what it produces.

Al McGee

408 stroker in a F150

[decipha]

vex1 is a waste of time, that falls under the ahacb strategy, its completely broken out by sailorbob, i know cuz i've tuned them

[decipha]

tvr... can you shoot me an updated SAD ??

decipha at efidynotuning dot com

[tvrfan]

Decipha,

It's still a bit flaky as yet... It isn't working quite right for automatic recognition of tables and functions in multibanks, but should work (probably with gaps) for things like the Cobra bin now. I have changed it to allow alternate bank ordering in the bin file. NOTE - it can't tell if data banks 0 and 1 are swopped at the moment - haven't figured out a way to do that yet.

It also isn't seeing background task calls when done via ALTSTACK instead of main stack.
Manual commands should work just fine, although haven't tested them thoroughly yet.

It's been a while since last release, but I've made some big changes to it, and still fixing bugs.

If you're happy to accept it might crash, or go nuts (It won't crash Windows, even if it does break), I will post latest version here for everyone.

Let me know if that's OK for you.

[ender11]

well sometimes every program crashes so go on post it.

[tvrfan]

I thought that would be the answer, so I have posted a new version in the "developing disassembler" thread, to keep all the versions in the same place as it's neater....

As always, If you find a binary that doesn't work at all , I'm interested in it, please post it.