Memory dump of ECU

[RoughSilver92]

Thanks, that is a big help. That ff was throwing me, up until now I have only ran into the 01,02,04,08,10,20,40,80. ff representing all the bits is perfectly logical, really should have been able to reason that out myself. With time, I guess.

[b3lha]

Originally Posted by longassname

Hey Phil,

Someone asked me an intersting question today for which I don't have the answer and thought I would pass on to you in case you are interested in/willing to look into it.

He asked me how the ecu handles when to start fuel injection. Not the pulsewidth but the timing of fuel injection in relation to crank position/valve opening. I remember the factory service manual mentioning timing fuel injection to end as the valve is opening. It might be fruitful to be able to adjust this.

I don't know either.

At the lowest level it's going to be some kind of syncronisation between the crank sensor pulses and the six injector timers. That's going to be tough to figure out unless there is some obvious map that controls it.

I'll make a note of it but I can't promise to come up with any hard and fast answers.

[TomsSVX]

Originally Posted by longassname

Hey Phil,

Someone asked me an intersting question today for which I don't have the answer and thought I would pass on to you in case you are interested in/willing to look into it.

He asked me how the ecu handles when to start fuel injection. Not the pulsewidth but the timing of fuel injection in relation to crank position/valve opening. I remember the factory service manual mentioning timing fuel injection to end as the valve is opening. It might be fruitful to be able to adjust this.

Fruitful for what?? Basic fuel efficiency?

I mean hell after about 2krpms it doesn't really matter if you even have sequential injection, esp with the stock injectors... To adjust the start angle would be trying to slit hairs with a hatchet

Tom

[b3lha]

Originally Posted by Mrdjc

What's this five speed stall your talking about, I've never experienced it on my Legacy and Neither have I heard of the problem being specific to 5th gear on the UKlegacy forum. Usually stalls are throughout the whole range of gears and speed, down to a messed up IACV, TPS or leak.

Must be an SVX thing then? Does it apply to EJ20's as well as the EZ/EG series?

Roughsilver,
good job blowing some life into this project once again!

I've been meaning to do exactly what you are doing now, but lost interest and now I'm studying abroad in Slovakia so my Vehicle is at my parents in storage in Scotland.
Once I get the basics worked out for my N/A I'm hoping to move on into the EJ20 TT setups, as there is a heap of demand out there for it, and the only real option currently is a complete aftermarket ECU but it doesn't really include any of the code that is written into the stock ECU with regards to boost and turbo malarky.

Phil,
Congrats with 2nd child! You must be a really really busy man now!
I think your presence on this thread is probably what is keeping it alive and ticking over, its clear to see it suffers without you.

Wishing everyone a happy new year, and hopefully fruitfull in terms of ECU exploration.

Cheers,
Daniel.

Hi Daniel, nice to hear from you. Hope your studies are going well.

The SVX only came with an Auto trans and the ECU makes certain assumptions based on that fact. When people swap in an impreza 5 speed manual trans, the ECU assumptions are sometimes wrong and this can cause a stall. The fact that not everybody gets the problem confounds the issue a little, but offers hope that the problem cars can be fixed.

I think you are right about the demand for tuning the TT setups. From what I hear, Subaru made a really bad job of it, and ended up with a huge dip in the middle of the power curve when one turbo had reached its limit and the other hadn't started blowing. This could be fixed by fitting some different turbos and then recalibrating the ECU. But as yet, very few people know how to recalibrate the ECU - and those that know aren't sharing.

[b3lha]

Originally Posted by SVXdc

BBC and BBS opcodes can use "Absolute bit relative" addressing mode (you'll need to look that up in the CPU software manual).

BBC is Branch on (all specified) Bits Clear

The 5th byte of the instruction specifies the relative branch (#0x0B in your example, so [PC] B095 + [offset] 0B = [branch target] B0A0).

Bytes 2 and 3 specify the memory location to read (848F).

Byte 4 specifies which bits to examine to make the decision whether to branch. FF here says to look at all 8 bits in the specified memory location. In other words, branch when all bits in 848F contain 0.

When the m flag is 0 ("16-bit data mode"), then the bit field becomes 16-bits (in bytes 4 and 5), and the 6th byte contains the branch offset.

Very nice explanation David.

I always find it confusing when more than one bit is specified in a BBC or BBS statement. I can never remember whether it means ALL or ANY of these bits.

[RoughSilver92]

I am still trudging through this code and I want to make sure i am interpreting this correctly:

00ADC6 AD2E10 lda ax, 0x102e
00ADC9 2900FF and ax, #0xff00
00ADCC 890D1A80 mpy 0x801a

Since it is little endian, 102f contains the most significant digits and 102e contains the less significant digits. So the value at 102e is inconsequential because the and will clear those bits anyways. In reality it is multiplying the value at 102f followed by 8 bits of zeros with the value at 801b followed by the value at 801a, or:
[102f][#00]
x[801b][801a]
---------------

Is this about right or do I have it backwards?

[b3lha]

Originally Posted by RoughSilver92

I am still trudging through this code and I want to make sure i am interpreting this correctly:


Since it is little endian, 102f contains the most significant digits and 102e contains the less significant digits. So the value at 102e is inconsequential because the and will clear those bits anyways. In reality it is multiplying the value at 102f followed by 8 bits of zeros with the value at 801b followed by the value at 801a, or:
[102f][#00]
x[801b][801a]
---------------

Is this about right or do I have it backwards?

Yes. That is correct.

The two 16-bit values are multiplied together and the 32-bit result is put into b,a
eg. [102f][#00] x [801b][801a] = [bh][bl][ah][al]
Then the next line of code takes the most significant 16 bits of the result and stores them at [1009][1008]

00ADD0 428D0810 sta bx, 0x1008

That's basically the same as dividing the result of the multiplication by 0x10000

[b3lha]

Originally Posted by RoughSilver92

I am still trudging through this code

Hey Andy,

If you are still playing with this then I have something to help you:

The first file is an M7700 debugger program (for windows). The second is your 722525 ROM converted into Intel Hex format.

pd77simv310r1a_e.exe

722525.hex

You can load the ROM into the debugger and run parts of the program one instruction at a time and watch what happens to the registers and the memory. You can also change variables in memory, then run through a calculation to see what effect it was on the result.



After loading the ROM, setup the M flag appropriately. Set the PC register to the address that you want to start executing from. Then set up any values in RAM or registers as you want them, and start stepping through the code.

Also, I think that you can dump the RAM from your car and load that into the simulator too, so the program has some good data to process. Obviously you'll have to fake ADC readings and other Input values because the simulator doesn't have an engine attached.

Phil.

PS. Daniel, if you're still here then you might like this too. It should work with your Legacy ROM. Just use bin2hex to convert the ROM binary into Intel Hex format.

[Mrdjc]

Thanks Phil,

That program looks mighty interesting.. I was going to try and make a flow chart type drawing to make note of what's happening with the registers but this will really help!

Might just be the best thing since sliced bread.. I'll give it a go some time in the near future.

I wonder if Roughsilver is going to get there before me, he most likely will..

Cheers,
Daniel.

[RoughSilver92]

The start of the semester has slowed me down a bit on the code, but I will find some time to play with this. Now I should be able to test weather a couple of the values I have been guessing at actually do what I think.

[Mrdjc]

I just tried this but I can't even get the first bit to work!

I took the 64K Bin file (The one we added 32K to)

Ran

bin2hex 64K742FA1.bin intelhex.hex

Loaded it into the PD77Sim and for some reason I can only get about 100 lines of code showing at a time, I can go beyond the lines showing by holding down the arrow key, but can't physically slide the bar down as it hits the bottom of the window and won't go any further, yet I know there is another 32K of data before what its showing me!!

I can jump to addresses manually but only get about 100 lines before the screen bottoms out again, I cant scroll beyond it, I need to hold down the arrow and get 1 or 2 lines per second.

I looked through the settings of the program but I think it was translated from Japanese or something

Any ideas?

Cheers,
Daniel.

[b3lha]

Originally Posted by Mrdjc

I just tried this but I can't even get the first bit to work!

I took the 64K Bin file (The one we added 32K to)

Ran

bin2hex 64K742FA1.bin intelhex.hex

Loaded it into the PD77Sim and for some reason I can only get about 100 lines of code showing at a time, I can go beyond the lines showing by holding down the arrow key, but can't physically slide the bar down as it hits the bottom of the window and won't go any further, yet I know there is another 32K of data before what its showing me!!

I can jump to addresses manually but only get about 100 lines before the screen bottoms out again, I cant scroll beyond it, I need to hold down the arrow and get 1 or 2 lines per second.

I looked through the settings of the program but I think it was translated from Japanese or something

Any ideas?

Cheers,
Daniel.

That's normal, just a quirk of this program. I'll give you a quick tutorial:

Run the PD77SIM program. Click OK on the "Init" window. Click File/Download/Memory Image. Select your 742FA1.HEX file. The file gets loaded into memory and the simulator is ready to start processing from the reset vector address. Click BasicWindow/Register Window and then BasicWindow/DumpWindow.

Suppose we want to look at the subroutine at address 0xAC4E. It reads the fuel map. Double click "PC" (program counter) in the register window. Change it to "AC4E". Click on the "M" button in the register window to change the M flag to 1 (we know from our previous disassembly work that the M flag is 1 for this subroutine). Now click the "view" button in the program window and then the "PC" button to view the code at the PC address.

The simulator is now ready to execute the line of code at address AC4E. "LDA A,8039". If you scroll the dump window to address 8030, you can see that the value at address 8039 is 00. There doesn't seem to be a fast way to scroll this window to a particular address.

Now if you click the "step" button (3rd from left on the toolbar), the instruction gets executed and the A register gets loaded with 00. You don't see a change because the A register was already 00, but notice the Z flag has changed to 1. When you step the next instruction, BEQ AC68, the program will branch to address AC68.

As you step through the next few instructions you can see the program storing the address of the fuel map, the X axis, the Y axis, the load and the rpm into addresses 1072 through 107A. It is setting up the parameters for the map lookup subroutine at 9200. Since the values of "RPM" (1062) and "Engine Load" (1140) are zero in the simulation, we won't get a meaningful value back from the map lookup. So edit the values to something meaningful in the dump window, before they get read into the registers. Just double click on the value you want to change. I think a value of 0x40 is 3200rpm and 0x00B0 is about half load. Notice how the program clears the M flag before operating on the 16bit load variable.

When you get to "JSR 0x9200" you could step into it and follow it through to see how it works. But since we know what it does, use the "Step Over" button to run it. You will see the result of the map lookup in the A register upon return from the call. This value represents an Air:Fuel ratio.

The program will use this AFR, together with the amount of air (engine load) to calculate the amount of fuel, which is then combined with the injector size value to calculate the injector pulse width.

[Mrdjc]

Cheers Phil,

I will try it a bit later on.

Do you happen to know of a program that can do a find/replace for multiple words at once?

I'm looking at replacing all the Mnemonics with Descriptions so I can actually understand them, in the text file, then perhaps to divide it into the sub-routines and compare them using the PD77SIM program.

Example:

LDA Load memory into accumulator.
LDX Load memory into index register X.

CLC Clear Carry Flag to “0”.
SEC Set Carry Flag to “1”.

Cheers,
Daniel.

[b3lha]

I managed to get the 4WS computer to talk to me today. I've tried and failed many times in the past, but today I found the secret.

As usual, you first send a reset "12000000". Here's the trick: the first 4WS address you ask for after the reset must be FFFF. Otherwise it just ignores you. So you send "92FFFF00" that makes the unit start talking and after that you can ask for other locations or the ROMID in the usual way.

The ROMID is 719210.

I tried dumping the whole address space and it returns zero for every address except FF00 to FFFF. So no ROM code to look at, just parameters to log.

ff00  D6 21 00 00 00 00 00 F9 3C B6 00 00 00 00 00 00
ff10  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
ff20  00 00 00 00 00 00 00 00 00 00 00 00 1F 00 00 00
ff30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
ff40  81 80 00 00 00 0B 00 00 80 00 00 00 00 00 00 00
ff50  00 00 00 00 00 03 00 00 00 00 00 00 00 1D 00 02
ff60  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ff70  00 00 00 00 CC 2F CC 8B 82 01 03 00 00 00 00 00
ff80  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
ff90  E9 06 08 CE 93 CE 02 E0 00 6F 00 4B 00 D5 00 61
ffa0  F8 7F 27 FF B8 77 D3 FF FF FF FF FF FF FF FF FF
ffb0  FF FF 2F 3A FF FF 90 D1 FF FF FB 18 FF FF 53 80
ffc0  FF 40 FF FF C9 E7 FF 00 03 B0 60 FF 9A FF FF FF
ffd0  43 B0 C2 FF 80 FF FF FF 24 7F 7C 7C 87 52 FF 17
ffe0  CD CC 82 82 01 01 01 00 BF BF 7F 7F FF FF FF FF
fff0  00 FF B8 C8 AE 77 65 52 C2 24 42 AA 82 6A 28 C2

I pulled the 4WS parameter from LAN's select monitor dump. I've included them below with my best guess as to what they might mean. They are all zero in the dump above, presumably because the car was parked. At some stage I'll try and write a datalogger for it, but first I need to check that I get consistent results on my other 4WS car.

ff24 vsp1 (km/h) - VSS1, rear wheel speed?
ff23 vsp2 (km/h) - VSS2, front wheel speed?
ff22 ptn1 (step) - position1?
ff21 ptn2 (V) - position2?
ff10 stan - steering angle?
ff1e rstan - rear steering angle?
ffb6 dio - digital IO bits?
ff16 stsp (deg/s) - steering speed?
ffb3 dio - digital IO bits?
ff1c rstsp (deg/s) - rear steering speed?
ff25 mtrcr (A) - motor current?
ff18 ddran (deg) - something angle?
ff1a ndr (deg/s) - something rate?
ff12 k
ff0a diag.cod - diagnostic codes?
ff02 diag.cod - diagnostic codes?
ff02 memory.clr - clear codes when write to this address?
ff0f special
ff0f special

[NeedForSpeed]

Now that's really interesting,
Phil, the Master, does it again, and then again!

Is it possible to change the speed of engagement, the rate of change, the direction of change, i.e. counter at low speed, the max percent of change?