EECTuning.org

I also wonder why Ford didn't simply do a LDW to get both registers in one hit Bits 8-15 of some special function registers are only accessible using a word sized read or write of an even valued memory address. This feature of the MCU looks like it's only used on the 8065 (for example, see the HSO ...

It's not obfuscation, just a neat way of saving 8 state times. I doubt you could automate commenting this out in the disassembly due to its subtlety.

This is just a bit of cute coding by Ford, in this particular instance using SHRDW has saved using SHRW twice (i.e. separately on 0x38 and 0x3A) as the value is 0x38 is not double word sized and the lowermost bits of 0x3A are zero.

Even if the temperature at the sensor is greater than 254 deg F the ACT value is limited in the code to a maximum of 254 deg F.

Providing the first and last input (Y axis) values for the function are set to the maximum and minimum limits of the input variable then there is not going to be a problem as the function's interpolated output value will be limited to be within those values in the function. Problems which occurs in ...

I believe the 4TAB ecu has an 88k rom so I suspect both of the bin files you have are not correct.

I've just issued an updated definition that includes the DFSFLG flag so you will be able to see if DFSO is causing your issue.

Are you sure it's going into DFSO?

Are you allowing the use of the DFSO Profile Correction mode? If you are then the normal DFSO parameters won't disable DFSO if the relevant KAM correction factors have not matured.

OK, from some rummaging around I now think this particular example of OR'ing and XOR'ing with a zero relates to how the BiDi port works at the hardware level. I suspect it's a hangover from programming the port directly rather via a 'image' variable. See the 1985 Intel Microcontroller Handbook secti...

For clarity, it is only with respect to the line at 0x5736 that I meant it was possibly there to waste some state times and not as a rule to be observed for all instances of XOR'ing with a zero.

XORing with a zero doesn't change any bits in the destination register. It's probably done to waste some state times for some reason.

I suspect an error in the code or a bodge to avoid re-compiling the binary because the line at 0x571E is redundant.

The SAFTOT value is the foreground calculated spark advance that is used to generate the Spark Angle Pulse Width (SAPW) value sent to the EDIS module. The ODB-II spark value should track the SAFTOT value very closely as it is derived from the SAFTOT value converted to meet the requirements of the J1...

86GT wrote: ↑

Tue Jun 19, 2018 5:32 pm

Bob is still on a Windows 95 PC

No, I'm not.

No point in checksumming unused areas of ROM and, IIRC, the VID block is excluded.

The multiple bank checksum calculation is the same as single bank checksum with each bank being added in turn. In the BWAK3 strategy the routine is at 0x872D9.

You can only tell by looking at what the various rev limit scalar values are to determine whether a particular rev limiter is used. An example would be if the 'Rev Limit Low Gear Stage 2' (aka NLMTLO_0) parameter was set to a higher rpm than the 'Rev Limit Low Gear Stage 3' (aka NLMTHI_0) parameter ...

The CDAN4 strategy has three ways of limiting the engine speed: Stage 1 - The rpm at which fuel delivery is enriched and spark advance is retarded. Stage 2 - The rpm at which fuel delivery is cut to alternate injectors. Stage 3 - The rpm at which all fuel delivery is cut. Not all the stages are nece...

tvrfan wrote: ↑

Wed Apr 11, 2018 6:04 pm

I haven't entirely worked out what some of the extra chips do either, for example what DUCE stands for

DUty Cycle Expander

Format - I copied the 8096 format, which Ford also use in their handbook. For an easy rule of thumb for reading , I treat the operands as BACKWARDS, like this - - - AD3W, R32, R34, R36 is R36 = R34 + R32 AD3W, op1, op2, op3 is op3 = op2 + op1 In the Intel documentation I have seen this is not their...

Using the AD3W instruction as an example you get the following for adding the values from R34 and R36 and storing the result in R32: ; Object code: ; 44363432 Not very easy to understand which is why we use higher level languages :smile: ; Disassembly listing: ; 44363432 ad3w r32, r34, r36 Note that...

I was expecting a comment about my order of the operands :smile: Section C of the eec-iv pocket reference guide gives the operation of the instruction and the object code format, not the assembly language format. I prefer to see and use assembly code in the style of the Intel macro assemblers for th...

My observations on those examples: AD3W R32, R34, R36 JC 12345 The jump occurs if R32 > 0xFFFF (i.e. the operation is R32 = R34 + R36) CMPW R32, R34 JC 12345 The jump occurs if R32 >= R34 (i.e. set PSW for R32 - R34) SB3W R32, R34, R36 JC 12345 The jump occurs if R32 >= 0 (i.e. the operation is R32 ...

That ecu has a 32k rom so it may be a valid read, just with 24k of junk at the end.

If you look at the subroutine at 0x8099 you'll see that the value in the entry address passed by 0x30 is not necessarily the one that gets used to determine the state of the carry flag. The following four addresses also get used in the subroutine.

I don't think you can realistically expect the disassembler to apply a symbol, or an address, in line 0xB1D3 as it does not know what state the carry flag will be in after the subroutine at 0x8099 has been executed (and would not know unless it simulated the code running with values for the various ...

The jnc is jumping according to the state of the carry flag, the state of which is determined by what's happened in the subroutine at 0x0x8099 not the contents of 0xCF75.

jsa wrote: ↑

Wed Dec 13, 2017 2:56 am

This

Code: Select all

b1cb: 45,41,00,f6,30    ad3w  R30,Rf6,41     R30 = cf75

This is correct, register 0x30 will hold the result of the sum of the value held in register 0xF6 and the value 0x0041.

1 = base
2 = borderline