12587603 code reference dump

[AngelMarc]

Not trying to add features like some. Mostly slashing chunks out for simplicity, limit table switching, primary goals right now.
Looking for anything like these posts. For myself and others to refence. I know people have already done some of what I want, but if they've shared the answer, I haven't seen it.
Quotes, links to other sites, Ghidra projectfiles,whatever. The more pieces, the less unknowns and guess work.

SharingGhidra projects https://www.youtube.com/watch?v=i_vZP15RtaY

Ive been looking at 12587603 disassembly some more and i cant seem to figure out how the axis's are referenced. I can see where the variables for the axis's are pulled from RAM but how the axis's are actually read are still a mystery to me. anyone have any insight on this?

im studying how the main high octane ignition table is read.

Code: Select all

OS1:00039FAC 3038 AEDA                           move.w  (RAM_RPM_2).w,d0 ; move RPM from RAM to register D0
OS1:00039FB0 3238 AEDC                           move.w  (RAM_MAF).w,d1  ; move MAF from RAM to register D1
OS1:00039FB4 7419                                moveq   #$19,d2         ; Move Quick
OS1:00039FB6 207C 0001 0E3A                      movea.l #SPARK_ADVANCE_KA_MAIN_OT_LOW_OCTANE,a0 ; This calibration determines base spark 'bad fuel' contribution to spark advance.
OS1:00039FB6                                                             ; Degrees
OS1:00039FBC 4EB9 0002 6994                      jsr     INTERPOLATE_TABLE ; Jump to Subroutine
OS1:00039FC2 3240                                movea.w d0,a1           ; Move Address

INTERPOLATE_TABLE is the 3D lookup routine. A0 is the address of the table, D0 (word) value searched on the X axis, D1 (word) is the value searched on the Y axis. d2 is the size of the of X axis, and the result comes back in D0 as word. So in the above, 19 hex is 25 cells of the table in the X direction which is the only dimension it needs to lookup the value.

If you look at the table, 25 cells in the X direction (400->8000).

The values are scaled before going in to the routine to take into account the axis so the lookup function does not need to know the axis beyond the X size.

So RAM_RPM2 is really RAM_RPM_SCALED and RAM_MAF is RAM_AIR_GPC_SCALED (or something like that). Where GPC=Grams Per Cylinder.

You'll find the scaling code between the ADC read and what writes it to that location in RAM. And all the rest of high and low octane scaling code, just to really keep you on your toes.

A similar idea I've had myself. GPC/KPA numbers would mean nothing anymore, but you could give such an ECU to somebody, instruct them to do typical HPtuners datalogging with no modifications, and just "paste special" or whatever, and it would work out.
And unless I'm missing a lot (which is likely), looks like forcing speed density is as simple as replacing one RAM address at ROM address 0x7a8e4.
Replace aedc with f2bc. Apparently, I don't know.

Code: Select all

                             LAB_0007a8e4                                    XREF[3]:     0007a8bc(j), 0007a8da(j), 
                                                                                          0007a8de(j)  
        0007a8e4 31 c3 ae dc     move.w     D3w,(RAM-GramsPerCylinder).w                     = ??

EDIT: to add good stuff Might cover most of what I hoped to get.
https://github.com/LegacyNsfw/12587603/tree/master

[antus]

I think you posted this in two places. Many features can be turned off with flags, and many pieces of logic disable with error codes set. You might be able to go quite a long way by just writing a document or instructions about what to disconnect (eg MAF), what to leave connected (eg EGT) and how to set the DTCs to hide the MIL but still process the error so the PCM does the right thing. You could release a bin with only calibration changes to start with which is getting close to your goals then look at code patches for eg loss of traction control when running in speed density.

If you proceed with code patches to remove functionality you'll need to do lots of testing as its not clear what data in ram is referenced by other parts of the code and you might cause problems you don't expect. If you' have skills with ida or ghidra and you can get a clean disassembly once you have identified ram addresses you should be able to find other code that references it. But you'll also need to be able to identify indirect references (eg where an address is copied to a register then the register used to access the data) as the disassembler might miss those references or maybe write a script for those tools that can identify those things to make sure nothing is missed.

Another school of thought is that most tables you can just leave factory so you could remove them from your own version of an XDF and if you need to change them to make the calibration run right, it probably also wont run right if you remove the processing of that table too.

[AngelMarc]

A small portion of it seemed relavent in another thread.
This was as far as I got with just calibration changes
https://www.facebook.com/groups/1074245 ... 2846246150
That's a .bin download if you care to look at it. All DTCs set to no report, for reasons I don't feel like typing out right now. I started to doubt if I was getting speed density, or a noisy MAF input from the open circuit. I also have an issue with the crank trigger wheel not staying centered at 6kRPM... custom made for a 1970 CB450, without a lathe or mill to do it well. Could be causing misfires problems.
https://www.youtube.com/watch?v=g_Q6pFgmySY
I'm aware there's a lot of interconnecting in the code that isn't immediately obvious. As much as I'd like to rip out massive chunks, I'll likely stick with altering the end of functions, like replacing GPC with MAP reading.

I'm looking at getting an oscilloscope and function generator or just spin the trigger wheel with an electric motor for more convenient testing.
I looked for some of the DTC code switching briefly but didn't get any leads yet.

[antus]

Ok that looks like a cool project. What engine are you running it on? Do you have any logs to see what is going on with regards to AFRs and DTCs? Which operating system did you start with?

If your goal is MAP and you dont have traction control in the first place and all is operating properly in hardware you should be able to get that with just cal changes. But on that engine, probably a few more things playing in to it.

[AngelMarc]

Ok that looks like a cool project. What engine are you running it on? Do you have any logs to see what is going on with regards to AFRs and DTCs? Which operating system did you start with?

If your goal is MAP and you dont have traction control in the first place and all is operating properly in hardware you should be able to get that with just cal changes. But on that engine, probably a few more things playing in to it.

Only sensors used were crank, MAP, and IAT. That's it.
I tried recording data with an Xtool D8 (at work). It seems to be buggy for recording.
I need it to work well without useless DTCs, I live in an e-check shit hole; and I want to swap something newer. I'd like to have some traction control functionality available in the future, but only to make it work with 6 speed automatics. Torque reduction for smooth shifts. Paddle shift style with an Arduino or something.
I'm aware I can't rely on references from other OSes to change to 12587603; haven't messed with any other.
There are time/RPM based misfire tables that could be triggered by missing cylinders; all those tables are set to max values. Other than not leaving the 4800RPM table, timing was always what I expected. Set it to be solely RPM based, scanner live data verified. Temp modifiers and cat light off all disabled in cal.
I was not using O2 sensors; but I observed the color of exhaust flame, richened/leaned VE table, observed the expected change between blue flame and orange flame. Which would lead me to believe it's speed density. A lot of cal deltas for MAP TPS etc. to switch between steady and unsteady state were set to max values.
I had inconsistant idle, no IAC was used, idle speed error tables were all set to 0. Never looked into what "stall saver routine" does; that could be valuable info.

Unanswered questions were answered previously.
EDIT: Attached File I started with. Scanner says GMC Savanna. Starting with DBW file gave me problems this file didn't.