[jamie from oz]

ok that will take a bit to sink in .
(60 pin EEC-V 8065)

so if in your example code 0x84BC has been changed to [r14+d00] and QH is looking at that position to find the data ?

ok so if i have data that is referred to at 0xABFA in the register of [r0+d00] and i want the data to be in the QH payload in free space at 0xEE00 .

i put in Address column A2 = 0xABFA and can have the offset in E2 = 0000 or EE00 ???

i will read throuh it a couple more times and i hadnt looked in the GUFB work sheet that appears to have some instructions that might help the penny drop .

Jamie

[jamie from oz]

ok so i think i found where the code in gufb came from [0x84BB: 1c,c3,15,00,0d,1c]
0x84BB 0x1C
0x84BC 0xC3 st REG_1C,$0D00[REG_14]
0x84BD 0x15
0x84BE 0x00
0x84BF 0x0D
0x84C0 0x1C
so the data column has the string of code that is at that address .

the 0xEE00 goes at B62 for EEC_IV and B127 for EEC_V .

this is in my code
abfa: a3,01,00,0d,24 ldw R24,[R0+d00] R24 = [d00];

so i will have
0xABFA 0xa3
0xABFB 0x01
0xABFC 0x00
0xABFD 0x0d
0xABFE 0x24 .

[jamie from oz]

yes i think i follow after looking at it more

this is the whole sub route that i enter into the address column.
(you had previously mentioned that 1f1c was in the console sub route)

Sub_abfa: " engineering console present ???"
abfa: a3,01,00,0d,24 ldw R24,[R0+d00] R24 = [d00];
abff: 99,3b,25 cmpb R25,3b
ac02: d7,03 jne ac07 if (R25 = 3b) {
ac04: ef,f9,6b call 1800 1800 (); }
ac07: a3,01,f2,1f,38 ldw R38,[R0+1ff2] R38 = [1ff2];
ac0c: 89,1c,1f,38 cmpw R38,1f1c
ac10: d7,03 jne ac15 if (R38 = 1f1c) {
ac12: ef,07,73 call 1f1c 1f1c (); }
ac15: f0 ret return;

by puting this into the QH tab BE knows where it can put its reference to the patch

[jsa]

Attach a spreadsheet with just your QHorse tab here. Then I'll be able to give you better feedback.

[jamie from oz]

ok i have a screen shot .

Patch code xls Screenshot.jpg

[jsa]

ok that will take a bit to sink in .
(60 pin EEC-V 8065)

8065 is the important information.

so if in your example code 0x84BC has been changed to [r14+d00] and QH is looking at that position to find the data ?

R14 is getting the first address from the payload list at 0x84EE.
Say you select GUFB ACT on the Payload tab for logging. BE will put the register address 0xB1 in the payload list starting at 0x84EE.

The code resolves [R14+D00] too [B1+D00]=DB1. The patchcode will copy ACT data from 0xB1 to 0xDB1. BE will read ACT data from 0xDB1 and put it in your log file.

ok so i think i found where the code in gufb came from

Code: Select all

[0x84BB: 1c,c3,15,00,0d,1c]
0x84BB	0x1C	
0x84BC	0xC3	st REG_1C,$0D00[REG_14]
0x84BD	0x15	
0x84BE	0x00	
0x84BF	0x0D	
0x84C0	0x1C	

so the data column has the string of code that is at that address .

Column B DATA has one byte of code in each cell. BE will write that byte of code to the adjacent address in Column A ADDRESS.

the 0xEE00 goes at B62 for EEC_IV and B127 for EEC_V .

Cell B62 would be correct for a GUFB type patch code.
Cell B62 may well work out for your 6DBX, time will tell, more later.
Cell B127 for 8065, it depends on the patchcode space required.
The cell is not dependent on 8061 or 8065.
This note in Cell D62 is key

Code: Select all

This is the marker to tell BE where to put the EEC-fetched payload list. The 1st instruction of the patch code above must reference this address.

this is in my code

Code: Select all

abfa: a3,01,00,0d,24      ldw   R24,[R0+d00]     R24 = [d00];

You have changed the operation address mode. Best to leave it as it was.

(you had previously mentioned that 1f1c was in the console sub route)

Code: Select all

   Sub_abfa:         " engineering console present ???"
abfa: a3,01,00,0d,24      ldw   R24,[R0+d00]     R24 = [d00];
abff: 99,3b,25            cmpb  R25,3b           
ac02: d7,03               jne   ac07             if (R25 = 3b)  {
ac04: ef,f9,6b            call  1800             1800 (); }
ac07: a3,01,f2,1f,38      ldw   R38,[R0+1ff2]    R38 = [1ff2];
ac0c: 89,1c,1f,38         cmpw  R38,1f1c         
ac10: d7,03               jne   ac15             if (R38 = 1f1c)  {
ac12: ef,07,73            call  1f1c             1f1c (); }
ac15: f0                  ret                    return;

by puting this into the QH tab BE knows where it can put its reference to the patch

1F1C yes, and D00 as well. more on it later.

ok i have a screen shot .

Patch code xls Screenshot.jpg

Not much chop, can you paste column A & B to code chunk in a post then.

More background info in the next post.

[jsa]

More background information...

I have this in a 6DBX_CMT.txt file.

Code: Select all

224D # Load the Background Vector List address

237B \n\n #### BACKGROUND VECTOR LIST
237C # Console Sub will be over written with patchcode

A23B # Load Checksum Structure address
A25A # Checksum Failed, set code 511

A25D \n\n #### CHECKSUM ADDRESS STRUCTURE
A25E # Checksum Start Address
A260 # Checksum End Address

ABFA # R24 is a scratch Reg
AC02 # Hi Byte of R24

AC06 \n\n    # JNE   from LAC02 no Console \t83\sABFA
AC07 # R38 is a scratch Reg

AC14 \n\n    # JNE   from LAC10 Console binary Sub1F1C not loaded \t83\sABFA

I have this in a 6DBX_CMT.txt file.

Code: Select all

Sub  A237 "SubA237_Checksum"
Sub  ABFA "SbgABFA_CC_Patch"

A couple things among many happen early on after the EEC boots up;
* The background vector list is loaded and executed
* The checksum of the binary is tested



The Vector List is of interest because the Console routine is typically the first vector and the first in the sub-loops as well.

Searching the disassembly _LST for D00 and 1F1C finds;

Code: Select all

abfa: a3,01,00,0d,24      ldw   R24,[R0+d00]     R24 = [d00];
ac10: d7,03               jne   ac15             if (R38 = 1f1c)  {
ac12: ef,07,73            call  1f1c             1f1c (); }

ABFA is the first address of that Sub.
Searching the disassembly _LST for ABFA finds a number of instances in the vector list;

Code: Select all

237C: fa,ab               vect  abfa             Sub_ABFA
23B2: fa,ab               vect  abfa             Sub_ABFA
23D0: fa,ab               vect  abfa             Sub_ABFA
23F4: fa,ab               vect  abfa             Sub_ABFA

Searching the disassembly _LST for the Vector List start address finds;

Code: Select all

224d: 65,7c,23,38         ad2w  R38,237c         R38 += 237c;                      # Load the Background Vector List address

Confidence that the Console sub has been found is high.

What else gives reason to believe it...

Code: Select all

   SbgABFA_CC_Patch:
abfa: a3,01,00,0d,24      ldw   R24,[R0+d00]     R24 = [d00];                      # R24 is a scratch Reg
abff: 99,3b,25            cmpb  R25,3b           
ac02: d7,03               jne   ac07             if (R25 = 3b)  {                  # Hi Byte of R24
ac04: ef,f9,6b            call  1800             1800 (); }

    # JNE   from LAC02 no Console                                                  SbgABFA_CC_Patch
ac07: a3,01,f2,1f,38      ldw   R38,[R0+1ff2]    R38 = [1ff2];                     # R38 is a scratch Reg
ac0c: 89,1c,1f,38         cmpw  R38,1f1c         
ac10: d7,03               jne   ac15             if (R38 = 1f1c)  {
ac12: ef,07,73            call  1f1c             1f1c (); }

    # JNE   from LAC10 Console binary Sub1F1C not loaded                           SbgABFA_CC_Patch
ac15: f0                  ret                    return;

Having read the EEC manuals you would be aware that D00, 1800, 1FF2 and 1F1C are not the sort of places you find code that normally operates from the ROM chip. The manuals will also allude to memory being reserved for consoles in those areas. So yes that is the console routine. It will be overwritten by patchcode by BE as layed out in the QHorse tab.

GUFB uses R14 as a scratch, all good for 8061, but that is a Special Function Register in 8065. We would wreak havoc if we used R14 as scratch on 8065.

Note R24 and R38 being used as scratch, we will use them in our patch. I see you (Jamie) have R24 already.

The console routine is 28 bytes long, we need to keep that in mind as a patchcode space impact...
GUFB patchcode is much longer than that...more later.



Checksum should be considered as well. BE is supposed to update the checksum when changes are sent to the ROM on the QH.

Checksum normally starts at address 0x2000 so lets search _LST for that;

Code: Select all

 #### CHECKSUM ADDRESS STRUCTURE
a25e: 00,20               word   2000                                              # Checksum Start Address
a260: f0,ff               word   fff0                                              # Checksum End Address
a262: 00,00               word      0

We find some Words or a Structure starting at address A25E.

Searching _LST for A25E finds;

Code: Select all

   SubA237_Checksum:
a237: 01,38               clrw  R38              R38 = 0;
a239: 01,44               clrw  R44              R44 = 0;
a23b: a1,5e,a2,4a         ldw   R4a,a25e         R4a = a25e;                       # Load Checksum Structure address
a23f: 46,4b,00,42         ad3w  R42,R0,[R4a++]   R42 = [R4a++];
a243: df,0d               je    a252             if (R42 != 0)  {
a245: a2,4b,46            ldw   R46,[R4a++]      R46 = [R4a++];
a248: 66,43,44            ad2w  R44,[R42++]      R44 += [R42++];
a24b: 88,46,42            cmpw  R42,R46          
a24e: d1,f8               jleu  a248             if (R42 <= R46) goto a248;
a250: 27,ed               sjmp  a23f             goto a23f; }

a252: 88,44,00            cmpw  R0,R44           
a255: df,05               je    a25c             if (R44 != 0)  {
a257: ef,15,04            call  a66f             Sub_a66f (
a25a: 11,05                     #arg 1              511 ); }                       # Checksum Failed, set code 511
a25c: 20,45               sjmp  a2a3             goto a2a3;

That code adds up words from 0x2000 to 0xFFF0, without carry.
It should ADD up to Zero.
If it adds up to anything else, fail and set code 511.

The patchcode will go to ABFA or NOT. Patchcode length forces us to put some or all patchcode elsewhere.

If patchcode replaced ABFA within the checksum address range. Your DEF would need the correct checksum addresses on the Config tab and BE to do it's part.

From _LST

Code: Select all

edca -> ffff = 0xff  ## fill ## 

The payload list can go anywhere in the fill from EDCA.
Some BINS will limit the upper range of the checksum to something like EDFE, giving the option of having the payload list inside or outside the checksum address range.

6DBX default does not give the option, so the payload list will be in the checksum range.
Config tab needs to be right and BE has to do it's part.

Jamie's selection of EE00 for the Payload List is ok, BUT space is required for the patchcode. So lets go with patchcode space and payload list from EE00 up.

EE00 is a ROM address, that is Read ONLY Memory with regard to the OEM ROM.
Is EE00 a good DatalogOffset choice for payload data to be Written too by the uP...
I have been assured that the QH is supposed to be smart enough to accept writes to read addresses...

I have had better luck using a RAM address for the DatalogOffset.
...so which RAM address...well the Console Sub uses D00 and 1Fxx.
I use D00 for DataloOffset with success for the BINS I've logged.

[jamie from oz]

I think i follow that.

I didn't proceed past the end of the console route because t thought it will need to be different.
ADDRESS DATA
0xABFA 0xA3
0xABFB 0x01
0xABFC 0x00
0xABFD 0xEE
0xABFE 0x24
0xABFF 0x99
0xAC00 0x3b
0xAC01 0x25
0xAC02 0xd7
0xAC03 0x03
0xAC04 0xEF
0xAC05 0xF9
0xAC06 0x6B
0xAC07 0xA3
0xAC08 0x01
0xAC09 0xF2
0xAC0A 0x1F
0xAC0B 0x38
0xAC0C 0x89
0xAC0D 0x1C
0xAC0E 0x1F
0xAC0F 0x38
0xAC10 0xD7
0xAC11 0x03
0xAC12 0xEF
0xAC13 0x07
0xAC14 0x73
0xAC15 0xF0
0xAC16 0xFF
0xAC17 0xFF
0xAC18 0xFF
0xAC19 0xFF
0xAC1A 0xFF
0xABA6 0xFF
0xABA7 0xFF
0xABA8 0xFF
0xABA9 0xFF
0xABAA 0xFF
0xABAB 0xFF
0xABAC 0xFF
0xABAD 0xFF
0xABAE 0xFF
0xABAF 0xFF
0xABB0 0xFF
0xABB1 0xFF
0xABB2 0xFF
0xABB3 0xFF
0xABB4 0xFF
0xABB5 0xFF
0xABB6 0xFF
0xABB7 0xFF
0xABB8 0xFF
0xABB9 0000
0xABBA 0xFF

[jamie from oz]

not sure how to add a code chunk.
cut and paste i have down tho.
I can msg you my messy MOD HWAD (still adding things )

[jsa]

I think i follow that.

I didn't proceed past the end of the console route because t thought it will need to be different.

Ok. I'll have to have a closer look at this, possibly tomorrow.

Code: Select all

ADDRESS	DATA
0xABFA	0xA1 
0xABFC	0x00
0xABFD	0xEE
0xABFE	0x24
.
.
.

The 0xABFA console routine is quite short, possibly too short to fit the patchcode. GUFB patch uses a lot more bytes than the 6DBX console routine. There are solutions either way given time to investigate.

[jamie from oz]

Thanks John

[jamie from oz]

is it possible to add patch code it to the filler between code and data area ??
add code at 0xAF49 or put a call in the console route to a new sub_AF4A ?

af38: 8f,f3,a8,00,28 divw R28,[Rf2+a8] wR28 /= [c41c];
af3d: d5,04 jnv af43 if (OVF = 1) {
af3f: a1,ff,00,28 ldw R28,ff R28 = ff; }
af43: b1,03,2a ldb R2a,3 R2a = 3;
af46: ef,66,87 call 36af Sub_36af (); }
af49: f0 ret return;

af4a -> bfff = 0xff ## fill ##


c000: 74,c3 word c374
c002: 01 byte 1

c003: ff ???

c004: a0,0f word fa0
c006: 5d,01 word 15d



Why does the checksum have to end at 0xffff ?
could we have checksum from 0x2000 to 0xEDFF and when its re calculated it won't see any data from 0xEE00 to 0xFFFF

[jsa]

I think i follow that.

I didn't proceed past the end of the console route because t thought it will need to be different.

Code: Select all

ADDRESS	DATA
0xABFA	0xA3
0xABFB	0x01
0xABFC	0x00
0xABFD	0xEE
0xABFE	0x24
0xABFF	0x99
0xAC00	0x3b
0xAC01	0x25
0xAC02	0xd7
0xAC03	0x03
0xAC04	0xEF
0xAC05	0xF9
0xAC06	0x6B
0xAC07	0xA3
0xAC08	0x01
0xAC09	0xF2
0xAC0A	0x1F
0xAC0B	0x38
0xAC0C	0x89
0xAC0D	0x1C
0xAC0E	0x1F
0xAC0F	0x38
0xAC10	0xD7
0xAC11	0x03
0xAC12	0xEF
0xAC13	0x07
0xAC14	0x73
0xAC15	0xF0

Jamie,
I see you have changed the address from D00 to EE00 and written in the rest of the console subroutine as it is from 6DBX.

The purpose of the patchcode is to copy data from uP internal registers to RAM external to the uP.
Checking for a console using EE00 will not allow logging of registers.

not sure how to add a code chunk.

The 'Post A Reply' menu bar has an icon with </> on it. Click it and place your code between code and /code.
http://eectuning.org/forums/app.php/hel ... 12d69aa2bd

I can msg you my messy MOD HWAD (still adding things )

Yep, I can take a look.

is it possible to add patch code it to the filler between code and data area ??

Yes patchcode and payload list can go where ever there is fill space.

add code at 0xAF49 or put a call in the console route to a new sub_AF4A ?

Adding patchcode from AF49 relies on Sub_AEDD to run, it is some way down the Background Vector List and only once. This approach can work but the data refresh is only happening a 1/4 of the time compared to Sub_ABFA. The timing of the data refresh is also much later in the background loop, could be good, could be bad. Timing wise Sub_ABFA is first on the list plus another 3 goes later on, so it has the field covered.

Sure could go with a new Sub_AF4A.
There are a number of ways to execute, your suggestion of Call from Sub_ABFA is one. Another is to Jump from Sub_ABFA.
Both of those methods waste a little uP time due to the stopover at Sub_ABFA.
The direct method is to change the Background Vector List by replacing ABFA with AF4A. I'd change all four entries but it is not essential.

The patchcode is neatest if it fits within the footprint of the Console Subroutine.
I see in your image above that you do not have Tune Position in your QHorse tab, so that can be stripped from the GUFB example for starters.

Why does the checksum have to end at 0xffff ?

Code: Select all

 #### CHECKSUM ADDRESS STRUCTURE
a25e: 00,20               word   2000                                              # Checksum Start Address
a260: f0,ff               word   fff0                                              # Checksum End Address
a262: 00,00               word      0

It doesn't. As posted above yours ends at 0xFFF0.

could we have checksum from 0x2000 to 0xEDFF and when its re calculated it won't see any data from 0xEE00 to 0xFFFF

Yes, but think about word addresses if you make a change.
Also ensure the checksum of your new range equals zero and adjust accordingly.

[jsa]

Looking back over the GUFB patchcode, it has code for the payload copying, tune position and handling the remainder of its console routine.

We need the payload copy part.
You have not included the Tune Position in your QHorse tab, so skip that.
The console routine is different in your 6DBX compared to GUFB, so we wont need to handle the much larger remainder.

The payload copying part is short enough to fit in the 6DBX Console Footprint.

The neatest is to overwrite the Console sub, so we'll do that.
You asked about fill space between Code and Calibration data, we'll use that.

We need three scratch registers.
We identified R24 and R38 from the console subroutine.
Looking at R26, it appears to be another scratch register used by background subroutines. We'll try that.

Looking at the disassembled code for the patch;
Vector list is unchanged, though I changed the Sub name in _DIR.
Patchcode overwrites the Console code.
Payload List space from AF50.
DatalogOffset is D00

Code: Select all

237c: fa,ab               vect  abfa             SubABFA_Logging_Patch
23b2: fa,ab               vect  abfa             SubABFA_Logging_Patch
23d0: fa,ab               vect  abfa             SubABFA_Logging_Patch
23f4: fa,ab               vect  abfa             SubABFA_Logging_Patch


 #### Console Subroutine is now our Logging Patch
   SubABFA_Logging_Patch:
abfa: fa                  di                     interrupts OFF;
abfb: a1,50,af,38         ldw   R38,af50         R38 = af50;                       # Payload List is at 0xAF50

    # JNE Loop from LAC0D until 0x0000 in Payload List                             SubABFA_Logging_Patch
abff: a2,39,24            ldw   R24,[R38++]      R24 = [R38++];                    # Load Payload Address from Payload List
ac02: a2,24,26            ldw   R26,[R24]        R26 = [R24];                      # Load Data from Payload Address
ac05: c3,25,00,0d,26      stw   R26,[R24+d00]    [R24+d00] = R26;                  # Store Data to Payload Address + DatalogOffset
ac0a: 8a,38,00            cmpw  R0,[R38]                                           # Test for 0x0000 at end of Payload List
ac0d: d7,f0               jne   abff             if ([R38] != 0) goto abff;
ac0f: fb                  ei                     interrupts ON;
ac10: f0                  ret                    return;                           # Job done

ac11: ff,ff,ff,ff,ff      ???                                                      # Fill Console Sub footprint


 #### Fill before Payload List
af4a: ff,ff,ff,ff,ff,ff   ???   

 #### BE uses 0xAF50 to 0xAFB7 as Payload List space
af50: ff                  byte     ff
af51: ff                  byte     ff
af52: ff                  byte     ff
af53: ff                  byte     ff
af54: ff                  byte     ff
af55: ff                  byte     ff
af56: ff                  byte     ff
af57: ff                  byte     ff
af58: ff                  byte     ff
af59: ff                  byte     ff
af5a: ff                  byte     ff
af5b: ff                  byte     ff
af5c: ff                  byte     ff
af5d: ff                  byte     ff
af5e: ff                  byte     ff
af5f: ff                  byte     ff
af60: ff                  byte     ff
af61: ff                  byte     ff
af62: ff                  byte     ff
af63: ff                  byte     ff
af64: ff                  byte     ff
af65: ff                  byte     ff
af66: ff                  byte     ff
af67: ff                  byte     ff
af68: ff                  byte     ff
af69: ff                  byte     ff
af6a: ff                  byte     ff
af6b: ff                  byte     ff
af6c: ff                  byte     ff
af6d: ff                  byte     ff
af6e: ff                  byte     ff
af6f: ff                  byte     ff
af70: ff                  byte     ff
af71: ff                  byte     ff
af72: ff                  byte     ff
af73: ff                  byte     ff
af74: ff                  byte     ff
af75: ff                  byte     ff
af76: ff                  byte     ff
af77: ff                  byte     ff
af78: ff                  byte     ff
af79: ff                  byte     ff
af7a: ff                  byte     ff
af7b: ff                  byte     ff
af7c: ff                  byte     ff
af7d: ff                  byte     ff
af7e: ff                  byte     ff
af7f: ff                  byte     ff
af80: ff                  byte     ff
af81: ff                  byte     ff
af82: ff                  byte     ff
af83: ff                  byte     ff
af84: ff                  byte     ff
af85: ff                  byte     ff
af86: ff                  byte     ff
af87: ff                  byte     ff
af88: ff                  byte     ff
af89: ff                  byte     ff
af8a: ff                  byte     ff
af8b: ff                  byte     ff
af8c: ff                  byte     ff
af8d: ff                  byte     ff
af8e: ff                  byte     ff
af8f: ff                  byte     ff
af90: ff                  byte     ff
af91: ff                  byte     ff
af92: ff                  byte     ff
af93: ff                  byte     ff
af94: ff                  byte     ff
af95: ff                  byte     ff
af96: ff                  byte     ff
af97: ff                  byte     ff
af98: ff                  byte     ff
af99: ff                  byte     ff
af9a: ff                  byte     ff
af9b: ff                  byte     ff
af9c: ff                  byte     ff
af9d: ff                  byte     ff
af9e: ff                  byte     ff
af9f: ff                  byte     ff
afa0: ff                  byte     ff
afa1: ff                  byte     ff
afa2: ff                  byte     ff
afa3: ff                  byte     ff
afa4: ff                  byte     ff
afa5: ff                  byte     ff
afa6: ff                  byte     ff
afa7: ff                  byte     ff
afa8: ff                  byte     ff
afa9: ff                  byte     ff
afaa: ff                  byte     ff
afab: ff                  byte     ff
afac: ff                  byte     ff
afad: ff                  byte     ff
afae: ff                  byte     ff
afaf: ff                  byte     ff
afb0: ff                  byte     ff
afb1: ff                  byte     ff
afb2: ff                  byte     ff
afb3: ff                  byte     ff
afb4: ff                  byte     ff
afb5: ff                  byte     ff
afb6: ff                  byte     ff
afb7: ff                  byte     ff

 #### Fill after Payload List
afb8 -> bfff = 0xff  ## fill ## 

This is the patchcode that goes in the QHorse tab of the definition.
Also set DatalogOffset to 0D00 in the QHorse tab
Also set Checksum Addresses in the Config tab to match BIN checksum range.
Test it, see what you get.

Code: Select all

ADDRESS   DATA
0xABFA    0xFA
0xABFB    0xA1
0xABFC    0x50
0xABFD    0xAF
0xABFE    0x38
0xABFF    0xA2
0xAC00    0x39
0xAC01    0x24
0xAC02    0xA2
0xAC03    0x24
0xAC04    0x26
0xAC05    0xC3
0xAC06    0x25
0xAC07    0x00
0xAC08    0x0D
0xAC09    0x26
0xAC0A    0x8A
0xAC0B    0x38
0xAC0C    0x00
0xAC0D    0xD7
0xAC0E    0xF0
0xAC0F    0xFB
0xAC10    0xF0
0xAC11    0xFF
0xAC12    0xFF
0xAC13    0xFF
0xAC14    0xFF
0xAC15    0xFF
0xAF50    0000
0xAF51    0xFF
0xAF52    0xFF
0xAF53    0xFF
0xAF54    0xFF
0xAF55    0xFF
0xAF56    0xFF
0xAF57    0xFF
0xAF58    0xFF
0xAF59    0xFF
0xAF5A    0xFF
0xAF5B    0xFF
0xAF5C    0xFF
0xAF5D    0xFF
0xAF5E    0xFF
0xAF5F    0xFF
0xAF60    0xFF
0xAF61    0xFF
0xAF62    0xFF
0xAF63    0xFF
0xAF64    0xFF
0xAF65    0xFF
0xAF66    0xFF
0xAF67    0xFF
0xAF68    0xFF
0xAF69    0xFF
0xAF6A    0xFF
0xAF6B    0xFF
0xAF6C    0xFF
0xAF6D    0xFF
0xAF6E    0xFF
0xAF6F    0xFF
0xAF70    0xFF
0xAF71    0xFF
0xAF72    0xFF
0xAF73    0xFF
0xAF74    0xFF
0xAF75    0xFF
0xAF76    0xFF
0xAF77    0xFF
0xAF78    0xFF
0xAF79    0xFF
0xAF7A    0xFF
0xAF7B    0xFF
0xAF7C    0xFF
0xAF7D    0xFF
0xAF7E    0xFF
0xAF7F    0xFF
0xAF80    0xFF
0xAF81    0xFF
0xAF82    0xFF
0xAF83    0xFF
0xAF84    0xFF
0xAF85    0xFF
0xAF86    0xFF
0xAF87    0xFF
0xAF88    0xFF
0xAF89    0xFF
0xAF8A    0xFF
0xAF8B    0xFF
0xAF8C    0xFF
0xAF8D    0xFF
0xAF8E    0xFF
0xAF8F    0xFF
0xAF90    0xFF
0xAF91    0xFF
0xAF92    0xFF
0xAF93    0xFF
0xAF94    0xFF
0xAF95    0xFF
0xAF96    0xFF
0xAF97    0xFF
0xAF98    0xFF
0xAF99    0xFF
0xAF9A    0xFF
0xAF9B    0xFF
0xAF9C    0xFF
0xAF9D    0xFF
0xAF9E    0xFF
0xAF9F    0xFF
0xAFA0    0xFF
0xAFA1    0xFF
0xAFA2    0xFF
0xAFA3    0xFF
0xAFA4    0xFF
0xAFA5    0xFF
0xAFA6    0xFF
0xAFA7    0xFF
0xAFA8    0xFF
0xAFA9    0xFF
0xAFAA    0xFF
0xAFAB    0xFF
0xAFAC    0xFF
0xAFAD    0xFF
0xAFAE    0xFF
0xAFAF    0xFF
0xAFB0    0xFF
0xAFB1    0xFF
0xAFB2    0xFF
0xAFB3    0xFF
0xAFB4    0xFF
0xAFB5    0xFF
0xAFB6    0xFF
0xAFB7    0xFF

[jamie from oz]

cool .
I will do that tonight and see what happens.
I should be able to check the checksum number with hex editor nero then adjust / change the 6DBX one at 0x200A before loading BE


thanks John you are a legend!!!

[jsa]

Jamie,

As a baseline it'd be wise to try it on the OEM bin with no changes, allowing BE to do its thing.

[jamie from oz]

I put patch code into the bin file and loaded it to QH .
key on engine off and limp home mode.
when i try to datalog no data and it changes 0xDFF2 and 0xDFF3 to FF also changes 0xDFFC and 0xDFFD for some reason .

(i am using the 6DBD.bin that i cut/moved the padding to make it start at 0x2000 like SAD_list)
(one row above where it would be in the 0xE000 file so i probably stuffed some conversion)


i will put the patch into a origional 6DBD that starts at 0xE000 and see what happens

[jsa]

I put patch code into the bin file and loaded it to QH .

Put the patch code into your Definition QHorse tab. Do not edit the bin.

Use an unedited OEM bin to load onto the QH.

Let BE manage the writing of the patchcode to the QH when register payloads are selected for logging.

[jsa]

(i am using the 6DBD.bin that i cut/moved the padding to make it start at 0x2000 like SAD_list)
(one row above where it would be in the 0xE000 file so i probably stuffed some conversion)

The bin size and settings in the definition for size and address are all interelated.

Post the bin and def if you can't straighten it out.

[jamie from oz]

these are the ones that match when i do a read in BE through the QH (note they start at 0xE000)

HWAD_E000.xlsx

be 6dbx_E000 bin.BIN

the one after i setup for 5.0v8 and runs ok (note the word at 0xDFFC)
not sure where that comes from and have checked all my addresses but havent found it.

be 6dbx_E000 binv8.BIN

[jamie from oz]

this is the ones i setup addresses as per SAD and TP with starting address of 0x2000

HWAD_2000.xlsx

be 6dbd_2000.BIN

wont run on this .

[jsa]

Jamie,

I have a 6DBE EEC here, hardware code ETV-513, to bench test with.
What is the hardware code on your EEC?

Looking at the payload tabs on your defs, only baro pressure needs patch code for logging.
Do you have any others?


MEM expansion does not look to be switched on in the bin, so it is running as single bank.
I'd be inclined to set the def and bin up as 56k to keep it simple.

[jamie from oz]

yes hardware code ETV-513 (i have a 6DBB and 6DBD so probably just data update in the bin)
i had only put RPM / MAP-BP / ECT ones in and others are just random ones i found to fill the address spots untill i work them out .

when i read it out in BE it always 112K.
with TP i could read it as 256k or 64k.

[jsa]

Yep, just a bin change.

RPM 410 ram address, loggable without patch
ECT 6b2 ram adddress, loggable without patch

MAP, Register address requires patch

Yeah, the ROM chip is larger than 56k so BE reads the whole ROM chip.

Ford put code in one 56k bank of ROM.
Ford set it to run as a single bank as mem_exp is not switched on.

I think address translation could be the issue, so I'll be testing a 56k version first. It may be a couple days before I get time to setup and test.

If you have a harness connector pinout, could you post it up please.

[jamie from oz]

pin 26 sensor reference 5.0 volts

EL pin out 1.png

EL pinout 2.png

EL pinout 3.png

[jamie from oz]

this might be better pin out i did as a comparison .

SPEED DENSITY PIN OUTS EA-EL Bronco Mustang.xlsx

[jamie from oz]

FYI
with HWAD_E000 runs sweet and in ve table i can lean it out untill it runs rough but no data .
when i use the HWAD_2000 files in the car it dosent like it so i compared it to TI 6dbd and they have the code starting at 22000 (so i looked in the xdf header info and there is a 20000 base offset)

(conclusion it dosent like using the lower part of the ROM)

is there a easy way to offset HWAD_2000 by 20000 in BE ?

[jsa]

Thanks for the pin outs.

Why do you want to offset by 20000 in BE?

6DBX_E000 bin has a mathematically correct checksum.
HWAD2000 bin has an incorrect checksum.
Having looked at your 6DBD bins and those scattered about the web, they have many different checksums, mostly incorrect.

I've taken your def, ignored some stuff, deleted some stuff, changed some stuff, highlighted some stuff and added some stuff. One thing BE gets bent out of shape over is non text in the def, make sure all cells are formatted as text, I changed a lot of number format to text.

The red highlight stuff is very likely incorrect.
The blue highlight stuff, I have added mostly for proof of logging.

I've set it up for 56k as only one bank is active. Further banks are complication for no apparent advantage.
I've run the bin on the bench for hours and logged it now and then. The attached log is the last of the period and has been edited to remove repetitive data. I've applied voltage to some AI channels which can be seen in the log as a change from the pull up values too around 3V. ADC names are based on pinouts provided.

The attached bin and DEF are a matched pair to facilitate the least troublesome register logging experience.
The log is as described above.
The DIR is a copy of your previously posted one with some additions.

It would be wise to test these as they are, as a baseline, before changing stuff.
Test them out as a matched set and see it they work beyond the bench.

[jamie from oz]

Thank you very much for your time.
I will have a look later today and post the results.
Is there a way I can donate some $ for your time please?

[jamie from oz]

It would be wise to test these as they are, as a baseline, before changing stuff.
Test them out as a matched set and see it they work beyond the bench.

I loaded them to BE then connected QH and cleared the ram/existing HWAD_E000 tune and uploaded the 56k tune to QH .

when i turned key on it was LHM fuel pump running constant and fans on .
No data when selecting basic or full pid list (probably because of LHM)
it did run about the same as with the 6cyl tune that i started with so there is hope !!!