[tvrfan]

I meant when I have a bug (like the banks not being seen in SAD) , then the bare file is neatly laid out in binary, so I can see if file looks OK...

[jsa]

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.

RAM/CART or RAM/CART/DUCE chip.
The memory map depends on the chip stepping. It is detailed in the pocket reference.
It is not CANbus.

There is DCL which runs on the CART capable chips. Ford Europe would have used FDS2000 diagnostic hardware with that. I don't know what Ford USA used. I have ForDiag which also works with that. The LHBH1 document describes this protocol.

EEC does not control the CART diagnostic hardware. The Diag hardware poles the EEC, triggering a software interrupt in the EEC, then the EEC returns the info.

There is SCP which runs on the EBD capable chips. I see info in the pocket reference. As I understand it, SBDS is the Ford diagnostic hardware for that protocol. Probably WDS and IDS systems.
It is not CANbus.

CANbus- I have not seen any info on how that is implemented in late EEC's. Anyone got anything to share?

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?

Very few 8065 have CART because they moved on to EBD chips speaking SCP. Some 8061 got CART, but not all. Study the handbook. Other CAR modules could talk to the EEC using SCP. I've not delved into EBD bins enough to understand the capabilities entirely.

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.

AA does not have CART.
P3M has CART, so does M0M2.
Motorhead has done some work on M0M2, but not the CART stuff in it. Check out openeec on github.

I usually end up with multiple windows open to have all the relevant code visible. I use notetab lite as my text editor to view the multiple instances of the SAD disassembly LST file.

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.

If a strategy needs more I/O than available on 8065 or 8061 then peripheral chips with additional I/O are part of the hardware configuration. If the uP is a bit strapped for throughput, then a peripheral chip can take some of the load.

The Scalar SARCHG sets the engine capacity. Search the strategy docs for the details. Very loosely there are Speed Density strategies and there are MAF strategies. MAF strategies all have very similar formulas with Scalars, Functions and Tables to adjust the tune.

[jsa]

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

That looks interesting.

At one stage i googled for C aware flow chart software. That turned up a couple options but seemed like the sort of thing to do once a disassembly was 100%.

[baba_banana]

Very few 8065 have CART because they moved on to EBD chips speaking SCP. Some 8061 got CART, but not all. Study the handbook. Other CAR modules could talk to the EEC using SCP. I've not delved into EBD bins enough to understand the capabilities entirely.

cool, I see more mentioning of EBC (EEC Bus Controller) in the pocket ref and in the IC arch than in the software manual (which left out the chapter on EBC) and strategy doc. There's more comprehensive material on DLC in the strategy which I'll look into and compare with the SCP to see how things fit together.

I usually end up with multiple windows open to have all the relevant code visible. I use notetab lite as my text editor to view the multiple instances of the SAD disassembly LST file.

yea, that would work for me. I was thinking of printing as well.

[tvrfan]

Just to confirm, early bins/boxes had no CAN or OBDII or any external info bus at all. They had a single 'test' input (which was grounded for one second) and a single very low speed error output, designed for a buzzer or lamp, and error codes were groups of pulses which could be counted by eye/ear. No immediate info at all. AA is like that. CAN bus is much newer, and I'm tempted to say AFTER EEC-IV/V (not quite true I guess, but correct in principle...) The only way to get data out of these boxes is via a Ford proprietary unit which plugs in the back of the box (the J3 port). Gradually more diagnostic output was added, OBDII I think was government mandated, and I thought still mainly test ouput ??

So don't expect much, especially on simpler boxes. This basic test method is documented in several places on the web.

[baba_banana]

Just to confirm, early bins/boxes had no CAN or OBDII or any external info bus at all. They had a single 'test' input (which was grounded for one second) and a single very low speed error output, designed for a buzzer or lamp, and error codes were groups of pulses which could be counted by eye/ear. No immediate info at all. AA is like that. CAN bus is much newer, and I'm tempted to say AFTER EEC-IV/V (not quite true I guess, but correct in principle...) The only way to get data out of these boxes is via a Ford proprietary unit which plugs in the back of the box (the J3 port). Gradually more diagnostic output was added, OBDII I think was government mandated, and I thought still mainly test ouput ??

So don't expect much, especially on simpler boxes. This basic test method is documented in several places on the web.

ok ok i see. I'll read more on SCP and look into the method of data retrieval via the box/port

edit: doesn't SCP have hi/low wire twisted together for data output to modules? I read that it's easier to get data out as there's no need for scan tool verification

[motorhead1991]

I'm partial to Notepad++ myself...

[jsa]

edit: doesn't SCP have hi/low wire twisted together for data output to modules? I read that it's easier to get data out as there's no need for scan tool verification

Ford used a RS-485 transceiver as the interface between CART chip and vehicle wiring. So all the rules for wiring RS-485 apply to CART.
I expect EBC chips and SCP would be similar, subject to laying eyeballs on that hardware.

TVRfan was talking about STI / STO which are the blink codes, and consoles that plugged into the J3 port as the only comms method for early boxes. Consoles were basically Ford's test and development tools.

QH in some ways is a miniaturized console.

[baba_banana]

I expect EBC chips and SCP would be similar, subject to laying eyeballs on that hardware.

but from program code, i'll be able to understand what packet I get from the DLC is related to which engine function right?

Anyways, I was looking at AA and CRAJ0, seems like the disassembly doesn't follow the assembler format, which specifies LDW offset(indexreg), breg. . but i guess you guys are following the instruction operation format

ldw.png

ldw_IS.png

it's fine with me. But I don't see the manuals defining what the word "MB" is.

Thanks for being so patient with me, i'm pretty embarrassing a noob.

I'm partial to Notepad++ myself...

currently using it too. I reckon i should just start grinding and say fk it.

[jsa]

but from program code, i'll be able to understand what packet I get from the DLC is related to which engine function right?

Yes

But I don't see the manuals defining what the word "MB" is.

Mode Bit... short indexed or long indexed.

I reckon i should just start grinding and say fk it.

Go for it.

[baba_banana]

Mode Bit... short indexed or long indexed.

ok i see.. i'll look into it later, looks pretty straightforward.

I was looking at AA 2039: xorb R2, 40 . . so I guess 40 = 0100 0000 while R2 = 0000 0000 so xorb -> R2 = 0100 0000 .. so I suppose that's bit 6 == LSO_6? Comment says CPU_OK ^=1 which is hardware watchdog -keep alive signal. . did tvr know this from docs or was this found out after some detective work?

further down i see something similar yet strange like ROM_code = 1. . care to explain? thanks

[jsa]

I was looking at AA 2039: xorb R2, 40 . . so I guess 40 = 0100 0000 while R2 = 0000 0000 so xorb -> R2 = 0100 0000 .. so I suppose that's bit 6 == LSO_6?

Including code in posts is good...

Code: Select all

2039: 95,40,02            xorb  R2,40            CPU_OK ^= 1;
203c: 66,31,34            ad2w  R34,[R30++]      R34 += [R30++];                   # add each word
203f: 88,32,30            cmpw  R30,R32          
2042: da,ee               jle   2032             if (R30 <= R32) goto 2032;        #[Signed]
2044: 89,00,00,34         cmpw  R34,0            
2048: df,04               je    204e             if (R34 != 0)  {                  # if result not zero, then
204a: 81,00,02,16         orw   R16,200          ROM_code = 1; }                   # ROM Checksum fail
204e: 20,12               sjmp  2062             goto 2062;
.
.
2050: 00,20               word   2000            ROMStart                          # Checksum segments
.
.
205e: ff,3f               word   3fff            ROMEnd

Yes, B6_LSO or B6_R2 or whatever you want to define it as using SYM in DIR.

Comment says CPU_OK ^=1 which is hardware watchdog -keep alive signal. . did tvr know this from docs or was this found out after some detective work?

Nothing in the docs states that it is CPU_OK. EDIT: Referring to B6_R2.
TVRfan has decided that is the purpose of it based on what the AA code is doing.

further down i see something similar yet strange like ROM_code = 1. . care to explain? thanks

Do you see the loop summing everything from x2000 to x3fff?
Checksum must equal zero, do you see the compare of the sum with zero?
Not equal zero must be checksum failure of the ROM range x2000 to x3fff.

[tvrfan]

It IS in the hardware manual , page 6-84, WATCHDOG TIMER.

CPU_OK (bit 6 register 2)
The idea is that if something goes wrong and the system locks up (hardware or software) then the watchdog timer forces a hardware reset, and a restart. So every er.... (it's in there somewhere...) 65,000 ? clock cycles, this bit has to be flipped/changed to keep the watchdog from resetting the system. I decided to call it CPU_OK. I guess you could call it WATCHDOG_RESET instead.... ALL bins have this requirement 8061 and 8065, I think actual detail timing may be a bit different, but it's still there. This is linked with a write to Register 5, which is the WATCHDOG_TIMER, which is also reset at the same time. I never did quite work out the hardware details of why there are two things to reset, but you will see this in all bins. Bit 6 could be watchdog timer overflow or something like that, not sure.

You will see this in a few places in startup, and then in the main loop (which runs all the calculation tasks) at 0x2156 onwards in AA. The time expired check is at 0x2118. An XOR (exclusive or) simply flips the bit state, which is enough to register as a write and a reset.


Register R16 (AA).
After analysing the code, I realised that R16 is used as 16 separate flag bits for FAIL states for output codes (the slow test ones), and the box first does a RAM test and a ROM checksum test to verify its hardware is OK. 0x204a is a ROM checksum fail. The fail flags for the sensors (via A/D inputs) is next door in R18.

SAD has the functionality to name individual bits (=flags) anywhere, and this is used a lot in the EEC code to mark events and states.

[baba_banana]

Including code in posts is good...

thanks, will do. .

Do you see the loop summing everything from x2000 to x3fff?
Checksum must equal zero, do you see the compare of the sum with zero?
Not equal zero must be checksum failure of the ROM range x2000 to x3fff.

yea i went through it but i'm not familiar with checksum but i know it's some sorta verification for the ecu or something.

I reviewed my addressing modes just now and looked through the beginning lines again.

Code: Select all

 203c: 66,31,34            ad2w  R34,[R30++]      R34 += [R30++];                   # add each word

i'm I right to say that after the disassembler read the mode bit, it clears it, hence it becomes 0011 0000, interpreted as 30?
kinda uncertain because I couldn't find any docs online that clarifies this. And it seems like it's the only line that uses bit 1 in mode field with a register that's not 0.

So if my understanding of addressing modes are right, then at 203c, R30 has address 2000 which is then accessed to get the values "e7,1d,00", which is assigned to R34 and value in R30 is incremented twice to 2002?

but it seems wrong if I read ahead to line 2044 . . unless the loop at line 2042 requires the processor to run through to the end of file, which is why tvr mentions the flipping of "CPU_OK" in line 2032 and the increment of R30 in 203c..

Code: Select all

2026: a3,01,50,20,30      ldw   R30,[R0+2050]    R30 = ROMStart;
202b: a3,01,5e,20,32      ldw   R32,[R0+205e]    R32 = ROMEnd;                     # ROM checksum loop start and stop (2000-3fff)
2030: 01,34               clrw  R34              R34 = 0;
2032: 95,40,02            xorb  R2,40            CPU_OK ^= 1;                      # Flip CPU_OK and back 
2035: ff                  nop                    
2036: ff                  nop                    
2037: 11,05               clrb  R5               WDG_Timer = 0;                    # Watchdog Timer reset
2039: 95,40,02            xorb  R2,40            CPU_OK ^= 1;
203c: 66,31,34            ad2w  R34,[R30++]      R34 += [R30++];                   # add each word
203f: 88,32,30            cmpw  R30,R32          
2042: da,ee               jle   2032             if (R30 <= R32) goto 2032;
2044: 89,00,00,34         cmpw  R34,0            
2048: df,04               je    204e             if (R34 != 0)  {                  # if result not zero, then
204a: 81,00,02,16         orw   R16,200          ROM_code = 1; }                   # ROM Checksum fail
204e: 20,12               sjmp  2062             goto 2062;

[tvrfan]

Checksums - these are used all over the place in software designs, everything from verification of something, to signatures, to indexes of data. Checksums can be simple additions through to complicated maths tricks, depending what is required.

For the EEC boxes, the entire contents of the ROM (0x2000-0x3fff for AA, 0x2000-0x9fff for A9L, etc) are simply added up byte by byte, or word by word (0x203C in AA) and any overflow is ignored, so the result 'wraps' in 16 bits. The value at word 0x200a is adjusted at build time so that if everything adds up correctly, the result is zero. That's an easy way to say "hey this ROM content looks good..."

You can see that RAM is tested by setting a couple of different patterns, and checking that reading back gives the same pattern as was written across a defined address range.

The same loops exist (with various small changes) in all bins. Later bins also have a check for powered RAM (KAM = keep alive memory) by special pattern written to defined locations, and multibanks do a separate checksum for each the banks.

Yes, square brackets means an INDIRECT operation-
DIRECT means (LDW R30,R32;) put the value of R30 into R32.
INDIRECT means (LDW [R30],R32) put the value at the ADDRESS stored in R30 into R32, and
LDW [R30++],R32, means put the value at the ADDRESS stored in R30 into R32, and increment R30 to point to the next value afterwards.

Autoincrements (like [R30++]) means increment the register R30 by TWO if it's a word operation, or ONE if it's a byte operation. This is specifically designed for efficient loops....R30 then always points to the next item after each opcode (LDW..) is finished.

[jsa]

yea i went through it but i'm not familiar with checksum but i know it's some sorta verification for the ecu or something.

A previous post
http://eectuning.org/forums/viewtopic.p ... 13#p133020

Search in the strategy documents for the term checksum. Plenty of info.

I reviewed my addressing modes just now and looked through the beginning lines again.

Code: Select all

 203c: 66,31,34            ad2w  R34,[R30++]      R34 += [R30++];                   # add each word

i'm I right to say that after the disassembler read the mode bit, it clears it, hence it becomes 0011 0000, interpreted as 30?

Yes, word op, bit 1 set... it's a memory mode for word R30.

kinda uncertain because I couldn't find any docs online that clarifies this. And it seems like it's the only line that uses bit 1 in mode field with a register that's not 0.

SAD is following the behavior described in the handbook and manuals.

So if my understanding of addressing modes are right, then at 203c, R30 has address 2000 which is then accessed to get the values "e7,1d,00", which is assigned to R34 and value in R30 is incremented twice to 2002?

It loops until 2000-3fff are added one word at a time. L203F tests for completion of the loop. L2042 jumps or continues dependant on the test result.

Code: Select all

2026: a3,01,50,20,30      ldw   R30,[R0+2050]    R30 = ROMStart;
202b: a3,01,5e,20,32      ldw   R32,[R0+205e]    R32 = ROMEnd;                     # ROM checksum loop start and stop (2000-3fff)
2030: 01,34               clrw  R34              R34 = 0;
2032: 95,40,02            xorb  R2,40            CPU_OK ^= 1;                      # Flip CPU_OK and back 
2035: ff                  nop                    
2036: ff                  nop                    
2037: 11,05               clrb  R5               WDG_Timer = 0;                    # Watchdog Timer reset
2039: 95,40,02            xorb  R2,40            CPU_OK ^= 1;
203c: 66,31,34            ad2w  R34,[R30++]      R34 += [R30++];                   # add each word
203f: 88,32,30            cmpw  R30,R32          
2042: da,ee               jle   2032             if (R30 <= R32) goto 2032;
2044: 89,00,00,34         cmpw  R34,0            
2048: df,04               je    204e             if (R34 != 0)  {                  # if result not zero, then
204a: 81,00,02,16         orw   R16,200          ROM_code = 1; }                   # ROM Checksum fail
204e: 20,12               sjmp  2062             goto 2062;

[sailorbob]

I do not think that LSO Port bit 6 is hardware related to the watchdog timer. For example, in the CBAZA and GHAJ0 strategies LSO Port bit 6 appears to be only used for controlling the aircon cutout relay. Why the bit gets tickled in the AA binary is a mystery to me as the watchdog timer gets reset in several places by instructions either incrementing or clearing it. Maybe in that strategy the LSO line is being used to reset a timer on another chip.

[baba_banana]

Checksums - these are used all over the place in software designs, everything from verification of something, to signatures, to indexes of data. Checksums can be simple additions through to complicated maths tricks, depending what is required.

For the EEC boxes, the entire contents of the ROM (0x2000-0x3fff for AA, 0x2000-0x9fff for A9L, etc) are simply added up byte by byte, or word by word (0x203C in AA) and any overflow is ignored, so the result 'wraps' in 16 bits. The value at word 0x200a is adjusted at build time so that if everything adds up correctly, the result is zero. That's an easy way to say "hey this ROM content looks good..."

You can see that RAM is tested by setting a couple of different patterns, and checking that reading back gives the same pattern as was written across a defined address range.

The same loops exist (with various small changes) in all bins. Later bins also have a check for powered RAM (KAM = keep alive memory) by special pattern written to defined locations, and multibanks do a separate checksum for each the banks.

thanks for the briefing, the concept of RAM testing, wrap arounds (someone on reddit mentioned something like modulo but i havent gotten the time to verify, but I guess something similar is mentioned in a computerphile video I've seen about complements and they prevent overflow) is also new to me but i'm pretty sure it will be good for me. . at first I thought checksum is an automotive term but turns out it's probably used in many places and lower division assembly undergrad class probably didn't talk about it.

Yes, square brackets means an INDIRECT operation-
DIRECT means (LDW R30,R32;) put the value of R30 into R32.
INDIRECT means (LDW [R30],R32) put the value at the ADDRESS stored in R30 into R32, and
LDW [R30++],R32, means put the value at the ADDRESS stored in R30 into R32, and increment R30 to point to the next value afterwards.

Autoincrements (like [R30++]) means increment the register R30 by TWO if it's a word operation, or ONE if it's a byte operation. This is specifically designed for efficient loops....R30 then always points to the next item after each opcode (LDW..) is finished.

Yea I found 2 good videos that talk about it algorithmically along with the practice. I just had to internalize the syntax I saw in the manual and our code and also to reflect on why indirect addressing is use. . it makes sense because the processor can only compute from the registers while the PC iterates through the instructions based on the address, so that's probably the sole use of it. .I think there's more to elaborate but I can't get any "operands" outta my "registers" for now.

[baba_banana]

I reviewed my addressing modes just now and looked through the beginning lines again.

Code: Select all

 203c: 66,31,34            ad2w  R34,[R30++]      R34 += [R30++];                   # add each word

i'm I right to say that after the disassembler read the mode bit, it clears it, hence it becomes 0011 0000, interpreted as 30?

Yes, word op, bit 1 set... it's a memory mode for word R30.

thanks for the confirmation, I tried to find out the workings behind the process but can't seem to see it in the software manual and i'm not sure what to type in google to look for it but it seems right by following the code, I was just worried about edge cases but i guess it's the algorithm that the software designer programmed into it according to manual.

[jsa]

thanks for the confirmation, I tried to find out the workings behind the process but can't seem to see it in the software manual and i'm not sure what to type in google to look for it but it seems right by following the code, I was just worried about edge cases but i guess it's the algorithm that the software designer programmed into it according to manual.

The Intel 8096 manual discusses memory modes as well but does not cover the 806x edge cases. May not give silicon level insight either.

Edge cases continue to cause revisions to SAD. Reported another on the weekend.TVRfan can't get enough of them...he asks for more regularly ;). Definitely keep an eye out for them.

[tvrfan]

'Wraps" - if you count in a limited space, say 16 bits............ start at 0 and go to 65534, 65535 and add another 1, what happens ??
The result goes back to zero, and 'overflow' condition is set in the CPU. (For us geeks, I'm ignoring further details..). This is what I meant by 'wraps'.

This also works in decimal, If you only have two digits -> 0,1,2, ... 98,99, 0,1,2 .... This is the same as modulo(100), which 'wraps' and returns the 'leftover' value (between 0 and 99).

In fact the EEC checksum will 'wrap' many, many, times as it adds up the words........... but it's the final result that's important.

An example - Some of the modern encrytion algorithms (in use on the web, for passwords, security etc.) actually rely on the fact that their calculations 'wrap' and you can't easily go backwards to decode to original values after this happens a few times. Checksums typically do the same thing.

I DON'T ask for more, I *HATE* them.... But either SAD is a working disassembler, or it's not. It's still a work in progress as we go through the various documents (the discovery and web release of them are still quite recent by the way) and find new stuff...
And yes I freely admit, SAD still has bugs, and I rely on others as well to spot them... (jsa has been really good at testing...)

[tvrfan]

I do not think that LSO Port bit 6 is hardware related to the watchdog timer. For example, in the CBAZA and GHAJ0 strategies LSO Port bit 6 appears to be only used for controlling the aircon cutout relay. Why the bit gets tickled in the AA binary is a mystery to me as the watchdog timer gets reset in several places by instructions either incrementing or clearing it. Maybe in that strategy the LSO line is being used to reset a timer on another chip.

Bob,
Yes, I got the label "CPU_OK" off an eec schematic, which shows LSO6 line as AMC/CPU/OK (or 0K) on that diagram. Toggle is in A9L code as well, around every watchdog timer reset, but not in later bins like CARD, or any 8065 as far as I can see. As far as I know AA doesn't have any 'intelligent' chips beside the CPU, as it's a very early basic box.... I thought it might be some kind of extra external reset 'pump' circuit, but now I wonder.....

Here's a comment got from an older A9L listing. LOS loss of signal ? Something else ? Anyone know ?

Code: Select all

26fb: 95,40,02            xorb  R2,40            CPU_OK ^= 1;                      # keep alive
26fe: b0,59,8f            ldb   R8f,R59          Wd_time = R59;                    # update wdog time
2701: 17,05               incb  R5               WDG_Timer++;                      # keep the watchdog at bay
2703: 95,40,02            xorb  R2,40            CPU_OK ^= 1;                      # toggle line 6 (LOS)

[baba_banana]

'Wraps" - if you count in a limited space, say 16 bits............ start at 0 and go to 65534, 65535 and add another 1, what happens ??
The result goes back to zero, and 'overflow' condition is set in the CPU. (For us geeks, I'm ignoring further details..). This is what I meant by 'wraps'.

This also works in decimal, If you only have two digits -> 0,1,2, ... 98,99, 0,1,2 .... This is the same as modulo(100), which 'wraps' and returns the 'leftover' value (between 0 and 99).

right, a clock can only travel thus far before it goes back to 12 again.

An example - Some of the modern encrytion algorithms (in use on the web, for passwords, security etc.) actually rely on the fact that their calculations 'wrap' and you can't easily go backwards to decode to original values after this happens a few times. Checksums typically do the same thing.

Ah I see, that makes sense, but the purpose is different.

I DON'T ask for more, I *HATE* them.... But either SAD is a working disassembler, or it's not. It's still a work in progress as we go through the various documents (the discovery and web release of them are still quite recent by the way) and find new stuff...
And yes I freely admit, SAD still has bugs, and I rely on others as well to spot them... (jsa has been really good at testing...)

No worries! It's a privilege to have you here! We could all improve SAD and its relevant analysis! Hopefully I can reach a stage where I can do more!

[sailorbob]

LOS = Limited Operation Strategy (aka limp home mode)

It could be that in these early ECU's the tickling of LSO Port bit 6 is for LOS control. On EFI-VM115 hardware LSO#6 connects to a 74001MC IC which also connects to the CPU's /reset line. The 74001MC also connects to some of the hybrid circuits.

[jsa]

DUCE chips have LOS built in, that would explain the change to LSO#6 usage in later boxes.

[tvrfan]

LOS = Limited Operation Strategy (aka limp home mode)

It could be that in these early ECU's the tickling of LSO Port bit 6 is for LOS control. On EFI-VM115 hardware LSO#6 connects to a 74001MC IC which also connects to the CPU's /reset line. The 74001MC also connects to some of the hybrid circuits.

DUCE chips have LOS built in, that would explain the change to LSO#6 usage in later boxes.

Ah of course ! I remember that LOS acronym now... thanks Bob.

That makes perfect sense too - I vaguely remember a description of an 'emergency get home' mode where timing and injection was fixed (?), and engine would run, just about. Later boxes with better limp mode with some functionality via extra chip(s) also makes sense, and so not required to reset the timeout in the same way.

(74001 is just a plain 4xNAND gate though isn't it ? I would have expected a monstable - perhaps it does use a capacitor based 'pump' to keep it alive....seen that before.)

No mention of LOS anywhere in those big Ford manuals that I can find.....Ah well, another thing to remember.

I'll change that bit name (R2_B6) to "LOS_RESET" (for 8061) which will be more accurate I reckon.
(AA box is labelled as VM-100 )

[sailorbob]

Page 25 of Tom Cloud's eectch98 document gives a little information on the LOS mode and it says the 74001MC is a multivibrator. The first sentence is wrong though as it says the 8061 watchdog timer provides the pulses to the 74001MC but we know it's the code tickling LSO#6 that does this.

I would not fix the name of 0x02 bit 6 as its use varies depending on the ECU hardware but if you do so then keep it as 'CPU_OK' as that's a better description than 'LOS_RESET'.

[jsa]

I think default naming it LSO_Ch#6 or similar avoids it being incorrect and misleading for a large number of bins.

The user can rename to suit any particular bin.

Not seen DUCE in 32kb or smaller bins, so that could be used to change the default name. Alternatively accessing of the DUCE memory addresses could trigger the change in default name.

[sailorbob]

'lsout_6' is the Ford PID for 0x02 bit 6 (you can guess what they called the other bits ).

[baba_banana]

holy molly. I see lots of discussion and progress been done since I was away. I can't wait to get back to the subject but I drove up from Southern California to Seattle 2 days ago to consider the prospect of relocating here after having to compromise and live in the common area for the past 6 months, I realize that I could've better alternative living situations if I look at the horizon and explored.

Anyways then I realize that to be serious about finding a good location I would have to get a decent SUV. Decided to settle on '90s Japanese SUVs like the Nissan Pathfinder ('93 or ' 95 for around 2 grand) just cuz it looks cool (hard-cover) and I would eventually settle on a Ford anyways. Regardless I probably should keep my options open ( Saw a explorer at 160k miles at the same price range ).

Anyways, fingers crossed, I hope to get back at it rejuvenated for the new year and be in a better residence for the year 2021!