Just to be clear, I did not write/create those files - they also came from Gearhead-EFI.

 

Yeah, from what I have found those were made by LRT on gearhead-efi, they will be credited as such.
To outline some of the changes coming...

• Improved Wiki
• Declustering the repo by removing readme's with unnecessary info
• Introducing the "Experimental/ Needs Testing" folder for xdfs found across the web
• Modified bins may be going away unless a way is found to get "Tuner notes" put in that track changes made.

To outline the issues with the repo:

• No structure in place for HW ID, Service Number, or P59 Intel chips.
• Information is not accurate
• Troubleshooting guide is rather limited
• Missing Accreditations
• Can be hard to find a specific file

 

It's a great start! Nothing is perfect in this life.

Thanks to you and everyone who has contributed to this now and in the past!

Scott

 

Hi all,
Progress has been slow, but I am still trying to squeeze some time into maintaining the repository.

• I am currently looking for an Australian 12587603 BIN to confirm an XDF feature before I put out an updated XDF with some cool features from 3 different XDFs (special thanks to dzidaV8 and LRT on the gearhead-efi for developing and releasing unlocked XDFs), unfortunately, I still have no way of ensuring that the OS patches do not have any intellectual property from the commercial tools, and so I won't be able to add them to the final XDF.
• There will be some more progress on the wiki in the coming weeks, I've been doing some deep digging to get some good information on the PCMs and some basic tuning info.
• I will be restructuring the BINs and separating the different OS's available per model year, as well as moving the BINs that do not currently have an XDF into a "Currently Unsupported" folder to hopefully decrease the number of "Do you have a XDF for my OS" questions.

Paul

 

HERE is a collection of stock bins i have been working on. These are untouched with the exception of the 2004 Silverado 5.3 4L80 12606960 EXPERIMENTAL file. There was never a factory 4l80 with this OS i manually segment swapped it in hex. The file checksums and opens properly in Tunercat and Efilive.I labeled the trans type as auto or manual if it didnt have a 4l60 i put the trans type in the name of the file. For flex fuel cals i put L59 in the naming convention.I dont have the time to put them on github ill let you do that how you want to admin the folders. Ill finish up the rest of what i would typically use up to MY 2007 P59.

 

Very interested in seeing what features you are referring to for OS 12587603.

Also, I think it would be good to update the first post to have a link to the github repo.

 

Sorry for the lack of replies, it's gotten really busy at work and I 've found it pretty hard to make any progress. One of the features that I am trying to confirm is lean cruise, which was enabled on euro cars and Australian cars but disabled on US cars due to the EPA frowning on the increased NOX emissions. It's a very cool feature for those who drive an LS equipped daily especially for those who use cruise control a lot, I personally would love a couple more miles to the gallon. I just need a bin file to double check that is truly the case.
Unfortunately, that is the only feature I can legally release, the other two are a MAFless(speed-density??) OS patch, and a 2 Bar OS patch. As these are both features offered in the commercial tools, and I have no way of checking that these patches do not contain IP, I can not release them in the XDF that I can hopefully get done with soon.

 

I had some free time last night and did some mix and matching from a couple of the bin files roughneck427 provided.

Where a trans swap in the file has been made the segment swapped included the trans calibration segment, diagnostic segment and the speedo segment.
Where an engine swap in the file has been made only engine calibration and the engine diagnostic segments where altered.
There are differences in the Speedo segments between the truck manual trans and the car manual trans that I'm not sure are covered in the XDF's floating around.

In the case of a couple of the F body files Eng cal, Eng Diag, Trans Cal, Trans Diag and Speedo segments were all swapped.

Other then altered segments the files are still stock.

If your already using a stock 12212156 OS then all you would need to do is flash the calibration data.

I have verified segment address in the boot block and Checksum values for each segment and they are all correct. It is possible in a stock application there may be some mismatch on messages for the cluster but it's very unlikely since I did not alter anything in the fuel or system segments and both applications use a hard wired speedo output.

I would like to also point out that NONE of these files or the one's roughneck427 shared should be used for "Cloning" with Ls Droid and they should NOT be used when writing the Security Sector or what ever it's called in PCM Hammer that's equivalent to cloning. The files do not have any data in the $4000 to $8000 range where things like the Seed and Key would normally be stored.

 

As of today, all the bins are sorted by XDF compatibility, if there is not an XDF for it on the repo, it is listed as unsupported. If you know of an XDF for one of the OS's listed as unsupported, let me know and I'll get it added and move the bin collection to the correct folder. A pretty cool thing about github is it hides empty folders, so if a model year does not have any supported OS's, you can tell within a click. Progress has been non-existent but figured I'd push that little update out there to make it a little easier to navigate and find what you need. Pete, I'll be adding the above bins under the respective modified folders, thanks for putting the work forward.

 

Based on Pete's concern's for what these file(s) should not be used for is that going to be reflected in the filename?

 

Yes, when I get around to adding them I'll separate them in a different folder under modified bins with Pete's warning. That folder will also have a readme just to play it safe.

 

Yes disassembly is a really good idea. If you've ever seen what the $59 group did you'll know that if everyone works at a disassembled code long enough they can make it do almost anything. It would at least be nice to change the indicated load columns. If we learn how to make custom code we can add it to an XDF with a patch function.

I have done done some disassembly, binary modification, and firmware development in the past. Are you allowed to post what you've done so far? If so would you feel comfortable sharing? A Corvette would be fun to tune!

I am still new to this, getting a PCM in the mail soon. I don't even know what processor these things use yet :-/

Can we use an xdf that isn't locked in the P59 repo? I like that one OS has been chosen to work with that can be made to fit many applications.

 

What I've done so far is here:
https://github.com/LegacyNsfw/12593358
There might be a little more on my laptop but not much. I'll upload the latest tomorrow. That's the OS that's on my C5. Besides the disassembly, the other key thing there is a couple of scripts that read an XDF and generate IDC script for use with IDA Pro. The generated scripts label all of the parameters and tables that are in the XDF, plus the OBD2 PID functions, and that stuff is a huge head start for reverse engineering. (Kudos to CMaje at pcmhacking for putting together the unlocked XDF that made that possible.) Since that OS is what's in my car, that's what I have been focusing on.

I later learned that the 12212156 OS would probably be more useful to most people though since it is available with pretty much every combination of features (manual/automatic, cable/DBW, etc). But the scripts I posted, together with the XDF for that OS (there's an unlocked one in the repo), could be used to get started with '2156. What I've found so far in my OS should probably be easy to find in that one. (Which really isn't much, to be honest.)

I also did a very tiny bit here:
https://github.com/LegacyNsfw/12592425
That's a P59 OS from a 2004 Corevette. There's an unlocked XDF for it, so I ran my scripts on it and that's the result - an IDA script that labels all of the tables and a bunch of OBD2 PID functions. But it's a free head start if anyone wants to dive in.

It would be preferable to work with the 12587603 OS for the P59 PCMs - like the '2156 OS it has variants with all of the feature combinations. However there is no unlocked XDF for that the '7603. So I assume that any P59 hacking is going to start with that Corvette OS. Hopefully we can make it work for cable throttles and automatic transmissions, but we won't know until we try.

 

I forgot to mention... I've been using IDA Pro, but that's expensive.
Ghidra is free, and it includes a C decompiler that looks very promising, but it doesn't support the table-lookup instructions in the 68332 CPU (aka the "CPU32" extensions to the Motorola 68000 instruction set).

So here's another thing that would help a lot...

https://github.com/NationalSecurityA...ra/issues/1244
Issue: Add CPU32 support

https://github.com/dzidaV8/ghidra/tr...data/languages
Private branch: working on that problem.

I haven't looked at in a while, so I don't know the current status, but dzidaV8 was working on it.

 

The annotated disassembly is like the rosetta stone for the whole thing.

We should pick some key features to work on. For me boost is important, so I am trying to scale the load tables. Everything is designed to be scaled for sensors I just don't know where right now. In $59 and many other older PCM the load axis scaling is just before the map, but I did not see it there.

What I've done so far is jumped around the annotated disassembly and used the XDF as a guide. Finding some neat stuff

3D lookup routine (16-bit) - LookupSurfaceValue
;
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;
; In:
; D0 = value for column lookup
; D1 = value for row lookup
; D2 = size of row
; A0 = base addr. of table


; Routine to look up cranking VE
;
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;
; VE = Calibrated VE x sqrt(current deg K) / sqrt(calibrated deg K)
;
;
; (M/R) x 2 x kPa MAP x 51.2 x baro corr x VE x 51.2 x cyl vol x 32768
; airmass x 4096 = ----------------------------------------------------------------------
; 100% x 51.2 x deg K x 32
;
; M = molar mass of air
; R = gas constant
;
LBL_$701A2:
MOVEM.L D0-D2/D6/A0,-(A7) ;Move data and addr. regs to stack
MOVE EXT_1C5A.W,D0 ;Load D0 with engine RPMs
MOVE EXT_22E8.W,D1 ;Load D1 with MAP kPa
CLR D3 ;Clear D3

LAB_3CAC:
MOVEQ #33,D2 ;Load D2 with size of rows
MOVEA.L #$0810C,A0 ;Load A0 with cranking engine VE
JSR EXT_0DCB ;3D lookup


3D table is comparing two things. For the VE while cranking table it is comparing RPM to kPa. I still don't know how it knows what the axis scaling is. I'll keep looking, it might be in the 3D lookup routine. That routine only takes in 3 values, the two sensor values and the number of columns per row.



I might not be using this strictly for GM products.

 

Far as I can tell, the axis scaling is kinda just implied, it's not really part of the table lookup. The X and Y values are 16 bit, fixed-point, and the axis scaling is a consquence of how those values are scaled.

This makes data logging kind of tricky because finding the memory location is only half the battle - you still have to figure out how to convert the value in memory from whatever odd scaling the PCM code uses into something familiar.

Coming from 2004+ Subaru, where the ECU uses floating-point and the tables in ROM have the axis values stored in arrays, this GM stuff is weird. But I guess floating-point was still a few years away from being affordable.

The more I screw with this the more I want to start over with an Arduino... That's a lot easier said than done, but if someone finds a way to put an Arduino into a box with P01/P59 connectors on it, I'd be all over that.

What else are you working on? I got some very valuable help a while back from a guy who was working on Lotus ECUs that also use the 68332, and the same flash chips too.
http://www.romraider.com/forum/viewt...hp?f=7&t=14805

 

I'm finding that the two key differences between the 33 column crank VE table and the 20 column VE lookup table are the following

The 33 wide table does this
LSR #1,D1 ;MAP kPa / 2, now MAP x 25.6
SUBI #512,D1 ;Sub 20 kPa offset

LAB_3CA9:
MOVE #2048,D1 ;Load D1 with 100 kPa, max allowed value
LAB_3CAB:


the max MAP value that gets fed to the 3d lookup is 2048, 25.6 * 100kPa. The number of rows is 33.



VE does not divide by 2, so it stays as the kPa * 51.2.

MOVEQ #40,D2 ;Load D2 with size of rows


So if we scale the number going into those properly it will treat that table as a 2bar table. Another thing to try would be moving the VE table somewhere else and doubling the size of it. The method that does the 3d lookup does not seem to care how big the tables are. A nice part about that is the whole table is referenced already.

EXT_0156 EQU $835E

I don't know what that means or where to find that command, but that is what is called when the main VE 3d lookup is called. It connects it to a different spot in the rom. Maybe it is storing that value in ram so it is faster to call?

LEA EXT_0156,A0 ;Load A0 with address of main composite VE table
LSR #3,D0 ;RPMs /8, now RPM / 1.5625
MOVEQ #40,D2 ;Load D2 with size of rows
JSR EXT_00D4 ;3D lookup routine


The 51.2 and 25.6 are important. If a longer map for a 2bar is successful then doubling the range of the map could be achieved by adding a piece of code to make the value kPa * 102.4. Bigger number, larger jumps per kPa through the map. A lot of other things may need to be scaled, but some things may not.


;
;-MAP kPa x 51.2 = (4835 x 64 x A/D MAP)/65536 + 529
;
LAB_4117:
MOVE EXT_07FE,D5 ;Load kPa offset for A/D MAP
EXT.L D5 ;Sign extend
MOVE EXT_07FD,D3 ;Load scalar for scaling A/D MAP
MULU EXT_22E6.W,D3 ;A/D MAP x scalar
LSR.L #8,D3 ;/256
LSR.L #8,D3 ;/256, now /65536
ADD.L D5,D3 ;Add in kPa offset to result
TST.L D3 ;Test D3
BLT.S LAB_4119 ;Bra if MSB of result set, invalid result
;
CMPI.L #$0000FFFF,D3 ;Compare to max allowed result
BHI.S LAB_4118 ;Bra if >, result out of range
;
CMPI #5375,D3 ;Compare result to 105 kPa, max allowed value
BLS.S LAB_411A ;Bra if calculated MAP <=
;
LAB_4118:
MOVE #5375,D3 ;Load max allowed value
BRA.S LAB_411A ;Bra to continue


If you check out the map sensor scaler value the 4835 value will be familiar.

0xFFFF is 65,500 or so. If we keep the 51.2 multiplier for a 4bar that would be 51.2 * 400, 20480.

For now just moving and doubling the table would be great!

That would be nice. I have tuned a few Subs, but it is not my favorite. I know that GM knew how to make the load axis a set of modifiable tables. $59 could do it and that was using a chip from the 80's.

Lol I was just telling my friend that the more I look at this code the more I wish it was a speeduino, especially when it comes time to flash it. We also came to the conclusion that there are likely zero completed, pinned, IP rated speeduinos in any junkyard anywhere in the world. I have a whole mess of micro controllers. I'd like to see an ESP32 based throttle body or batch injection system with coil on plug support.

I used to help with the MS42 RR group, I didn't get really far. The car popped a head gasket and the cost was verging on a whole LS vehicle, so that's been on my mind since. Also have a friend looking to get a box to replace a ME7. Focusing on a P59 would be good then there are options for all models. Having DBW is really cool too.

Have you ever looked at this?

https://www.nxp.com/docs/en/user-guide/MC68332UM.pdf

It doesn't look like it has a built in A/D converter. Does that mean it is external and soldered to the board?

 

I do think they have a rescaled copy of the MAP value (and other usething things) just for table lookups, so that they only need to scale it once, rather than scaling it before each table lookup.

My thinking for 2-bar / 3-bar stuff is that we should not change the scaling by much. With a 1-bar MAP sensor 0-5v means 0 to 100kpa, and in the PCM there's a 16-bit value that maps (no pun inteded) to that 0-100kpa range.
With a 3-bar, the same 0-5v range means 0-300kpa, and with no code changes that same 16-bit value just means 0-300kpa. The main thing that really needs to change is the MAP axis header values in the XDF file.
We'd also have to change the tables that tell the PCM what MAF values make sense for the newly redefined MAP value, so it doesn't throw codes, or maybe you could just disable the codes and skip that part.
I wrote about this a while back here - https://pcmhacking.net/forums/viewtopic.php?f=42&t=6278 but the conversation just kinda tapered off.

The only thing that worries me is what tables might also depend on the MAP value that we don't know about. But PeteS told me that somebody out there is running a boosted car this way already, in fact that's where I got the idea.

Speeduino is apparently going to support sequential V8 pretty soon. But in order to actually make the switch I'd need to cut up an old PCM and re-use the connectors, so I can easily swap back and forth between the Speeduino and a known-good OEM PCM. I'm afraid to dive in without a backup plan. I probably will at some point but I've got too many irons in the fire already and I want my car to be 100% dependable for track days.

Yes, I have that PDF. There's also a "programmer's reference manual" that goes into more detail about the instruction set. You can probably find it with a web search for "M6800 family programmer's reference manual includes cpu32 instructions"

I think the ADC is on the chip, but I'm not certain. But here's the function that handles the "get PID 000B" operation:

OS2:000456DE GetPid_000B_ManifoldAbsolutePressure
OS2:000456DE clr.l d0
OS2:000456E0 move.w (Pid_000B_MAP).w,d0
OS2:000456E4 divu.w #$33,d0 ; '3' ; 0x33 = 51
OS2:000456E8 rts

Pid_000B_MAP is FFFFADB8, and there are only a few cross-references to it, and only one of them writes to it... The function at 7658E reads FFFFF2BC, does some math with the MAP offset and scaling values, sanity checks the result, and writes to Pid_000B_MAP, so I assume that FFFFF2BC is the raw value from the ADC. I don't see any code that writes to that address, but there are a couple places that read from it.

 

In other news, I just realized that I have an unlocked XDF for the '7603 1MB PCM. This was created by dzidaV8 and I'd forgotten all about it.

You'll want to remove the ".txt" from the end of the file name, I just put that there to make sure that I can attach it.

BoredTruckOwner, can you add this to the repository on GitHub?

 

That is one method to tuning, but I think we can make it a lot easier on ourselves with a bit of work.

The best way to get one of those is to brick a box I just got an OBDlink MX+ and someone on OfferUp is supposed to be shipping me a 9463 with pigtail. Any advice for doing a read for the first time? I also want to plug into our Volt and see what it is up to.

kPa is stored as a 16bit number. The number = kPa * 51.2

It is stored in at least two different places in the ram
EXT_1A2D EQU $FFFF9C5C ;Stored MAP kPa, val = kPa x 51.2
EXT_22E8 EQU $FFFFADA2 ;MAP kPa, val = kPa x 51.2

If you look at Main routine to calculate the cylinder airmass you'll find this line

MOVE EXT_22E8.W,EXT_1A2D.W ;Update MAP kPA

So they are equal to each other at the start of that routine. I'm assuming one is for a long process that could be interrupted and one is stored for short processes that get updated frequently and are interrupts. Now, where it is updated from the ADC happens in the Routine to read in and update manifold absolue pressure

LBL_$75F9C:
MOVE EXT_2575.W,D3 ;Load D3 with A/D MAP
LSR #2,D3 ;/4
ASL #8,D3 ;x256, now x64
MOVE D3,EXT_22E6.W ;Save it, A/D MAP

there's a few calculations and shifts going on here, but ultimately this method turns the a/d ticks into a number that represents kPa * 51.2 using this number

LBL_$16C02:
DC.W 4835 ;4.72, scalar for converting raw A/D MAP to kPa

When you double that number the number being fed into the map lookup tables doubles for a given voltage. This is really useful and it is something anyone could try right away.

If you double the map scaling and adjust the offset along with adding a 2bar map the vehicle should run just like stock. We have scaled the MAP sensor output, but we are still talking the same values as before. 1bar map at 100kPa is putting out 5V and feeding the tables a number of 5120. The 2bar map sensor at 100kPa is putting out 2.5V and feeding the tables a number of (this is the clever part) 5120.

This means all the tables and functions that deal with the MAP sensor, known and unknown, will function exactly the same. This will not allow you to tune in boost, the tables need to be scaled to do that. If you were to go past 100kPa the table reader would start reading the next table. It will not allow you to exceed the maximums, and those come from a few different places. It's good to be in control of those limits

This system looks like it was built to scale the map sensor. Do you know of any GM vehicles that had a PCM like this with boost? LS Droid says it will read V6 and LB7 PCM. Do you know anyone who uses those that is looking into this stuff?

In order to scale the load axis on the tables we need to be able to change the

MOVEQ #40,D2 ;Load D2 with size of rows

command. That #40 needs to be either 20 or 80 for a 2bar and 10 or 160 for a 4bar. Otherwise it will only consider 15-105kPa, 768-5210, before it starts to eat into the next table. If the table is moved to somewhere it can be larger nothing needs to be done for a 2bar sensor and that number needs to be halved or doubled for a 4bar. When this number is changed remapping the values is necessary. If the table is doubled the bottom half of the table can stay totally stock, or totally however it was tuned NA.

I wish these things could physically rev higher.