Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Dissassembling and finding the maps


Guru

Status: Offline
Posts: 2338
Date:
Dissassembling and finding the maps


The downloaded code can be found here:
http://macmadigan.no-ip.com/Public/ECU/Hayabusa%20K6%20-%2032920-24FK0%20112100-1100%2012V%20NEP074.mot

Its a motorola s record format, so you can e.g. use mot2bin to convert it to a binary. I choose to use the S record as it has a checksum for each row and a row count at the end. With that information I can be quite sure that the data was transmitted (slowly) over to the PC.

Now its time to start looking at dissassembling strategies for this source. And particularly time to find maps for this.

Do you have any strategies how to locate the maps ?


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

For finding maps I recommend Analyze.exe

It allows you to view the data visually and makes it easy to pick out progressive repetative patterns that identify maps

analyzer1.jpg


Then by shifting the starting address and row size you can define the boundry addresses.

analyzer2.jpg


You can see how the shift in pattern between the fourth and third from last rows mark the start of a new map.

As for disassembly I would load it into IDA and start disassembly at address 0000:0400. I didn't check, does IDA support that processor core?

__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent - thanks, analyze looks very good. Will have a go when have a bit more time. The EB13 data looks from TTY screen very much like the one with the maps.

IDA supports SH-4 core which dissassembles the SH-2 code quite well. Not as well as motorola, but most of it is done automatically.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

What do you guys think this could be smile.gif. Its from 32bit busa ECU from address 0x00034AA2 that is for sure...

The best thing is that we are most likely to be able to identify the key tables by looks just comparing to the 16bit busa ECU maps without dissassembly. Making the key target for dissassembly to look for limiters.

K6 busa map sample

ps. the downloaded ecu code I posted is still somewhat faulty. Noticed that I had some faults in the download algorithm posting some memory addresses twice and also overflowing to 0008xxxx area too. Anyway for maps just looking 0003xxxx should be a good starting point.

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

Of course the next step is tracing out all the circuits on the ECU to the CPU pins. The pins of the CPU have known addresses. If you trace an injector circuit to a particular pin and then search out that pin's address in the code then you know you have found the injector software. Same for the ignition coils, the throttle and air sensors etc.

Without this information you will not know if you are looking at an ignition map or a fuel map.

__________________


Guru

Status: Offline
Posts: 963
Date:

I have an older version of IDA but mine has a SH4 (little endian) and SH4B (big endian) You need to use a big endian version.

It just dawned on me that this may be a little endian CPU and actually that is why it seems to output data 'backwards'. We have wanted the routines to output the data so we could read it, but backwards is how it appears it should be.

Anyway it looks like IDA has compensated by offering a big endian version

__________________


Guru

Status: Offline
Posts: 2338
Date:

As I am not really a specialist on this field, could you please explain the difference of big endian and little endian ?

I vaguely recall reading from the compiler manual that this processor is using the big endian. When doing the initial dissassembly last time with ida the SH-3 seemed to work a bit better.

Anyhow just completed the new upload from flash to PC as previously there was a problem with the downloading algorithm (initially had the sw downloaded each block separately and that caused double downloads & missing some segments. ) For next run I will just try downloading 0x00000000-0x0003FFF and skip bytes which have 0xFFFFFFFF values.

Anyway both .mot and .bin files are now updated and should be fairly complete, at least no row level errors and row count seemed to match:
http://macmadigan.no-ip.com/Public/ECU/Hayabusa%20K6%20-%2032920-24FK0%20112100-1100%2012V%20NEP074.mot

http://macmadigan.no-ip.com/Public/ECU/SH7052.BIN

btw. THe MOT2BIN does not recognize for a reason or another the S5 record?



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Yes, SH3 - big endian.

When trialling the dissassembly with the EVO .bin (also sh7052) I noticed that all the ports were really nicely there as variables at the end of code segment. (The hw manual gives nicely out the port addresses.) That should be the easy part ... more difficult will be to understand the assembler code.

seg000:00000000 ; Processor       : SH3B
seg000:00000000 ; Target assembler: SHASM Assembler
seg000:00000000 ; Byte sex        : Big endian
seg000:00000000
seg000:00000000 ; ---------------------------------------------------------------------------
seg000:00000000
seg000:00000000 ; Segment type: Pure code
seg000:00000000                 .section seg000, CODE
seg000:00000000 off_0:          .data.l loc_400  
seg000:00000004                 .data.l h'FFFFAFA0
seg000:00000008                 .data.l loc_400
seg000:0000000C                 .data.l h'FFFFAFA0
seg000:00000010                 .data.l sub_2B20

seg000:00000400 ; ---------------------------------------------------------------------------
seg000:00000400
seg000:00000400 loc_400:                                ; DATA XREF: seg000:off_0o
seg000:00000400                                         ; seg000:00000008o
seg000:00000400                 sts.l   pr, @-r15
seg000:00000402                 stc     sr, r0
seg000:00000404                 mov.w   @(h'12,pc), r3 ; [0000041A] = h'FF0F
seg000:00000406                 and     r3, r0
seg000:00000408                 or      #h'F0, r0
seg000:0000040A                 ldc     r0, sr
seg000:0000040C                 mov.w   @(h'C,pc), r2 ; [0000041C] = h'6D8
seg000:0000040E                 jsr     @r2 ; sub_6D8
seg000:00000410                 nop
seg000:00000412                 mov.l   @(h'C,pc), r4 ; [00000420] = loc_2B3C
seg000:00000414                 mov.w   @(6,pc), r3 ; [0000041E] = h'424
seg000:00000416                 jmp     @r3 ; loc_424
seg000:00000418                 lds.l   @r15+, pr
seg000:00000418 ; ---------------------------------------------------------------------------
seg000:0000041A word_41A:       .data.w h'FF0F          ; DATA XREF: seg000:00000404r
seg000:0000041C word_41C:       .data.w h'6D8           ; DATA XREF: seg000:0000040Cr
seg000:0000041E word_41E:       .data.w h'424           ; DATA XREF: seg000:00000414r
seg000:00000420 off_420:        .data.l loc_2B3C        ; DATA XREF: seg000:00000412r
seg000:00000424 ; ---------------------------------------------------------------------------




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

That looks like my results with SH4B. BTW how did you paste that code in the thread? as HTML?

As for endian it is basically MSB first (Big endian) or LSB first (little endian)

If you store the hex address 1234:5678 in 4 bytes of memory you can store the bytes as

addr data
0001 12
0002 34
0003 56
0004 78

The above is big endian. Or you can store it little endian as shown below...

addr data
0001 78
0002 56
0003 34
0004 12

I hate little endian however little endian proponents will argue it arranges data with increasing numeric significance with increasing memory addresses.

I started writing assembly on a Motorola CPUs when I was 16 so I guess you could say I was raised big endian


Also I think the maps start at 0002:8000

__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks - learned again something new... (big/small endian).

Assembler since 16 years... no wonder you are a wizzard and a master with it smile.gif

Below is something I did put together earlier about the ports and address routes. I will look into analogue and other interesting ports a bit later.

Looking at the code the FFFF8xxx looks like RAM variables that can be addressed directly (must check this from manual) where as FFFFFxxx i.e. port addresses seem to be addressed through using a some kind of indirect pointer.


HarnessNameexplanationcpunamebitDR ADDR
11exsexhaus sensor power onn/cPH1010FFFFF72C
12sol2n/c
21msmap select ???39PH44FFFFF72C
22tstest38PH33FFFFF72C
20ntneutral40PH55FFFFF72C
19cltclutch35PH00FFFFF72C
37PH21FFFFF72C
29txd112rxd1FFFFF005
30rxd111txd1FFFFF003
31sdsn/c
32fwe28fwe7FFFFE800
34rct30reset
14md122md1/PB1515FFFFF738
13sck109sck1

COS243PH77FFFFF72C
COS141PH66FFFFF72C

I will email to you a copy of the sh7052 hardware and software manuals just in case you would become interested more of sh7052 (its in your new bike too ?).

Just copying the screen with ctrl-c and pasting with ctrl-v, then format font size and courier if needed.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Yes, tracing the ports is easy even though time consuming. Here are the injector and ignition timers:
IG4PK1111FFFFF778
IG3PK1010FFFFF778
IG2PK99FFFFF778
IG1PK88FFFFF778
Inj4PK33FFFFF778
Inj3PK22FFFFF778
Inj2PK11FFFFF778
Inj1PK00FFFFF778

I think that I have found also the first couple of A/D subroutines. (this is for you(=rr) to confirm as I dont really know how this processor is addressing ports).

Throttle positionAN15FFFFF826
Gear positionAN14FFFFF824


ROM:00003690 ; ---------------------------------------------------------------------------
ROM:00003690
ROM:00003690 READ_GPS:                               ; CODE XREF: sub_3614+22j
ROM:00003690                 mov.w   @(h'22,pc), r3 ; [000036B6] = h'F824
ROM:00003692                 mov.w   @r3, r0
ROM:00003694                 extu.w  r0, r0
ROM:00003696                 shlr2   r0
ROM:00003698                 shlr2   r0
ROM:0000369A                 shlr2   r0
ROM:0000369C                 bra     loc_36AE
ROM:0000369E                 mov.w   r0, @(h'1C,r4)
ROM:000036A0 ; ---------------------------------------------------------------------------
ROM:000036A0
ROM:000036A0 READ_TPS:                               ; CODE XREF: sub_3614+26j
ROM:000036A0                 mov.w   @(h'14,pc), r3 ; [000036B8] = h'F826
ROM:000036A2                 mov.w   @r3, r0
ROM:000036A4                 extu.w  r0, r0
ROM:000036A6                 shlr2   r0
ROM:000036A8                 shlr2   r0
ROM:000036AA                 shlr2   r0
ROM:000036AC                 mov.w   r0, @(h'1E,r4)
ROM:000036AE
ROM:000036AE loc_36AE:                               ; CODE XREF: sub_3614+28j
ROM:000036AE                                         ; sub_3614+38j ...
ROM:000036AE                 mov.l   @(h'C,pc), r2 ; [000036BC] = h'FFFF
ROM:000036B0                 mov.l   @(h'C,pc), r3 ; [000036C0] = loc_7304
ROM:000036B2                 jmp     @r3 ; loc_7304
ROM:000036B4                 mov.b   @r2, r4
ROM:000036B4 ; End of function sub_3614
ROM:000036B4
ROM:000036B4 ; ---------------------------------------------------------------------------
ROM:000036B6 GPS_sensor:     .data.w h'F824          ; DATA XREF: sub_3614:READ_GPSr
ROM:000036B8 TPS_sensor:     .data.w h'F826          ; DATA XREF: sub_3614:READ_TPSr
ROM:000036BA                 .data.w h'FFFF
ROM:000036BC word_36BC:      .data.w h'FFFF          ; DATA XREF: sub_3614:loc_36AEr
ROM:000036BE                 .data.w h'820C
ROM:000036C0 off_36C0:       .data.l loc_7304        ; DATA XREF: sub_3614+9Cr
ROM:000036C4




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Here you are with most of the i/o and a/d ports traced. The ones with questionmarks do not have a straight path to processor io. Those need more work. The detailed tracing information as excel format can be found here:
http://macmadigan.no-ip.com/Public/ECU/Busa32bitECU_signals.xls
IG4PK1111FFFFF778
IG3PK1010FFFFF778
IG2PK99FFFFF778
IG1PK88FFFFF778
Inj4PK33FFFFF778
Inj3PK22FFFFF778
Inj2PK11FFFFF778
Inj1PK00FFFFF778
49vtaThrottle positionAN15FFFFF826
gpGear positionAN14FFFFF824
???AN13FFFFF822
oxOxygen sensorAN12FFFFF820
atAnti theftAN11FFFFF816
???AN10FFFFF814
cov3AN9FFFFF812
cov2AN8FFFFF810
cov1AN7FFFFF80E
paair pressureAN6FFFFF80C
thwwater temperatureAN5FFFFF80A
dontip over sensorAN4FFFFF808
thaAir temperatureAN3FFFFF806
vmInjector voltage compensationAN2FFFFF804
pmManifold pressureAN1FFFFF802
??????AN0FFFFF800

The one I am becoming most interested in is the Oxygen sensor 'F820 as the european ecu has that connected and USA version is missing some components. If the oxygen sensor routines are not present we need to do yet another version to cover the european ecus. But looking at 0x00003982 it looks like that ox sensor routine is there even though hw is not present.

The high resolution pictures of the PCB to locate the components are here:
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-1.jpg
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-2.jpg
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-3.jpg
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-4.jpg

-- Edited by PetriK at 12:33, 2007-11-25

-- Edited by PetriK at 12:37, 2007-11-25

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Yes, you are right - again!!! The tables section seems to start at 0002:8000. The first few bytes may to contain the table addressess (as also seen on some other ECU:s by Denso). The numbers 91100, 92800 and 9F000 propably also have somekind of meaning ?

ROM:00028000 dword_28000:    .data.l h'9110000       ; DATA XREF: ROM:off_67E8o
ROM:00028000                                         ; sub_794E:off_79A8o
ROM:00028004                 .data.l unk_2899C
ROM:00028008                 .data.l unk_289BE
ROM:0002800C                 .data.l 0
ROM:00028010 dword_28010:    .data.l h'9280000       ; DATA XREF: sub_794E:off_79B0o
ROM:00028014                 .data.l unk_289D0
ROM:00028018                 .data.l table_28A20     ;
ROM:0002801C                 .data.l 0
ROM:00028020 dword_28020:    .data.l h'90F0000       ; DATA XREF: sub_794E:off_79D8o
ROM:00028024                 .data.l h'28A48
ROM:00028028                 .data.l unk_28A66
ROM:0002802C                 .data.l 0
ROM:00028030 dword_28030:    .data.l h'90F0000       ; DATA XREF: sub_794E:off_79DCo
ROM:00028034                 .data.l unk_28A76
ROM:00028038                 .data.l unk_28A94
ROM:0002803C                 .data.l 0



-- Edited by PetriK at 16:29, 2007-11-25

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

At least some of the fuel and ignition tables seem to be 23x36 with x-axis and y-axis scaling defined per table. Based on the shape of the table the x-axis and y-axis look very alike to what the earlier kawi and earlier busa look like.

Spoiler


-- Edited by PetriK at 18:58, 2007-11-25



-- Edited by PetriK at 17:00, 2007-11-27

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

on the SV, which only has two cylinders, I traced the inj & coil connections to identical pins!

IG1 & IG2 connect (via some transistors/resistors/...) to PK8 & PK9
FI1 & FI2 connect (also via some transitors/resistors/...) to PK0 & PK1

I am still coming to grips with IDA pro and enginuity, my calves are aching from climbing up the learning curve ...

__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes it hurts - literally in neck and head !

Anyway thanks to input from RR i the initial tracing of crankshaft and camshaft sensor information looks like its tracing to the following inputs:

n-109PB14/SCK114PB: FFFFF738IC101
n+109PB14/SCK114PB: FFFFF738IC101
g-75PA1/TIOB1PA: FFFFF726IC101
g+75PA1/TIOB1PA: FFFFF726IC101


The path is not very straightforward, but maybe this is a starting point. At least both of those ports connect to IC101 (177G).

About the port addresses; I am a bit unsure if Denso would have been so advanced that they would have used SCK to define the engine speed and TIOB to drive the interrupts - or if its just ports and calculating the speed using the ports.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

I think that the watchdog writing procedure as explained in the hardware manual page pdf:445 looks something like below.

mov.w   @(h'22,pc), r8 ;  h'5A00
mov.w   @(h'28,pc), r12 ; h'EC10



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

PetriK wrote:

Yes it hurts - literally in neck and head !

Anyway thanks to input from RR i the initial tracing of crankshaft and camshaft sensor information looks like its tracing to the following inputs:

n-
109PB14/SCK114PB: FFFFF738IC101
n+
109PB14/SCK114PB: FFFFF738IC101
g-
75PA1/TIOB1PA: FFFFF726IC101
g+
75PA1/TIOB1PA: FFFFF726IC101


The path is not very straightforward, but maybe this is a starting point. At least both of those ports connect to IC101 (177G).

About the port addresses; I am a bit unsure if Denso would have been so advanced that they would have used SCK to define the engine speed and TIOB to drive the interrupts - or if its just ports and calculating the speed using the ports.


 The TIOB, Timer input capture input, is what I would expect for both of those inputs. On the 16 bit ECUs the crank and cam signals are also connected to capture registers.  Every signal edge it generates an interrupt and latches the freerunning timer value. To service the interrupt you read the value, subtract the previous value from it and you have a time period between pulses at a 2uS resolution.


You might want to recheck the SCK1 to sensor trace. That just doesn't seem right. You see using the pin as a non interrupting, straight I/O port would be a lot harder, more 'advanced' than using a simple capture timer that was designed to measure the time between pulses. It was made for these kind of inputs.

__________________


Guru

Status: Offline
Posts: 2338
Date:

SCK1 is also TCLKB aka TI10, i.e. timer input - a strong candidate with TIOB.

So it is time to find the interrupt addresses for these... ???

EDIT - after rechecking the IC101 to processor, SCK/TI10 is likely, but TIOB lost in between. Need to do more work - again, nothing comes easy without the skills to question the findings by myself.

-- Edited by PetriK at 19:38, 2007-11-27

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

PetriK wrote:

At least some of the fuel and ignition tables seem to be 23x36 with x-axis and y-axis scaling defined per table.




Hi Petri, I am following your footprints through the forest and we seem to be observing the same features in the terrain ... For the SV, I found a group of 20 maps last night, all with dimensions of 23 columns and 36 rows, and 141 bytes separating each table.

__________________


Guru

Status: Offline
Posts: 2338
Date:

.... and its a harsh path, at least for me...

Yesterday nigh I spent quite a few hours trying to follow the n+/n- and g+/g- paths from ecu harness to the processor. That is not easy with my limited electronics skills, so I come to a conclusion that maybe building a bike emulator and tracing the signal live will help. (not right now but in near term future)

Then I spent some time trying to understand the maps selection criteria and come to think that there is a ram variable that holds the engine load condition that is used for selecting the right map. I am keen to get better understanding of the code for two reasons:
- I need to have double maps (Nitrous and non nitrous)
- I need to remove the top speed limiter (to do 200mph for a mile with ecu mod by RR)

BD6C sub_BD6C:                               ; CODE XREF: sub_BAD8+2p
ROM:0000BD6C                                         ; sub_BAE8+Cp ...
ROM:0000BD6C                 mov.l   r14, @-r15
ROM:0000BD6E                 mov     #1, r6
ROM:0000BD70                 mov.l   @(h'9C,pc), r3 ; [0000BE10] = h'FFFF83CF ; map flags ?
...
BD98                         mov.b   @r3, r12
...
loc_BE34:                               ; CODE XREF: sub_BD6C+76j
ROM:0000BE34                 mov.w   @(h'AC,pc), r14 ; [0000BEE4] = h'F04
ROM:0000BE36                 extu.b  r12, r0
ROM:0000BE38                 cmp/eq  #2, r0          ; 00000010
ROM:0000BE3A                 bt/s    loc_BE5A        ; mapA1
ROM:0000BE3C                 mov.w   @r13, r6
ROM:0000BE3E                 cmp/eq  #4, r0          ; 00000100
ROM:0000BE40                 bt      loc_BE76        ; mapA1
ROM:0000BE42                 cmp/eq  #8, r0          ; 00001000
ROM:0000BE44                 bt      loc_BEBA        ; mapA5
ROM:0000BE46                 cmp/eq  #h'10, r0       ; 00010000
ROM:0000BE48                 bt      loc_BEBA        ; mapA5
ROM:0000BE4A                 cmp/eq  #h'20, r0 ; ' ' ; 00100000
ROM:0000BE4C                 bt      loc_BED6        ; mapA7
ROM:0000BE4E                 cmp/eq  #h'40, r0 ;
'@' ; 01000000
ROM:0000BE50                 bt      loc_BED6        ; mapA7
ROM:0000BE52                 cmp/eq  #1, r0          ; 00000001
ROM:0000BE54                 bt      loc_BF1A        ; Two dimensional map, maybe a cranking map ???
ROM:0000BE56                 bra     loc_BF36        ; ;restore regs for return
ROM:0000BE58                 nop

But as I am far from being as fluent with assembler as RR is, this is quite difficult task (=read errors likely) ... so come to think about using AUD to monitor the RAM variables. Maybe when the ecu is up and running using the bike emulator we can use the AUD to read the ram variable values to confirm the meanings for key variables helping in understanding how the code works. Additional benefit would be an on line tracing during the tuning of the bike.

Maybe by tracing the address h'FFFF83CF we can see if it really has those values I expect based on the code above ?



-- Edited by PetriK at 08:17, 2007-11-28

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Having spent some time with trying to locate the map select feature this is so far found:

There is two subroutines accessing different sets of maps:
MAPA = BD6C
MAPB = BF46
Both of these are called from e.g. one of the main subroutines at 636.

Before calling the BD6C or BF46 MAPA/B subroutines the potential "map_select" variable is read.
ROM:0000BB0A sub_BB0A:                               ; CODE XREF: sub_636+12BD8p
ROM:0000BB0A                                         ; DATA XREF: ROM:off_133A0o
ROM:0000BB0A                 sts.l   pr, @-r15
ROM:0000BB0C                 mov.l   @(h'A4,pc), r2 ; [0000BBB4] = map_select ; map select variable ?
ROM:0000BB0E                 mov.b   @r2, r0
ROM:0000BB10                 extu.b  r0, r0
ROM:0000BB12                 cmp/eq  #2, r0
ROM:0000BB14                 bf      loc_BB1E        ; mapB
ROM:0000BB16                 bsr     sub_BD6C        ; mapA

The variable that seems to set the map selected is in address 00029407
ROM:00029404 word_29404:     .data.w h'C35           ; DATA XREF: ROM:off_B73Co
ROM:00029406 byte_29406:     .data.b h'C0            ; DATA XREF: ROM:off_BCECo
ROM:00029406                                         ; sub_BD6C:off_BDFCo
ROM:00029407 map_select:     .data.b h'80            ; DATA XREF: ROM:off_BBB4o
ROM:00029407                                         ; ROM:off_BCE0o ...
ROM:00029408 unk_29408:      .data.b h'40 ; @        ; DATA XREF: ROM:off_BCE4o


But this is also where the trying to understand the dissassembly thinkingprocess stops. The map_select is defined as a constant byte (not at the word boundary) and hence can not refer to 0xFFFFxxxx variable. Even if its a long word 8040 then its not found anywhere else in the program ???

Something is not right or not understood here...



-- Edited by PetriK at 17:21, 2007-11-28

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

PetriK wrote:

 


BD6C sub_BD6C: ; CODE XREF: sub_BAD8+2p
ROM:0000BD6C ; sub_BAE8+Cp ...
ROM:0000BD6C mov.l r14, @-r15
ROM:0000BD6E mov #1, r6
ROM:0000BD70 mov.l @(h'9C,pc), r3 ; [0000BE10] = h'FFFF83CF ; map flags ?
...
BD98 mov.b @r3, r12
...
loc_BE34: ; CODE XREF: sub_BD6C+76j
ROM:0000BE34 mov.w @(h'AC,pc), r14 ; [0000BEE4] = h'F04
ROM:0000BE36 extu.b r12, r0
ROM:0000BE38 cmp/eq #2, r0 ; 00000010
ROM:0000BE3A bt/s loc_BE5A ; mapA1
ROM:0000BE3C mov.w @r13, r6
ROM:0000BE3E cmp/eq #4, r0 ; 00000100
ROM:0000BE40 bt loc_BE76 ; mapA1
ROM:0000BE42 cmp/eq #8, r0 ; 00001000
ROM:0000BE44 bt loc_BEBA ; mapA5
ROM:0000BE46 cmp/eq #h'10, r0 ; 00010000
ROM:0000BE48 bt loc_BEBA ; mapA5
ROM:0000BE4A cmp/eq #h'20, r0 ; ' ' ; 00100000
ROM:0000BE4C bt loc_BED6 ; mapA7
ROM:0000BE4E cmp/eq #h'40, r0 ;
'@' ; 01000000
ROM:0000BE50 bt loc_BED6 ; mapA7
ROM:0000BE52 cmp/eq #1, r0 ; 00000001
ROM:0000BE54 bt loc_BF1A ; Two dimensional map, maybe a cranking map ???
ROM:0000BE56 bra loc_BF36 ; ;restore regs for return
ROM:0000BE58 nop

.....

Maybe by tracing the address h'FFFF83CF we can see if it really has those values I expect based on the code above ?



-- Edited by PetriK at 08:17, 2007-11-28

 



I'm pretty sure that piece of code is select by gear position and h'83CF is gear position as bit flags. 1=N, 2=1st, 4=2nd, 8=3rd, etc.

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent, many thanks- that helped me to locate the below a strong suspect for max rpm limits - which does raise a question if there is another limiter somewhere or if K6 USA busa actually has 11.3k rev limit (or if scaling is different than assumed).


ROM:0000E720 Max_RPM_limits:                         ; CODE XREF: sub_E24C+34p
ROM:0000E720                                         ; DATA XREF: ROM:off_E464o
ROM:0000E720                 mov.l   r14, @-r15
ROM:0000E722                 mov.l   r13, @-r15
ROM:0000E724                 mov.l   r11, @-r15
ROM:0000E726                 add     #-4, r15
ROM:0000E728                 mov.l   @(h'198,pc), r3 ; [0000E8C4] = h'FFFF8555
...
ROM:0000E796
ROM:0000E796 Sixth_RPM_limits:                       ; CODE XREF: Max_RPM_limits+40j
ROM:0000E796                 mov.l   @(h'16C,pc), r1 ; [0000E904] = word_295A0 ;  input: h'FFFF8398->@R15
ROM:0000E798                 mov.l   @(h'16C,pc), r3 ; [0000E908] = word_295A2
ROM:0000E79A                 mov.w   @r1, r5
ROM:0000E79C                 mov.w   @r3, r7
ROM:0000E79E                 mov.l   @(h'16C,pc), r2 ; [0000E90C] = word_295A4
ROM:0000E7A0                 mov.l   @(h'16C,pc), r1 ; [0000E910] = word_295A6
ROM:0000E7A2                 mov.w   @r2, r14
...
ROM:00029598 word_29598:     .data.w h'7200          ; DATA XREF: ROM:off_E8F4o
ROM:0002959A word_2959A:     .data.w h'7400          ; DATA XREF: ROM:off_E8F8o
ROM:0002959C word_2959C:     .data.w h'7600          ; DATA XREF: ROM:off_E8FCo
ROM:0002959E word_2959E:     .data.w h'7800          ; DATA XREF: ROM:off_E900o
ROM:000295A0 word_295A0:     .data.w h'64A6          ; DATA XREF: ROM:off_E904o
ROM:000295A2 word_295A2:     .data.w h'64E4          ; DATA XREF: ROM:off_E908o
ROM:000295A4 word_295A4:     .data.w h'7600          ; DATA XREF: ROM:off_E90Co
ROM:000295A6 word_295A6:     .data.w h'7800          ; DATA XREF: ROM:off_E910o
ROM:000295A8 word_295A8:     .data.w h'7200          ; DATA XREF: ROM:off_E914o
ROM:000295AA word_295AA:     .data.w h'7400          ; DATA XREF: ROM:off_E918o
ROM:000295AC word_295AC:     .data.w h'7200          ; DATA XREF: ROM:off_E91Co



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

So the first ram variables may be the following:
h'FFFF83CF; Gear position indicator, Bit1=Neutral, Bit2=1st, Bit3=2nd etc...
h'FFFF8398; Actual rev or or Rev limit

But, But - then found the next problem, there is a problem with IdaPro translating a memory segment. I would guess that the problem starts around 6928 or soon after that... dont have a clue how to fix that ?

ROM:00006914 .data.l h'8000800
ROM:00006918 .data.l h'FFFFF654
ROM:0000691C .data.l h'FFFFF618
ROM:00006920 .data.l h'FFFFF608
ROM:00006924 .data.l h'4000400
ROM:00006928 byte_6928: .data.b h'1E ; DATA XREF: sub_447C:off_4598o
ROM:00006928 ; sub_447C:off_466Co ...
ROM:00006929 .data.b h'2A
ROM:0000692A .data.b 6
ROM:0000692B .data.b h'12
ROM:0000692C unk_692C: .data.b 6 ; DATA XREF: sub_447C:off_4594o
ROM:0000692D .data.b h'12
ROM:0000692E .data.b h'1E
ROM:0000692F .data.b h'2A ; *


-- Edited by PetriK at 20:53, 2007-11-28

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

I found the RPM limits.

I'm sorry I didn't remember this earlier but the limiter uses a different type value than the maps use. I remembered there was this unique constant to convert the crank period to pulses per time and when I looked it up in the 16 bit software the routine reminded me of the other value.

The limiter routine uses the unconverted crank pulse period value (lower value is faster). Check out the 16 bit busa Enginuity .xml for the definition formula but it basically works out to

((37500/x)*2048)/5.12

Here are the values I found

10,800 rpm = ROM:00029576 word_29576: .data.w h'56D ; DATA XREF: sub_E014:off_E0C4o
10,900 rpm = ROM:00029578 word_29578: .data.w h'560 ; DATA XREF: sub_E014:off_E0C8o
11,005 rpm = ROM:0002957A word_2957A: .data.w h'553 ; DATA XREF: sub_E014:off_E0CCo
11,102 rpm = ROM:0002957C word_2957C: .data.w h'547 ; DATA XREF: sub_E014:off_E0D0o
10,700 rpm = ROM:0002957E word_2957E: .data.w h'57A ; DATA XREF: ROM:off_E178o
10,800 rpm = ROM:00029580 word_29580: .data.w h'56D ; DATA XREF: ROM:off_E17Co
10,500 rpm = ROM:00029582 word_29582: .data.w h'594 ; DATA XREF: ROM:off_E180o
10,600 rpm = ROM:00029584 word_29584: .data.w h'587 ; DATA XREF: ROM:off_E184o

Most of these are the exact same values used in the 16 bit busa software. BTW for reference the 2001 busa is set up for Fuel Off = 10,600, Fuel On = 10,500, Ign off 11,200, Ign On 11,000

Again, sorry I didn't remember this earlier



__________________


Guru

Status: Offline
Posts: 963
Date:

PetriK wrote:

So the first ram variables may be the following:
h'FFFF83CF; Gear position indicator, Bit1=Neutral, Bit2=1st, Bit3=2nd etc...
h'FFFF8398; Actual rev or or Rev limit

But, But - then found the next problem, there is a problem with IdaPro translating a memory segment. I would guess that the problem starts around 6928 or soon after that... dont have a clue how to fix that ?

ROM:00006914 .data.l h'8000800
ROM:00006918 .data.l h'FFFFF654
ROM:0000691C .data.l h'FFFFF618
ROM:00006920 .data.l h'FFFFF608
ROM:00006924 .data.l h'4000400
ROM:00006928 byte_6928: .data.b h'1E ; DATA XREF: sub_447C:off_4598o
ROM:00006928 ; sub_447C:off_466Co ...
ROM:00006929 .data.b h'2A
ROM:0000692A .data.b 6
ROM:0000692B .data.b h'12
ROM:0000692C unk_692C: .data.b 6 ; DATA XREF: sub_447C:off_4594o
ROM:0000692D .data.b h'12
ROM:0000692E .data.b h'1E
ROM:0000692F .data.b h'2A ; *


-- Edited by PetriK at 20:53, 2007-11-28



I think your reading that data segment wrong. I think it is some kind of cylinder data lookup table.

ROM:000068E8 dword_68E8:     .data.l h'FFFFF650      
ROM:000068EC                 .data.l h'FFFFF614
ROM:000068F0                 .data.l h'FFFFF604
ROM:000068F4                 .data.w h'100           
ROM:000068F6                 .data.w h'100
ROM:000068F8                 .data.l h'FFFFF652
ROM:000068FC                 .data.l h'FFFFF616
ROM:00006900                 .data.l h'FFFFF606
ROM:00006904                 .data.w h'200
ROM:00006906                 .data.w h'200
ROM:00006908                 .data.l h'FFFFF656
ROM:0000690C                 .data.l h'FFFFF61A
ROM:00006910                 .data.l h'FFFFF60A
ROM:00006914                 .data.w h'800
ROM:00006916                 .data.w h'800
ROM:00006918                 .data.l h'FFFFF654
ROM:0000691C                 .data.l h'FFFFF618
ROM:00006920                 .data.l h'FFFFF608
ROM:00006924                 .data.w h'400
ROM:00006926                 .data.w h'400



There are 4 groups, each group having 3 32bit addresses and 2 words. In each group the addresses are +2 the previous group or the bit value shifted left 1 with the exception that the actual sequence of increase by group is 

1 - 2 - 4 - 3

This is the same as the cylinder firing order.  I think the memory between 68e8 and 697c is data, not code.



-- Edited by RidgeRacer at 23:50, 2007-11-28

__________________


Guru

Status: Offline
Posts: 2338
Date:

RidgeRacer wrote:

I found the RPM limits.



Excellent !!!! I will put those into an enqinuity table.

Then propably the other table that I posted earlier is the hard cut table (with gear specific map selection) and possibly the top speed limiter - or ?






__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

RidgeRacer wrote:

I think your reading that data segment wrong. I think it is some kind of cylinder data lookup table.

ROM:000068E8 dword_68E8:     .data.l h'FFFFF650      
ROM:000068EC                 .data.l h'FFFFF614
ROM:000068F0                 .data.l h'FFFFF604
ROM:000068F4                 .data.w h'100           
There are 4 groups, each group having 3 32bit addresses and 2 words. In each group the addresses are +2 the previous group or the bit value shifted left 1 with the exception that the actual sequence of increase by group is 

1 - 2 - 4 - 3

This is the same as the cylinder firing order.  I think the memory between 68e8 and 697c is data, not code.

-- Edited by RidgeRacer at 23:50, 2007-11-28


This table effects also the following bytes so that the code from this table onwards up to table 0x70bc looks suspicious or possibly includes other tables.

The FFFFF650 is a down counter so it is likely that this relates fuel and injection timing.


I will spend some more time on that part in the future. But now as the RPM limits are known its really only the map switching that is the last missing function from having most of the needed tuning elemets known.

There is two subroutines accessing different sets of maps:
MAPA = BD6C
MAPB = BF46
Both of these are called from e.g. one of the main subroutines at 636.

Before calling the BD6C or BF46 MAPA/B subroutines the potential "map_select" variable is read.
ROM:0000BB0A sub_BB0A:                               ; CODE XREF: sub_636+12BD8p
ROM:0000BB0A                                         ; DATA XREF: ROM:off_133A0o
ROM:0000BB0A                 sts.l   pr, @-r15
ROM:0000BB0C                 mov.l   @(h'A4,pc), r2 ; [0000BBB4] = map_select ; map select variable ?
ROM:0000BB0E                 mov.b   @r2, r0
ROM:0000BB10                 extu.b  r0, r0
ROM:0000BB12                 cmp/eq  #2, r0
ROM:0000BB14                 bf      loc_BB1E        ; mapB
ROM:0000BB16                 bsr     sub_BD6C        ; mapA


Additionally acceleration enrichment table would be nice to have as usually that has the biggest effect on quarter mile start, but that can of course be compensated also with the low gear maps.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

I think that in this case the picture tells more than words. The .xml that is linked at the enguitity thread is updated accordingly. Will also tease a bit the sh.org with this information smile.gif).

Will later have a look of the gear specific subroutine to put right names for the ignition and fuel maps. And let me mention now that the gear specific table gives a value of 11.383 as the low rpm limit for certain engine conditions. I would recommend that the highest limits should not exceed 11.350 unless also a lot of more values are changed (even though the map supports values up to 14.800).


revlimiters

-- Edited by PetriK at 14:10, 2007-11-29

-- Edited by PetriK at 14:25, 2007-11-29

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

The two last challenges before going into reprogramming phase include finding more information about the maps and also finding if the maps are switchable.

The way the maps are currently in Eginuity is that there is 4 ignition maps and 12 fuel maps (or other way round).

According to the manual there should be:
- an ingition map for each cylinder for high load and low load conditions (4x2)
- an fuel map for each cylinder for high loand and low load conditions(4x2)

Either I have made a mistake in inputting the map values to Enginuity or there is more to this - and hopefully there is so that we can find dual maps also for nitrous usage. The earlier map swich variable may as well just be an engine bank selection variable.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

PetriK wrote:

Either I have made a mistake in inputting the map values to Enginuity or there is more to this - and hopefully there is so that we can find dual maps also for nitrous usage. The earlier map swich variable may as well just be an engine bank selection variable.



Talking tomyself ?

And yes there is - e.g. in address 00029F02 (and before and after) there is 8maps altogether which are too yellow for analyze to find and which idapro had not labelled...





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Now have also uploaded the Busa K5 European ECU Flash to my PC.

Its good news - the code segments are exactly the same. First difference is @ 28C28 which is on the map definition area. Even the key maps already defined with K6 USA model seems to translate nicely with K5 Euro. Anyhow the ID string needs to be changed accordingly for Enginuity to accept the .def file.

I would suspect the biggest difference being the Gas Sensor (oxygen sensor circuitry). Having opened the USA model noticed that the components are not installed to oxygen sensor related harness connector pins. Where as the European model do have oxygen sensor due to tighter emission controls (even though I have not dremeled the European Busa ECU open. This part of the information is slightly uncertain but likely.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

PetriK wrote:

 

The numbers 91100, 92800 and 9F000 propably also have somekind of meaning ?

ROM:00028000 dword_28000: .data.l h'9110000 ; DATA XREF: ROM:off_67E8o
ROM:00028000 ; sub_794E:off_79A8o
ROM:00028004 .data.l unk_2899C
ROM:00028008 .data.l unk_289BE
ROM:0002800C .data.l 0
ROM:00028010 dword_28010: .data.l h'9280000 ; DATA XREF: sub_794E:off_79B0o
ROM:00028014 .data.l unk_289D0
ROM:00028018 .data.l table_28A20 ;
ROM:0002801C .data.l 0
ROM:00028020 dword_28020: .data.l h'90F0000 ; DATA XREF: sub_794E:off_79D8o
ROM:00028024 .data.l h'28A48
ROM:00028028 .data.l unk_28A66
ROM:0002802C .data.l 0
ROM:00028030 dword_28030: .data.l h'90F0000 ; DATA XREF: sub_794E:off_79DCo
ROM:00028034 .data.l unk_28A76
ROM:00028038 .data.l unk_28A94
ROM:0002803C .data.l 0



-- Edited by PetriK at 16:29, 2007-11-25

 



yes, the 9 looks like it has something to do with the format of the table (maybe it means there's only one row?), and 11 looks like the number of columns in the table ... with other tables, I see h'29 instead of 9, followed by numbers which seem to indicate number of columns and number of rows ... ?

 



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes,

That definately is an expression that explains the format of the table. We just need to find the table conversion function and that should give explanation.

Anyway the analyze program is very handy, I have managad to define size for most of the tables based on that. Then I just input the size and starting address to the excel for generating enginuity xml code.

You can find the k5 .bin .xls, .xml and also latest .idc in the following directory:
http://macmadigan.no-ip.com/Public/ECU/Enginuity/


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

I think I have found the AD converter RAM variables that will help to locate the remaining maps. There is a subroutine that generates all these values starting from F800->FFFF81C8 and the next one is F802->FFFF81C8+2 etc...

RAM variables generation from AD converter:
Unk:                 F800->FFFF81C8
Manifold pressure:   F802->FFFF81CA
Voltage comp:        F804->FFFF81CC
Air temperature:     F806->FFFF81CE
Tipover sensor:      F808->FFFF81D0
Water temperature:   F80A->FFFF81D2
Air pressure:        F80C->FFFF81D4
Cov1:                F80E->FFFF81D6
Cov2:                F810->FFFF81D8
Cov3:                F812->FFFF81DA
UnkAN10:             F814->FFFF81DC
Antitheft:           F816->FFFF81DE
Oxygen sensor:       F820->FFFF81E0
Unknown AN13:        F822->FFFF81E2
Gps sensor:          F824->FFFF81E4
TPS sensor:          F826->FFFF81E6

You can find the latest .bin .doc, .xls, .xml and also .idc in the following directory:
http://macmadigan.no-ip.com/Public/ECU/Enginuity/


-- Edited by PetriK at 20:20, 2007-12-03

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

PetriK wrote:

Yes,

That definately is an expression that explains the format of the table. We just need to find the table conversion function and that should give explanation.



 it appears that the numbering scheme (for my ECU anyway) is as follows:

1  2   3   4   5   6

5  A   8   -   8  16

6  A  16   -   8  16

9  A   8   -  16  16

A  A  16   -  16  16

19 M   8   8  16  20

25 M   8  16  16  20

29 M   8  16  16  20

2A M  16  16  16  20

where the columns are:

1. format number

2. A(rray) or M(atrix)

3. bits per data point

4. bits per X (Y?) axis data point

5. bits per Y (X?) axis data point

6. record length (bytes)


 

Cheers,

Mark



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes - I can confirm the table definitions by Mark. This is excellent, makes writing the enquinity file much more easier. Well done !

The excel tool with name: tables_new generated and enginuity definitions updated accordingly. Now you can just copy the table start address and table definition lonword to the excel and the .xml definition is generated automatically based on that. (The excel tool may still contain errors, but tables look the same as earlier when hand defined).

Anyhow scaling is still dependant on defining the tables, so those are most likely incorrect.


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

Hi Petri, can you outline the process of using your excel file to generate the XML? I've been doing this longhand, using an XML editor and want to automate it to eliminate the possibility of human errors. Specifically how do you convert the range of cells in excel containing the XML strings into an XML file that enginuity will recognise?

Sorry if I'm asking a really basic question here ...

__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes of course.

I just add the address and format to the excel on the yellow area on the left. Then when all the parameters are ther just paint and copy the gray area to the .xml file that is used as a definitition file for the bin. Simple copy from excel to a notepad will do as long as the notepad file is saved as an xml.

My excel should work quite well to start with, exept that you need to dig from the end of your bin a six letter ecu id code that you put into the beginning of the .xml definition. Additionally the RPM limiters are not yet there, but all the maps are which helps up understaindint their purposes.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

Thanks Petri.

My ECU has 178 maps by the looks of it, and I've defined so far about 130 of them in the definition file, doing it the long way.

I'm sick of toggling between analyze, ida, xml editor and enginuity to add each map & am looking for a smarter way to create the XML def file.

Cheers,
Mark

__________________


Guru

Status: Offline
Posts: 963
Date:

PetriK I make PortH bit4 to be A/B map select on your busa.

Also Maps C/E, J/F, K/H, and D/G are A/B map pairs. There may be others. The RAM location of the A/B select value is 8160 the bit test is h'10

It looks like you had the right idea, you just had the bad luck of starting with the mapA group which appears to be doing something altogether different than simple A/B selection

-- Edited by RidgeRacer at 16:04, 2007-12-05

__________________


Guru

Status: Offline
Posts: 963
Date:

BTW Bozo are you posting your results anywhere? If you need somewhere to host your stuff I can set you up with an FTP account on www.bikeland.info

email me at info@bikeland.info

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

Some of my screendumps are hosted in photobucket, but I have nowhere to host other files. Will send you an email, thanks RR.

Here's one of 8 (I think) fuel maps in the SV... (the axes aren't yet scaled/labelled)...




__________________


Guru

Status: Offline
Posts: 2338
Date:

Noticed based on feedback from RR that in the excel i had forgotten to define types (uint8/uint16) for table values. Will update the excel a bit later. Halfway done.

RR just confirmed over email that Ram variable 8160 is PortH and that it is used for MAP select function - i.e. selecting which sets of maps are used when harness connector MS line is high/low.

So far I think that the known RAM variables look the following (not confirmed, just working assumptions).

h'FFFF83CF;  Gear position indicator, Bit1=Neutral, Bit2=1st, Bit3=2nd etc...


h'FFFF8398; Actual rev (used in serveral subroutines as actual rev to compare to)

8160:  RAM PortH
FFFFF72C: PortH
  Bit0 = Cranking relay input
  Bit1 = ?
  Bit2 = ?
  Bit3 = test switch
  Bit4 = MS (map select?)
  Bit5 = Neutral
  Bit6 = COS1
  Bit7 = COS2
  Bit8 = ?
  Bit9 = ?
  Bit10 = Exhaust sensor power
  Bit11 = ?
  Bit12 = ?
  Bit13 = ?
  Bit14 = ?
  Bit15 = ?

RAM variables generation from AD converter:
Unk:   F800->FFFF81C8
Manifold pressure: F802->FFFF81CA
Voltage comp:  F804->FFFF81CC
Air temperature: F806->FFFF81CE
Tipover sensor:  F808->FFFF81D0
Water temperature: F80A->FFFF81D2
Air pressure:  F80C->FFFF81D4
Cov1:   F80E->FFFF81D6
Cov2:   F810->FFFF81D8
Cov3:   F812->FFFF81DA
UnkAN10:  F814->FFFF81DC
Antitheft:  F816->FFFF81DE
Oxygen sensor:  F820->FFFF81E0
Unknown AN13:  F822->FFFF81E2
Gps sensor:  F824->FFFF81E4
TPS sensor:  F826->FFFF81E6

              
h'FFFF8168; Input Capture Register copy in RAM

h'FFFF8208; Next AD sensor counter

h'FFFF820C; Which sensor is next to be read
  0x1C = GPS Sensor is read
  0x1E = TPS Sensor is read
  0x18 = Oxygen sensor is read

h'FFFF816C...+h'30; Timer Counter


The following are not yet confirmed...

Other gear indicator possible ?
h'FFFF8555; 
h'FFFF8556; Clutch flag ?




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

With BikeEmulator almost fully up and running and being able to monitor both the port values and RAM variables I can confirm that the MS signal (Ecu harness connector pin 21 on Busa) is connected to Port H. Its the one that RR found out as a strong candidate for a map switching signal.

MS changes PortH from 0xF7 (11110111) to 0xE7 (11100111), i.e. PortH bit 4 is MS signal.

Clutch signal changes 0xF7 to 0xD7 (11010111), i.e. PortH bit 5 is CLUTCH signal.

Test switch changes from 0xF7 to 0xFF (11111111), i.e. PortH bit 3 is test switch signal.

Cranking relay chages 0xF7 to 0xF6, i.e. PortH bit 0 is cranking signal.

The other sensors 100% confirmed by testing with BikeEmulator and RAM variable monitoring are the following:

Coolant temperature,FFFF81D2 = 000000AD
Ambient pressure,FFFF81CA = 000000A9
Gear position sensor,FFFF83CF = 00000004
TPS Sensor ,FFFF81E6 = 000000F2

Anyhow the RPM variable still puzzles me a bit. This gives somewhat inconsistent readings with a steady RPM input. As a byte its constant, but as a word the value of the variable changes even though nothing else in input changes like the boundary would be incorrect ?

Actual RPM ,FFFF8398 = 0000002F

And YES, the ram 0xFFFF8160 has the MS, Clutch, start and test signals as PortH, but mapped to different values. So we can call 0xFFFF8160 as PortH RAM variable.



-- Edited by PetriK at 21:34, 2007-12-13

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

That is a nice setup you have there, being able to monitor the ram realtime while running it on the emulator. I wish I could do that with the 16 bit ECUs. I can read the RAM but I must first execute a break command in the software and halt the cpu operation.

I'm curious how you determined which value was the rpm. I haven't looked at the 32bit in depth but in the 16 bit there where many 'rpm' values. There is the period between pulses, the raw crank value, that value multipled to give 90, 180, 360 degree time periods.  From the periods a rate value (revs per unit time) is calculated and then also this rate is 'zoned' into a map coordinate values.



__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes - its nice setup to read ports and variables, even though not quite fast and the emulator is still a bunch of wires and separate boards which I can not move around.

Regarding the RPM variable, I guess this is one of the many RPM related. I found this by looking at some of the maps and limiters and often come to see this. Today tested it and it behaves very much like it is RPM/100 value. It moved in sync with the RPM gauge so i think its very safe to say it being the RPM/100 variable.

Actual RPM/256*100 ,FFFF8398

[formula corrected having found a problem in RAMread program not including all the bits]

This should now help in finding the other RPM variables from the code...

Its a bit confusing as some of the RAM variables seem to be bytes where as some others are words so yesterday when reading this I was reading it as a word and obviously got two variables inside one AUD read command. 

Today I found that its the TPS that does not behave linearly. It becomes full 0xFF too early and then starts to go down again. Anyway this variable does only move with TPS sensor. So it may be that the emulator has too big resistor - 4.7k, but as its only a voltage splitter I doubt that. I double checked the circuit and found nothing, but everything is possible... (with this level of enthusiasm and lack of real skills).


[EDIT - TPS works too now, it was that the RAMread was not including all the bits]

-- Edited by PetriK at 08:02, 2007-12-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

There seems to be sequence that repeats itself in many subroutines. First load the RPM/100 in r3 then load the map definition longword into r4 and then call sub_E9C smile.gif). E.g. ...

ROM:0000C744                 mov.l   @(h'44,pc), r3 ; [0000C78C] = h'FFFF8398
ROM:0000C746                 mov.l   @(h'50,pc), r4 ; [0000C798] = dword_28698
ROM:0000C748                 mov.w   @(h'18,pc), r2 ; [0000C764] = h'E9C
ROM:0000C74A                 jsr     @r2 ; sub_E9C
ROM:0000C74C                 mov.w   @r3, r5
ROM:0000C74E                 extu.w  r0, r0
ROM:0000C750                 mov.l   @(h'48,pc), r2 ; [0000C79C] = h'FFFF84E9


-- Edited by PetriK at 18:34, 2007-12-14

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Now knowing the GPS and RPM variables for sure the maxrpm/gear function seems to set engine condition variable 0xFFFF8556 with the following values:
Possible fuel cutoff: 1111 1110
Possible ignition cutoff: 1111 1101

Anyway setting RPM limits above 11.400 requires updating these "maximum speed" values too ...

This information is to be confirmed... (IDC updated up to this point, enginuity not updated)


ROM:0000E720 Max_RPM_limits:                         ; CODE XREF: sub_E24C+34p
ROM:0000E720                                         ; DATA XREF: ROM:off_E464o
...
ROM:0000E796 Sixth_RPM_limits:                       ; CODE XREF: Max_RPM_limits+40j
ROM:0000E796                 mov.l   @(h'16C,pc), r1 ; [0000E904] = Gear6rpmlimit_10000_unk_295A0 ;  input: h'FFFF8398->@R15
ROM:0000E798                 mov.l   @(h'16C,pc), r3 ; [0000E908] = Gear6rpmlimit_10000_unk_295A2
ROM:0000E79A                 mov.w   @r1, r5
ROM:0000E79C                 mov.w   @r3, r7
ROM:0000E79E                 mov.l   @(h'16C,pc), r2 ; [0000E90C] = Gear6rpmlimit_11800_byte_295A4
ROM:0000E7A0                 mov.l   @(h'16C,pc), r1 ; [0000E910] = Gear6rpmlimit_12000_unk_295A6
ROM:0000E7A2                 mov.w   @r2, r14

...
ROM:0000E818 loc_E818:                               ; CODE XREF: Max_RPM_limits+F0j
ROM:0000E818                 mov.b   @r6, r0
ROM:0000E81A                 and     #b'11111110, r0


EDIT - and yes, it looks by looking at the numberst that the RPM scaling for word values is value/256*10 (as suggested by RR for weeks ago).



-- Edited by PetriK at 19:58, 2007-12-14

-- Edited by PetriK at 08:11, 2007-12-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

1 2  >  Last»  | Page of 2  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard