EFIDynoTuning Forum

Sub 0FCD1 "Sub0FCD1" :WN
Sub 0FA41 "Sub0FA41" :WN
That will define the subs with one word argument and apply names to the argument.

It will do every instance with a single command.
Individual arg command are useful where a sub has different numbers of args determined by some variable in the code.

4.012 cool. Yeah 5.08 is not ready for prime time on multibanks.

From the disassembly;
Add the 12A650 to get XU7A-12A650-AFA.
http://www.obdtester.com/ford-ecu-updat ... 12A650-AFA
http://www.obdtester.com/ford-ecu-info/ml2_8a1

Going back early in this thread, it started from a RZASA disassembly using a DIR generated from a DMR file. Equivalent subroutines were identified between RZASA and this FLN0 bin. The address names in RZASA were transferred to the FLN0 (EQE3) DIR equivalent addresses.

Thanks for posting the update.
Do Ford have a complete fault code reference for you techs to use?

The user can choose any of the current SAD versions now.

Trouble is all SAD versions don't get everything right in any bin.

Even cherry picking the best bits of disassembly from all versions is going to come up short.

TVRfan, thank you for the new version and ongoing effort.

Efloth, in simple terms it's the nuances that are causing the trouble.

BOOSTEDEVERYTHING wrote: ↑2024 Feb 13, 13:21 Here is the updated compare sheet and Dir file.

Your DIR, why have you chosen 0068? RZASA EQE3
Following through various code for TOT and ECT, I agree with what you have done, so it looks like you are on the right path.


Your DIR, what question remains? You DIR, any reason for PIPCNT to still be in doubt? You can add this 0186 is N (RPM) so you can change that entry. Your DIR, any reason for LD_EGO_DLTA to still be in doubt? Delete these You have pasted in the fault code list without aligning them with the fault code numbers.
Code 113 does not get the name for Code 430, and so on. This is repeated, delete one of them Keep doing what you are doing, except blindly copying and pasting.

BOOSTEDEVERYTHING wrote: ↑2024 Feb 14, 11:53 Ok, So if I am understanding correctly, if the vehicle did not have it then the PCM probably does not have the components to implement the feature.

For large production runs, that would usually be the case.
For small production runs, the hardware code from a large production run might be used as is and may have spare IO in place.

My 2003 Harley F150 with EKO2 PCM, for example, did not have electric fans, so it most likely does not have the hardware to implement the feature?

Does any other application using the same hardware code have electric fan control??
The PWB is often common to other hardware codes, component placement in manufacture will be to suit a particular hardware code. You need to go digging on those dusty old Ford servers to find out all the PWB/Hardware code/Catchcode/Feature set combinations. Oh, and then share it with us!

But I could maybe steal the EGR output to make it happen? But then I would have to find another output for a high/low fan function if desired? I would have to look in the service pubs to see if anything else deleted was a pwm output to implement pwm fans. Or I may be able to add the components to make it work if I can find the components and have the necessary spaces free on the board?

All possible hypothetically.
PWM points are on DUCE or DARC chips. There is some info in the manuals, handbook and strategies. Start looking in your PCM to see if any chips match the documents.

I guess to sum it up I would like to add some modern features and make it all operate like it was factory equipped. I am very OCD/nit-picky about things like wiring and aftermarket components that do not integrate seamlessly.

The option of using a more feature rich Ford EEC-V box should be considered.

Then after finding or adding components I would have to figure out how to add the needed code to make it function, is there a write up somewhere for adding extra code to factory code and recompiling the BIN file properly to make it all work?

No write up I'm aware of.
There is no compiler, it is done by overwriting the BIN hexadecimal with a hex editor.
You may need to make space in your BIN for extra code, by stripping out redundant code.
You may be able to repurpose redundant code.
You might be lucky, your BIN already has the necessary code but it is just switched off.

This bin was hand coded with a hex editor. Partially cut and paste from another BIN and some bespoke code.
https://github.com/OpenEEC-Project/EEC- ... -Test-Bins

BOOSTEDEVERYTHING wrote: ↑2024 Feb 13, 13:13 Wow. That is a bit more in depth than I thought it would be. LOL. Maybe it won't be as intimidating after I actually get started doing it.

It's not difficult, just a process to work through.

Side note: have you had anymore time to look at my EQE3 dir file and spreadsheet? Just wondering how many more errors you have found.

I have spent a little time on it but nothing to report at the moment.
I'll update to the new one you posted and continue.

Also forgot to ask, How could I determine if a specific PCM has hardware available for things like pwm fan control or hi/low fan control, or other things of that nature?

If an OEM application has the features, then that PCM could be used to implement the features.

Also how could I tell if there are extra inputs available for extra sensors, like ethanol sensors and things like that?

Tracing the circuit traces on the circuit board of the PCM to harness pins. If the harness does not have a wire for the pin, then it may be possible to use it elsewhere.

I know I have the hardware manual but I am having issues identifying exactly what everything is on the actual board.

The later PCM's have chips that are not covered in the manuals or handbook. Both the manual and handbook predate the first 8065 box in the wild and stuff changed pretty quickly after they started shipping 8065 boxes.

And can hardware be added to boards to make things available? I know on most of the PCMs I have, have a lot of blank spots for chips and other components. Thanks again

Yes components can be added to complete circuits. The trick is to work out what the unused chip pin is for.

Substituting a PCM from a posh model with more features than you need is the easiest way to get spare IO for other purposes.

BOOSTEDEVERYTHING wrote: ↑2024 Feb 12, 10:48 Can you try to explain for me how you made the dir file from the tunerpro definition file please?

SAD806x will import XDF and export DIR files.
Its not perfect, but it helps a lot.
https://github.com/OpenEEC-Project/SAD806x

The basic process is;
Install SAD806x.
Open the target BIN.
Run the disassemble command.
Import the target XDF.
Run the disassemble command.
Export to DIR.
The DIR will need some clean up, that may include processing the DIR using a spreadsheet.

I would like to try another one and start a third comparison to try and find other subroutines that I cannot find similar between RZASA and EQE3.

The RZASA dir I posted was derived from a DMR file not a XDF file, but don't let that stop you.

Maybe OMAE2 as I also have a Harley Davidson F150, So I can apply things and see what may work and what does not.

I don't have a DMR file by that name, but don't let that stop you.

Also, Can you please point me to a write up for making a spreadsheet type def file for BE from a DIR file please?

First off you need to understand what a BE def looks like.

The help file has a section covering what is required in the def file.
http://www.eecanalyzer.net/dl/BE2012/He ... 20Help.pdf

Next look at some open def files, here's the GUFB one.
http://www.eecanalyzer.net/strategies?v ... fileId=553

Because you listened previously, you will have kept your DIR tidy and the columns aligned.

Your DIR will have lots of commands for Scalars, Functions, Tables and Payloads.
Others commands may not end up in your DIR.

Scalars are parameters at ROM addresses. Typically Bits, Bytes, Words and Longs. They could also be small code hacks.
Functions are the two column parameter blocks at ROM addresses.
Tables are the multi column multi row parameter blocks at ROM addresses.
Payloads are Bits, Bytes, Words and Longs at Register and RAM addresses.

The basic process is;
Open a new excel workbook.
You want to get the content from your DIR into excel and break it up into Scalars, Functions, Tables and Payloads.
Scalars, Functions, Tables and Payloads want to end up on individual sheets. The rest of the DIR ends up being discarded.
I usually import the whole thing to a worksheet then break it up over multiple worksheets within excel.

Import the DIR into a sheet or copy and paste to the sheet.
Use excels text to column command to break up the DIR into columns with the command, address, name, sign, size, comment and characters.
The DIR will have characters such as " and #, set column breaks so they can be discarded.
All columns need to be formatted as text.
You may need to create an index column from the hex address using =hex2dec(0xaddress).
Sort your columns by DIR command and address.
Copy and paste S, F, T & P rows to clean worksheets.
Use excel functions to convert the DIR cells into cells for the DEF.
Start a clean DEF workbook or use an existing one as a starting point.
Ensure all worksheets are formatted as text.
Copy the DEF cells from your DIR workbook and paste as text to your DEF workbook.
Complete all the other entries in your DEF workbook, such as equations etc.

Do not use the clear contents command in your DEF workbook, BE has issues with it. Use backspace or delete.
Again, ensure the whole DEF workbook is formatted as text.

It will be an issue resulting from the call and arg at 0ef10.

First confirm how many args sub 87e99 really takes, then command SAD if required.