[baba_banana]

first, I really appreciate reading through the discussions you guys made on these posts:
https://eectuning.org/forums/viewtopic.php?t=21827
https://eectuning.org/forums/viewtopic.php?f=8&t=21697
http://forum.efidynotuning.com/viewtopi ... 2&start=40

I'm excited that I could get into the phase where I can reverse the blocks of binaries and get down to deciphering the instructions and jumping into routines to id functions.

Abit about me: I'm recently graduated from UC San Diego with a BS in Math and I guess I realized late in life that my passion was really in discovering/hacking things and understanding how they work and nature itself. After graduation, I had to fix and sell my car and I wanna get a truck for outdoors but at the same time I got into the whole OBD scanner thing and things just spiral deeper into the hole from there. From the time I last posted on efidyno at the end of August, I've looked into the fascinating history of hacking and creation of retro games in channels like MVG and Arstechnica, reviewed circuits and spent a lot of time piecing together a picture of how data flows in MCUs and assembly in general.

my intention is similar to tvrfan; I would like to take a peek into ford ECU to learn about the programming of the tables and functions, and maybe if I get more proficient I could disassemble other models more and do a comparative analysis . . i don't think i'll be flashing anytime soon as I want to cover the breadth of coding and hardware, that means building my own device to interface with the obd port to get the live data (as I want to do some embedded systems/electronics project). Thought this will be a great learning opportunity (nerve-wrecking at times) and it's a cool project along the lines of retro-computing RE/emulators. Also, as you guys found out through your practice, analyzing and finding meaning in data/binary is a huge subject.

I got my hands on a few EECV bins a month ago and only hex dumped a few days ago. I then used binwalk, since I wanted to use an opensource, generic disassembler that's support cross-scripting with other languages like python.
Seems like binwalk split it into 5 sections of lzsm compressed files on the first go and the signatures disappeared after subsequent tries. I figured maybe it's because binwalk mistakenly (like it famously does) recognized some hex code in the headers as the lzsm format.

Anyways yesterday I googled intel 8065 disassemblers and saw that SAD and BL does specifically that. I see SAD is in c++ and on git but I don't have any idea how BL is or where it is. Unfortunately, this is my first time disassembling things and I have no affirmation understanding (from the software aspect) of how files are assembled or disassembled. . Isn't the process just matching hexes to opcodes(Instruction set), pre-op (.SYM?) so to make the code human-readable (especially when you are just analyzing the data statically?)? So can't I just use python scripts to print out the hexes and start to piece together the bits of the puzzle? And if you are flashing, isn't it as intuitive as changing a particular hex value or in asm but making sure damn well that it's the correct one to change? Anyways from what tvrfan mentions, it seems like there's a lot more going beneath the surface but I would be delighted to explore that and provide any possible updates.

Today, I thought, upon recommendation by other people, that I would explore other popular archs with datasheet and bin files supported by general hacking tools like Ghidra or even find simulations online to gain first-hand intuition rather than read about it. But I thought I should pop by first to inspect, since you guys are the direct sources to Ford/Intel MCUs.

Anyways, I would appreciate any advice on using or integrating multiple platforms to achieve a more general way of analysis. I have been recommended Ghidra where I could fill in my architecture and I see tunerpro is opensource and already supports multiple MCUs and have a variety of functions whereas Radare2 is a general comprehensive but steep tool to use. Also BL and SAD has already built up a comprehensive foundation for disasm and, I see, forDiag is able to read many vehicles through obd. I was fixated on Binwalk since it seems straightforrward (i'll still review it later). I wish to use Python but would dig into C++ if I have to.

Pardon my naivety on this topic, looking forward to hearing from you guys and posting updates on my progress.

[jsa]

Welcome to our rabbit warren.....

Google tvrfan and github, grab the latest development version 4.07.8. Not perfect but has some important fixes for eec-v.

Google openeec project and github. Grab Pym's latest SAD806x.

BL was the only choice for a long time. It worked well, but the SAD's are an improvement. I have it here if you really want it.

Way back when, the eectech document and intel 8096 literature was the only info available.

Eventually the EEC-IV handbook was shared here.

Quite recently the EEC software and hardware manuals were shared here.

There are strategy documents available which are Ford's description of what the code does for a particular application. The 4 I am aware of are GUFB, LHBH1, CDAN and CRAI8.

Yes there are a lot of nuances, but relatively easy to understand with the manuals now available.

I've only used the 806* specific disassemblers. Good luck with the other options.

[baba_banana]

thanks for the welcome! And wow you guys been sticking to this for a long while! I have been going thru eectech several times the past month but I think with the google drive and SAD, i'm ready to explore new terrain starting this weekend!

I'm still not familiar with such terms like definitions or strategies (which I've never read or seen in any assembly RE materials, hence I'm assuming it's ECU specific use-cases, or I haven't been exposed to that depth yet) but I assume definitions are like the so-called pre-op symbols (.SYMs). I'll look out for the so-called applications that you're referring to.

I am just curious on the BL disassembler, since mpaton actually mentioned he added new features to it, so I was wondering what was his original motivation for using BL instead of SAD and I'm down to explore both. And I'm actually more comfortable with linux command line than in windows (unless with GUI). Currently using Virtual Box on my main laptop.

[baba_banana]

Micheal,

Obviously I'm going to be more in the 'automatic' point of view, but here are some thoughts....
all of which should be argued for or against, this is my input for discussion, and a couple of questions, if you don't mind !

From your list, There are some things which can be included very easily and could potentially help immediately (see notes on how I do it - open for discussion).
These are all either in fixed places, or are easy to detect.

7) Interrupt handlers
6) finding which bank is bank 8 (where code really starts)
5) ROM section sizes
?) finding the BASE registers for much of the ROM data.
3) RAM sizes, from init routine(s).

Then it gets harder, and probably falls out of the scope of a more 'manual' disassembler, but I guess some things could get printed as a warning ? [to be investigated]
I used a 'signature' approach to find following things, this is a kind of 'regular expression' approach, with a pattern match. Some of them don't work as well as I would like, but it's ongoing.

Table lookup
Function lookup
Base register code (links up with above)
Subroutines which mess with the stack (= have parameters)
Subroutines which not only mess with stack, but get parameters on behalf of others (A9L does this quite a bit, and later ones too)
Vector lists (background task, test lists etc)
[ haven't done rolav(s), don't see the need from a code analysis point of view, but agree would be useful for reader - I could add this ]

Note - If you've not heard the term, the 'regular expression' is a very powerful pattern match technique, shared across many UNIX utilities. They look like gibberish much of the time, but once you get the hang of them, they can be amazingly concise and yet flexible and have optional and/or multiple subpatterns within a single main one.

Things I still haven't properly sorted out [automatically]

May be possible to do -

Timer table - the earlier bins seem to have almost the same code, so may be possible to detect
Subroutines with variable parameters (yes, there are some)

Haven't a clue at the moment -

Data Structures, especially with embedded subroutine calls (e.g. HSO table).
Vector lists with data in them (A9L again - has this trick, effectively a vector call to a subr with data param(s) )
Error tables
ODBII data structs and code (Question - are these also pretty regular in layout and code ? if so could be detectable.

See next post for more....

having revisited the post again and seeing this quote, I think may be it would also be a great exercise for me to see if I can add some features. Also reading this allows me to affirm the fundamental things I have been reading lately. But it's 2020 and you guys have probably updated it several times over. Anyways i'll take a look again.

[jsa]

thanks for the welcome! And wow you guys been sticking to this for a long while!

Indeed. Many reasons for that. Primarily lack public information, followed by the way the code assembly changed over time, the introduction of coprocessors hanging off the memory bus and of course spare time to dig through bins.

I have been going thru eectech several times the past month but I think with the google drive and SAD, i'm ready to explore new terrain starting this weekend!

Eectech is relevant to its time in history. It does not give any insight into changes in later bins. You can pretty much ignore anything it says about 8096, just read the software manual shared here recently.

I'm still not familiar with such terms like definitions or strategies.

A definition is an index of all the memory locations of interest within a bin. For BE that is an xlsx or cry file. For Tunerpro it is an xdf file.

Look for GUFB.xlsx, on here, openeec or eecanalyzer.net. I ccan load it here if need be when next on my pc.

A strategy document describes the process control or logic for a group of bins. GUFB is a strategy that covers a9l.bin among others. GHAJ0 is the strategy for CARD QUIK COSY and ANTI bins. All bins under a strategy have the same memory locations and code sequences, just the tune data changes.

I am just curious on the BL disassembler, since mpaton actually mentioned he added new features to it, so I was wondering what was his original motivation for using BL instead of SAD

BL predates SAD by a long time. Mpaton can speak to other reasons he may have.

And I'm actually more comfortable with linux command line than in windows (unless with GUI). Currently using Virtual Box on my main laptop.

Tvrfan is on linux. He was posting both win and linux builds. I'm sure he could do so some more.

I just drag the bin and drop it on the exe under windows. I don't use the sadwin gui.

[jsa]

having revisited the post again and seeing this quote, I think may be it would also be a great exercise for me to see if I can add some features. Also reading this allows me to affirm the fundamental things I have been reading lately. But it's 2020 and you guys have probably updated it several times over. Anyways i'll take a look again.

2015, a lot of water has gone under the bridge since that post.

Current work on SAD centers around making sure 8065 specific memory access modes are correctly handled. Correct sizing of arguments. Data block dimensions. Expanding structure commands for various ways of encoding.

Look at the gufb dir and cmt files on open eec in combo with the gufb.xlxs definition. Be aware they would be SAD V3 vintage, SAD V4 syntax has changed quite a bit. Most of the posts on here are V3 and earlier.

Next run a bin without dir or cmt through SAD to see the default output in lst and msg files. Take note of the msg file, parts can be copy/pasted/altered to generate a dir file.

[motorhead1991]

While you're at it, come join the telegram group if you want a more chatroom-type interaction. The link is down in my signature.

I would also like to welcome you to the rabbits den . I created the OpenEEC idea to gather the information all on one place, outside of a forum for easy backups and revision. If you're unfamiliar with GIT, I can help with that too.

[tvrfan]

Welcome to the world of geek...................

I've been doing this FAR TOO LONG, and people like jsa WON'T LET ME ESCAPE !! (just joking).

Seriously, welcome, and we are all of a similar aim, to try to get a full decode of all EEC-IV and V binaries. For me personally, I no longer own any qualifying Ford cars, but it's still something to go for as a project, and it's like a complex puzzle to solve. SAD is ongoing....still some bugs, and still adding features.

Over the years we have collected quite a lot of data, and motorhead has created OpenEEC to keep that data. I wanted to be able to automatically dissasemble EEC code, and it's a tough ask, as they got more complex and bigger. Some hardware details are STILL not completely clear either.

I always suggest to start with AA (in OpenEEC) which was my first EEC_IV box. Not because it's mine, but becuase, a) it's the smallest code found (so far), b) it has no EGO or feedback sensors, and is pretty straightforward, for a simple 2 valve V6 with a distributor. Always bank fired.

So that's a 'foundation' step to get started and get a feel for how these boxes work, whilst you are reading. After that join and suggest whatever, we are always open to new ideas...

you can email me too, I'll try to answer your questions.... tvrfan99 at gmail (done this way as I HATE bots ...)

[baba_banana]

Eectech is relevant to its time in history. It does not give any insight into changes in later bins. You can pretty much ignore anything it says about 8096, just read the software manual shared here recently.

A definition is an index of all the memory locations of interest within a bin. For BE that is an xlsx or cry file. For Tunerpro it is an xdf file.

Look for GUFB.xlsx, on here, openeec or eecanalyzer.net. I ccan load it here if need be when next on my pc.

A strategy document describes the process control or logic for a group of bins. GUFB is a strategy that covers a9l.bin among others. GHAJ0 is the strategy for CARD QUIK COSY and ANTI bins. All bins under a strategy have the same memory locations and code sequences, just the tune data changes.

Wow ok looks like i've got much more information to be acquainted with. I'll look through everything and just explore both versions of the tool and perhaps pick up more info relevant to the stage i'm in.

[baba_banana]

by the way, does anyone have an efficient way of removing these hex sockets from my ECU hardware? it's not a priority right now but definitely on my to-do list.
the only bit that fits from my screwdriver set is a 5.5mm . . I'm thinking of getting an electric screwdriver or mini ratchet so I can get more torque, but maybe I need a smaller bit too.

https://imgur.com/U6dNk86]

[motorhead1991]

by the way, does anyone have an efficient way of removing these hex sockets from my ECU hardware? it's not a priority right now but definitely on my to-do list.
the only bit that fits from my screwdriver set is a 5.5mm . . I'm thinking of getting an electric screwdriver or mini ratchet so I can get more torque, but maybe I need a smaller bit too.

https://imgur.com/U6dNk86]

5.5mm is correct. Torque is all you need.

[jsa]

Yeah, battery screwdriver, screwdriver handle for a socket or ratchet, all work well.

[tvrfan]

I can't remember if heads are plain hex, or the 'star' pattern.... ? Maybe I'm confusing with something else....maybe Euro vs US boxes ? Have a good look with a magnifier to confirm.... Hex driver will easily chew up a star head and then it gets REALLY hard to undo. Been there.....(not on an EEC box though).

EDIT - later. Ah, I see looking at your pic that it's a cast style box. Some EEC boxes are folded steel or more 'tin' like, and have socket head bolts, and I'm pretty sure they are 'star' pattern, and not hex. Sorry bout that.

[baba_banana]

Hey guys,

I'm finally back again! I had to let it all soak in and think about what my next course of action is (along with some other misc/admin stuff). Really wished I had come back earlier! But I feel more obligated if I had gotten my ankles wet at least.

I've tried out a couple of bin files on SAD and SAD806x, I couldn't open the files in SAD (says can't find starting bank, corrupted) while everything shows the right information on the 'Binary and definition information panel', but I don't see any of the disassembly.

I'm I doing something wrong or lacking the use of some files (def or strategy files)? I would look into the docs later to get an overview but it would be great if someone could clarify if my files are good or the program can't read it or I'm lacking some files.

thanks

attached are the files forementioned

[baba_banana]

While you're at it, come join the telegram group if you want a more chatroom-type interaction. The link is down in my signature.

I would also like to welcome you to the rabbits den . I created the OpenEEC idea to gather the information all on one place, outside of a forum for easy backups and revision. If you're unfamiliar with GIT, I can help with that too.

thanks for the welcome! it's been quite a while since I used GIT; definitely need some refresher, especially on the vital commands!

I'm surprised that eec-tuning is mainly Ford dudes!

[baba_banana]

So after going through some info you guys provided and Decipha's write up, specifically on calibration and strategies, I'm assuming I have to do things the hard way and find the relevant hexes or words myself to create my own definition file since strategy MZAG0 is probably not supported?

Still doesn't really explain why I can't see the disasm output though.

[motorhead1991]

That is generally the path you'd need to take for an unsupported bin.

You're not seeing output from SAD? Generally that points to a corrupt comment file or another fault in disassembly.

The messages file might be able to tell you what's going on.

[baba_banana]

That is generally the path you'd need to take for an unsupported bin.

You're not seeing output from SAD? Generally that points to a corrupt comment file or another fault in disassembly.

The messages file might be able to tell you what's going on.

yea this is the output of the message file


# ----------------------------
# SAD Version 4.0.6 (22 Jun 2020)
# ----------------------------

# Input file is 'qbl1.bin'

# File is 216K (0x36000) bytes


Cannot find a Start bank [bank 8]
Probably binary file is corrupt
Abandoned !!

[mpaton]

but it would be great if someone could clarify if my files are good or the program can't read it or I'm lacking some files.

thanks

attached are the files forementioned

Your files are good.

[jsa]

I'm I doing something wrong or lacking the use of some files (def or strategy files)? I would look into the docs later to get an overview but it would be great if someone could clarify if my files are good or the program can't read it or I'm lacking some files.

thanks

attached are the files forementioned

Did these files come from a WDS disk or system?

So after going through some info you guys provided and Decipha's write up, specifically on calibration and strategies, I'm assuming I have to do things the hard way and find the relevant hexes or words myself to create my own definition file since strategy MZAG0 is probably not supported?

Still doesn't really explain why I can't see the disasm output though.

Yes, that is the nature of definition creation. Comparing code from public disassemblies will help identity parameters in your bin.
Reading the available strategy docs will help identify parameters.
My preferred thin end of the wedge is finding the AD_ read subroutine, then AD channel structure, then work out what each channel is for.

SAD output is another issue.

SAD V3.07 is the last version that does any disassembly on those files. But 3.07 lacks odd direct memory mode awareness.

[tvrfan]

Guys,

To let you all know, SAD doesn't work on these bins as they only have 3 detectable banks. I coded SAD to reject a 3 bank bin as it can't possibly be valid (1 bank select bit = 2 banks, 2 bits = 4 banks). [NB. But I must check if there's a bug causing 4th bank to be missed]

Reason is that Hardware design requires the interrupt vectors to be present (0x2010 - 0x205f) even if bank is otherwise empty.

However as there may be a few of these floating around, and whoever made the bin may have dropped off the 'empty' bank, I'll change SAD to allow a '3 + Missing' format.

(for info, spotted at top. SAD is written in plain 'C' but linker issues between Linux and Win32 meant it was easier to label as C++. Original BL disassembler is also in plain C, and I have a copy somewhere, if it's not already in OpenEEC.)

[mpaton]

You need to get out more and read more bins if you think there is anything missing here.

You've either forgotten or never realized that the way these bin files are put together is full of more history than sense. There is no canonical way that the banks are put in the "bin" file. People made things up as they went along.

You've probably assumed that the banks are in there in some order that you think is a convention and it isn't.

[tvrfan]

Huh ??? Don't understand......

SAD doesn't assume any order or conventions, as you rightly say, there's "no standards". If there is a fourth bank in that file (which I haven't checked in detail yet) then there's a bug in my 'bank finder' code.

SAD first scans the bin file for 'fingerprint' bank start, which is a jump followed by the interrupt vectors, up to 4 times. They MUST be there, as is specified in all the Ford documents. Given the messing about with the 'short bank 1' format a couple of months ago, I'm not surprised that another bin 'format' has popped up....

It is also quite possible that there are bin files with 3 banks, which I didn't cater for (and should have done). But if there's 3 in the file, it MUST actually be a 4 bank eec box in reality .....

[ADDED later]

Now I think about it some more, there ARE some assumptions made, which I shall see if I can remove. The 'short bank' RZAS5... series problem was actually down to a bank size assumption.....but in the end there has to be some things.... for example that a two bank bin is always bank 1 and 8 (either way around), and that SAD cannot always tell which bank is which on a 4 bank (or a 3 bank..), so has to fall back to common defaults.

But good idea to add some more smarts around bank detection.

[and later still...] OK, that's a bug. SAD reckons that the first bank (in the file) has an incomplete set of interrupt vectors.....which it doesn't seem to......need to find out why.

[tvrfan]

I've found a jump calculation error in the check for the interrupt vectors, where a 'negative' value (top bit set) causes the wrong answer, but it only happens when there is no ROMBANK prefix. So now I know why. This has been hiding for a long time. I haven't changed this code, even for the RZAS bin fix...... [Yes, I know there was all this debate about whether long jumps are signed or not....which is why I put it in quotes]

in qlb1 this is in first bank (the missed bank, which is bank 0)

Code: Select all

   I0_HSI_FIFO:
0209c: 10,01              rombk 1
0209e: e7,74,b7           jump  1d815            goto 1d815;

   I0_External:
020a1: e7,53,84           jump  0a4f7            goto 0a4f7;          ## ok when listed, but WRONG in bank find check.....

SO confirm there's nothing wrong with the bin file, and it's a bug. It may affect other bins too.

[baba_banana]

Hi guys

So i guess after a week or so (not sure how long, time passes fast, annoyingly or not) of AWOL, I have not deeply analyzed any bins yet but I did survey the one-bank bins like AA that tvrfan mentions. But I've been scrutinizing the docs again to gain a better, high-level idea of the data flow within the ECU (the 2 stack pointer, General File Register, ROM etc).

I'm turning my attention back to the overall data flow between the vehicle and the ECU as I dig further into I/Os (SFRs) and interrupts.

I've read some general EEC books and, correct me if I'm wrong, that most data signals flow from the sensors to be converted at the AD convertor before being accepted at the I/O of the microprocessor to be processed and output. I'm kind of confused how the CART or CAN fit into all of these. I assume that for Ford EEC-V that the CART protocol is Ford's version of OBDII? And CART/OBDII is just a protocol that promotes communication between the different control units in the car and they do not partake in the flow of signals from the sensors relevant to their respective control units? So not all signal inputs or outputs from the Engine Control Unit are sent out to the CANbus, likewise for the Transmission Control Unit etc, unless programmer/protocol dictates so? (i've seen quite a few of CAN hack videos, so I have an idea of how people try to interpret readings from live data)

Assuming I have a Ford EECV '99-'03 ECU.

In conclusion, just wanna get a solid picture of the transceiving and processing of signals . . am thinking about getting the Ford Fuel Inj and EECIV book by Probst, any opinions on that too?

I've received a message from BillMarkVIII saying there's a EECV reference 1991? Didn't manage to see that in any drives, maybe someone could point it out to me.

thanks!

[jsa]

I've read some general EEC books and, correct me if I'm wrong, that most data signals flow from the sensors to be converted at the AD convertor before being accepted at the I/O of the microprocessor to be processed and output.

Correct not much happens in an EEC until inputs are read.
Generally...
Digital inputs like PIP trigger an interrupt that runs code assigned by the interrupt vector.
ADC is primarily a background process that runs when interrupt processes are not being serviced.

I'm kind of confused how the CART or CAN fit into all of these. I assume that for Ford EEC-V that the CART protocol is Ford's version of OBDII?

CART is not OBDII.
Read the LHBH1 strategy doc for some info on CART.
CART depends on a CART capable chip being part of the hardware selected for a particular EEC. Some 8061 very few 8065 have CART chips. I use numbers intentionally as it is not entirely clear what Ford intended EEC-IV and EEC-V to mean.
EBC is typically used with 8065's.

And CART/OBDII is just a protocol that promotes communication between the different control units in the car and they do not partake in the flow of signals from the sensors relevant to their respective control units?

CART is not setup so that the EEC receives signals from sensors via CART.
OBDII was intended for diagnostics not engine control.
OBDII is a subset of the data that is available on CANbus.

So not all signal inputs or outputs from the Engine Control Unit are sent out to the CANbus, likewise for the Transmission Control Unit etc, unless programmer/protocol dictates so? (i've seen quite a few of CAN hack videos, so I have an idea of how people try to interpret readings from live data)

Yes, whatever Ford decided to program the EEC to transmit or respond to.

In conclusion, just wanna get a solid picture of the transceiving and processing of signals . .

Look at the disassembled code to see what is going on. It will be strategy dependent to some extent.

I've received a message from BillMarkVIII saying there's a EECV reference 1991? Didn't manage to see that in any drives, maybe someone could point it out to me.

Yes, big thanks to BillMarkVIII.
Check out the chip pictures and associated descriptions.
Ironman has it hosted on his Gdrive;
https://drive.google.com/open?id=0B3c0I ... 2pyU2VnRnc

[tvrfan]

Probst Book - if it's the dark blue one, I had this for a while. It doesn't give much at all on how the innards and communication protocols work, it does give some sensor data, but only really from a view of 'external tuning' (i.e. fiddling with the sensors). So not a lot of use for EEC internals. It's REALLY good for the K-series mechanical setup though (continuous injection) and how that works, but that's not what you are after I guess. K series is however a really neat design, used on VW, Audi, Ford, Merc, Ferrari, <others> if you're interested, but not relevant to EEC.

Sensors - most of the sensors do work by voltage (i.e. via the A/D in the CPU), but the Atmo Pressure sensor, often used for a MAP (Manifold Absolute Pressure) works by FREQUENCY, so you will see that the code does a lot with the IO_timer, in an interrupt handler. It's normally connected to one of the HSI interrupts (High Speed Input), like the PIP signal for sparks, which also does a lot with timer, to work out the instantaneous RPM. Also most of these inputs are subsequently filtered/averaged to stop and wild swings or glitches, and limit the max rate of change. So if you can find these bits in the code, you are well on the way to understanding the input processing.

For scanning raw binaries I use Ghex (Linux) but there's several Windows alternatives, WxhexEditor does a lot of stuff.

[baba_banana]

CART is not OBDII.
Read the LHBH1 strategy doc for some info on CART.

thanks for the rec/reminder, I ignored the strategy files because I downloaded 1 in Microsoft Words that contains gibberish.

Anyways I took a look at it, seems like CART/RAM contains serial input/output that allows EEC to interface with other vehicle microcomputers, mention a lot on off/on board diagnostics. Not sure if the serial I/O on CART/RAM is the same memory-map on the 8065, but I think it's easy to find out. But just saying CART gives the impression of it being linked to a CANbus or perhaps what the books mention as Data Link Connector via SBDS, which is still controlled by the EEC right? Ultimately the EEC takes precedence before all other operations.

CART depends on a CART capable chip being part of the hardware selected for a particular EEC. Some 8061 very few 8065 have CART chips. I use numbers intentionally as it is not entirely clear what Ford intended EEC-IV and EEC-V to mean.
EBC is typically used with 8065's.

If very few 8065 have CART chips then do they or how do they communicate with the other vehicle microcomputers? Directly via some sort of CANbus? But there will be something like an SBDS giving privilege to microcomputers to transceive right?

Look at the disassembled code to see what is going on.

Yea i started to look at the disassembled code of AA again. Haven gotten deep into the interrupts from the start yet; but do you guys use any program to trace the function calls? I don't mind using pen and paper while refering to docs but options would be great.

It will be strategy dependent to some extent

It's not really evident to me yet how different strategies affect I/Os etc but I assume that strategies are tunes and some cars use different parameters for the same functions or have different formulas depending on the engine displacement etc.

[baba_banana]

Probst Book - if it's the dark blue one, I had this for a while. It doesn't give much at all on how the innards and communication protocols work, it does give some sensor data, but only really from a view of 'external tuning' (i.e. fiddling with the sensors). So not a lot of use for EEC internals. It's REALLY good for the K-series mechanical setup though (continuous injection) and how that works, but that's not what you are after I guess. K series is however a really neat design, used on VW, Audi, Ford, Merc, Ferrari, <others> if you're interested, but not relevant to EEC.

Yea that sounds cool, but probably not right now.. my focus is on Ford trucks.

Sensors - most of the sensors do work by voltage (i.e. via the A/D in the CPU), but the Atmo Pressure sensor, often used for a MAP (Manifold Absolute Pressure) works by FREQUENCY, so you will see that the code does a lot with the IO_timer, in an interrupt handler. It's normally connected to one of the HSI interrupts (High Speed Input), like the PIP signal for sparks, which also does a lot with timer, to work out the instantaneous RPM. Also most of these inputs are subsequently filtered/averaged to stop and wild swings or glitches, and limit the max rate of change. So if you can find these bits in the code, you are well on the way to understanding the input processing.

I see, it's clearer to me now as I read the section on Data Communication Link and PID tables and Bimap definitions. perhaps if I dig deeper like you say, I can see for myself how the data get transferred and sent to the frame. But jsa did mention something about most EECIV EECV not having CART, i'm looking at '99-03 models, so I would have to investigate further

For scanning raw binaries I use Ghex (Linux) but there's several Windows alternatives, WxhexEditor does a lot of stuff.

What do you mean scanning raw binaries? Do you mean tracing the calls and jumps? I was wondering if y'all use any programs to make the flow visually clearer rather than use pen/paper.

[baba_banana]

here's an example: https://www.youtube.com/watch?v=WEsnOIU ... wQ&index=7

would be convenient to have a control flow graph to navigate. Radare2 is opensource compared to IDApro