The command 0x7428 at 0x06F884 is the MOVEQ that makes the table spacing. 74 is the command and 28 in hex becomes 40 in decimal.

PG 238 of the manual explains how the MOVEQ works, 0111(xxx)0(yyyyyyyy) where x is the register (010 for D2 in this case) makes 0x74 and (00101000) decimal 40 makes 0x28.

Now, the question is, do we make that 01010000 or 00010100?

Are the checksums bad to deal with? It looks like LSDroid just fixes it for you before it will ever let you flash something bad.

I have to finish some other projects for a while. I'll check back when the box gets out of quarantine.

 

This is what I used as a reference for building my bench harness:
http://www.gmtruckcentral.com/articl...h-harness.html
I don't recall whether anyone has tested with the MX+ and PCM Hammer so if you could give that a try I'd love to know how it goes.

As far as tables and scaling... I'd rather cut the table resolution in half. My Subaru seems fine running 22psi+ with smaller tables than what GM used for these naturally aspirated cars.

I can't really help with the GM questions... the only GM vehicles I know anything about are C5s and I still have a lot to learn about the one in my garage.

 

I couldn't stay away

Looking at the P01 disassembled ROM at 0x6f87C the code

41 F9 00 00 83 5E E6 48 74 28 4E B9 00 00 16 10

LEA EXT_0156,A0 ;Load A0 with address of main composite VE table

All the way at the top of the document we find out that

EXT_0156 EQU $835E

00 00 83 5E is the location of the main VE table. To move the table it is looking for into the blank space in the transmission section it can change to 0001B070

E6 48 is a LSR bit shift to divide

74 28 at 0x06F884 is the MOVEQ previously discussed. Changing the 28 to 14 or 50 scales the MAP input

4E B9 00 00 16 10
JSR EXT_00D4 ;3D lookup routine

again we find that EXT_00D4 refers to 00 00 16 10. This could send us anywhere on the rom.

41 F9 00 01 B0 70 E6 48 74 14 4E B9 00 00 16 10

would be our new code.

This is also how the XDF helps you define functions in the disassembly. If you know what the maps are you can know what is happening when the code is looking for them. Once all the functions that you want are defined you go in and change them around. Hopefully there is a robust reflash procedure for a bricked device :-/

Which P59 ROM do you think has the most features? It is easier to turn off a DTC than add code to initialize pins or shift maps around. We can move on to annotating the disassembly of that instead of the P01.

The P59 ROM is huge, they had space to add so much. I have to double check the flex fuel bins but it looks like a 4bar table will fit without any issues or scaling. 6 bar looks to be about the max without changing how it is stored or called (signed 16bit). I won't be needing a 6 bar map sensor lol.

I just found the github repo for PCMhammer, great work dude! All this time I thought your icon was expressing your frustration with the PCM. I don't know how to compile it for linux, if you do I can try it. I could throw windows onto a laptop, but I really don't want to.

 

12587603 is the OS that is being talked about a lot for the P59 PCM

 

I bought a similar bench harness off a guy off ebay. I was the one who first tried the MX+ which worked fine for reading on the bench with an 512k. Other than that though, I've never tried anything else, or writing to the ecu ( think I did change the VIN though )
No car to test anything on anyway.

And if you've ever worked on an old Possum Link ecu for a Subaru....the original was a called a 6 row link. In that it had 6 rows for the MAP values. Yes...6 LOL That didnt leave a lot of resolution when using a 3 bar sensor. But it did still work ok.
I'd never go back to one though

 

Indeed there is. The 68332 has a feature called Background Debug Mode, or BDM, that's basically JTAG. There's a $50ish USB device that needs about 10 solder connections or a pogo-pin fixture. It comes with software that's a little tricky to figure out, but it works very well.
https://www.usbjtag.com/zenshop/inde...products_id=11

This thread is pretty long and overdue for a summary since the important bits are scattered all over in it:
https://pcmhacking.net/forums/viewtopic.php?f=42&t=6215

And here's a 3d printable fixture:
https://www.thingiverse.com/thing:3565197

Once you get it hooked up, it only takes a minute or two to reflash a P59 or P01.

Thanks! In theory you could compile the main library on Linux if you install .Net Core. There's also a smaller library with platform-specific stuff like opening and closing serial ports, and that would need to be rewritten, but I don't think it would take much work. The UI might need to be rewritten, but I suspect that a command-line version could be created pretty easily.

Cool, thanks for testing the MX+. If it can read then it can probably write. Probably.

The only Subaru I've got much experience with is my 2005, which has fuel and timing tables that are 16x18. So that feels about right to me for a 3-bar setup.

 

Yeah, we have two good XDFs for it, and one of them is unlocked, and factory bin files files seem to be available with every combination of options, so I think this is the winner.

I have a PCM with this OS on it, and I plan to put it in my car. But first I want to get a second one to work with at my desk. I'll get around to it eventually.

 

The old 6 row link was the early 89-96 cars. Wasnt really a lot of options near 20 years ago to be fair though and the Link's were cheap. I think the model after than became a 10 row.
With std map sensor and less range, resolution wasnt so bad. 3 bar it was just silly..but as said, it work ok despite this.

 

Can we choose a 7603 bin to focus on so we do not have to do disassembly work multiple times? Or is that the purpose of the OS, that all the code functions are the same between bins? Anyway, a disassembly to commentate would be very helpful. I spent about 2 hours trying to find an open source disassembler. I don't know how to build ghidra with the CPU32 branch so hopefully that gets put in there soon. I should have followed the instructions, maybe some other time. I found this on a Saab Trionic tuning forum but I can not make it work

https://onlinedisassembler.com/odaweb/Pqoog1pg/0

and this

https://github.com/Obeisance/Motorola68K_Disassembler

I might be able to build that. It ran under wine, but I could not figure out how to use it.

Just from the information in the annoted disassembly you can look at a 7603 bin and xdf and learn a lot. For example we know the main VE table is 84 42 and the code to load a table address before 3D lookup is 41 49. If we search for 41 F9 00 00 84 42 at 0x79B92 we find

41 F9 00 00 84 42 E6 48 74 14 4E B9 00 00 16 D6

looking mighty familiar. We can safely say we know where the 3D table lookup routine is located (do you know where?), so that's another tool we can use to annotate and disassemble.

We also find something similar at 0x7A176, and there we see a 74 28 command, so those numbers are a way to scale the row lookup value. I don't think we will need to do that though. Finally we see the 41 F9 00 00 84 42 again at 7A96E. Why are there three functions looking at the main VE table and why is one scaled? We won't know until we disassemble more. In the annotated P01 there are 3 main VE lookups, all use 74 28.

Calculate air mass per cylinder based on MAP
Calculate maximum possible cylinder airmass
Routine to reset dynamic fuel air calculation variables

We could try something really silly like scaling the kPa * 51.2 number up and having a 1bar map sensor in a table with 76 rows.

Does the LTFT data get written to the rom or is there a spare always on memory?

Makes you wonder if a black magic probe could be used as a BDM tool.

 

​​​​​​​Wanted to add on to this, there are actually 3 good XDFs, but they all have differences between them, what I was trying to do before the pandemic is sort through which of the parameters were pointing to the correct addresses. The 3 XDFs are extremely similar, IIRC the above XDF was pointing to a different address for the DFCO enablers so it ended up being set aside, and I unfortunately only have my daily so I can't test if those addresses are correct without potentially bricking my PCM.If there are any volunteers who are willing to experiment, PM me and I'll get everything I have sent to you. The XDF above is under the experimental section, just until we can verify which of the XDFs is pointing to the correct locations.
Hopefully, you all are doing well and staying safe with the pandemic, work has been driving me crazy so I can't dedicate much time to the repo, but I'll try to roll out what I do have ready to the wiki in the next couple of weeks.
Paul

 

Hello,

Sure, I will give it a try. I have five different PCM's here - four different P01 devices and one P59 -- all in previously verified good working order. If it bricks it, I have wanted a reason to try a recovery and this might be it. And if it doesn't recover, there's plenty . . . PLENTY more around here in the yards for very short money on Half Price Sale Days.

Rick

 

PM sent, thanks for volunteering!

 

It's my understanding that the only differences in the various 7603 bin files are in the flash chip's calibration block - in other words, the OS code is all the same, only the data is different. I haven't verified that myself, but all signs point to that being the case.

Some table lookups are done in a shared subroutine, but in a lot of cases (most, I think) the table lookup CPU instructions are just invoked directly. There are a few opcodes in CPU32 that do most of what the table-lookup functions do in Subaru ROMs. It's a surprising amount of logic to pack into a CPU instruction.

I am pretty sure I can dump a complete disassembly out of IDA, but it'll take some time since I haven't started a 7603 OS yet. I'll get to it soon though.

There are two "parameter" blocks of flash memory reserved for data that needs to persist across power cycles (battery disconnect, not just key off/on) but as far as I know that's only used for OBD2 fault codes and some similar diagnostic info. I think the trims are just stored in RAM.

 

Hello Paul,

Using Tuner Pro RT, I went through the one megabyte 7603 OS copy that I have here from a 2004 Chevrolet SSR truck and edited it using the XDF file you sent me via email. I then attempted to write it to my one P59, 1 megabyte PCM device using LS Droid.

LS Droid version 0.2.2 did not like it. It complained about "invalid checksums" and then asked for "Tell me more" information and then went into a large text block saying "This is unexpected" giving many reasons why this is not a proper condition to continue the writing.

So, I did not brick my P59 PCM because LS Droid would not let me get that far.

A few other notes using your XDF and please forgive me if I sound like a knuckle dragging moron here because I probably am. I could not see very much of the usual context sensitive help in the parameter tree view of Tuner Pro using your XDF file. I realize this is an experimental XDF and those words might come later but those tool tip words help us tuning Neanderthals a lot.

In the DTC sections - What is meant by the addition of the word "Action" at the end of the line P0137, for example? There appears to be two things to do with DTC P0137 (again, for example) - one in the line without "Action" and more in the line with "Action". With other XDF files I've used with Tuner Pro RT, I have not seen methodology like this.

The "Lean Cruise" patch would not enable. I tried the "OS Patches" area at the bottom of the parameter tree view and I could not get it to apply. Tuner Pro complained . . . "Patch aborted. Base data does not match". Is there something else to do prior to enabling this OS patch?

Many thanks for trusting me with this. Learning is always good and no harm to any device here.

Rick

 

For all the stuff I know about computers I still don't know how the checksum is done. It is a way of verifying data integrity and there is supposed to be a plugin for tunerpro to do it automagically for both the P01 and P59. I wish it could be integrated into an XDF. Maybe we should bring that up with the tunerpro dev's. If you're not making custom code it should work within an XDF every time. If you are doing custom code you should know how to change the XDF to make it work.


The checksum data starts at $0500 in the 2088 and it appears the 7603 bins.

In a 2088 these are the 5 checksums

3D 37 00 01 00 BA 30 68 42 42

And these are the locations

start end

00 00 00 00 00 07 FF FD

00 00 80 00 00 01 3F FF
00 01 40 00 00 01 6D FF
00 01 6E 00 00 01 BD FF
00 01 BE 00 00 01 C7 FF
00 01 C8 00 00 01 E5 1F
00 01 E5 20 00 01 EE 9F
00 01 EE A0 00 01 EF 9F



7603 is here

D2 E8 00 01 00 C0 12 53 44 43


00 00 00 00 00 0F FF FD

00 00 80 00 00 01 62 CF
00 01 62 D0 00 01 95 FF
00 01 96 00 00 01 D8 AF
00 01 D8 B0 00 01 E1 AF
00 01 E1 B0 00 01 F6 BF
00 01 F6 C0 00 01 FE AF
00 01 FE B0 00 01 FF DF

The first addresses cover the whole rom. It's fun to see the 2088 with a 00 07 FF FD final address and the 7603 00 0F FF FD due to the 1mb rom. Also neat to see the first checksum address starts at the same place for the fuel calibrations, whatever they needed to do in the first 80 00 bit of space hasn't changed so much they needed to expand it.

Seeing the way it is stored in the flash we might be able to aim where the checksum is looking to a set of blank spaces and have a checksum that is correct to the PCM and lsdroid no matter what is done to the code. This would obviously only be a good idea if you had a BDM tool or liked to live dangerously. It would be best to have a checksum tool that could be applied before flashing. This is what I thought lsdroid would do, or at least give you the option to fix it.




I'll do a bin compare on the 7603 bins we have in the repo. At the very least all the function subroutines should be the same. Getting half way and then doing all of this over again for a different OS would probably make me lose interest in the project.

To me it looks like the CPU32 table read is for a 2 dimension table. It treats 3D tables as really long 2D tables and uses the row length to index to the next row. The full code for the unsigned 16bit 3D lookup is listed below. The other 3D table subroutines act the same and are called (as far as I can tell) whenever there is a 3D table. Looking at it again it makes a lot more sense to me. You always interpolate to the next column to the right and the row below. Interesting to know for tuning

In the 2088 bin the code at 0x1610 is

36 01 E0 4B C6 C2 D1 C3 36 00 F8...

When we search for that sequence in the 7603 we find it identical and right where it was expected at 0x16D6. A lot of the code after that is identical too. My eyes went cross after a few rows. We can do bin compare and find big sections that are the same. So we should already have big portions of this disassembled and annotated for us, which is good because there is a huge amount of junk that hasn't been annotated in the 2088 and even more in the 7603. We're not even fully sure if the annotated code is done correctly, but it looks very good so far.

If the processor can write to the ROM to store long term fuel trim data then the procedure for writing data to the ROM through software written on the ROM is somewhere in this disassembly. When we use BDM we mind meld with the processor and force it to write to the ROM, so it is obviously able to. With a half meg of space we could have a lot of fun.

;~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;
; 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
;
; Out:
; D0 = Result
;
LBL_$01610
MOVE D1,D3 ;Load value for row lookup into D3
LSR #8,D3 ;/256, now row offset
MULU D2,D3 ;Row size x row offset
ADDA.L D3,A0 ;Add in offset to base address of table for
;desired row
MOVE D0,D3 ;Move value for column lookup into D3 as well
TBLUN (A0),D0 ;Look up column value in row and interpolate
TBLUN (A0,D2),D3 ;Look up column value in next row and interpolate
TBLU.L D0: D3,D1 ;Interpolate column values between rows
ADDI.L #$00000080,D1 ;Round up if needed
LSR.L #8,D1 ;End result /256
MOVE.L D1,D0 ;Load result into D0
RTS ;Return

 

Thanks for checking it out, should have checked the thread first. That XDF is one I actually found searching, I too am still trying to understand what's going on, I've run it through winmerge a couple of times trying to compare the XDFs but I never got too far before things got busy. I hear you on the comments, those have been a work on progress, I sent you the original XDF, I've been working on restructuring, adding comments, and comparing each parameter to the other XDFs. I haven't made any progress for the last couple of months though because of work, things are finally starting to slow down so I'm trying to get more time put into getting one good XDF put together. As for the lean cruise, I thought it may have been because the tables were empty, which is why I was asking for an Australian BIN file. The Australian cars came with lean cruise enabled from factory.
Paul

 

Hello Paul,

I've read that domestic U.S. production Pontiac GTO engines had a Lean Cruise capability - model year 2004 . . . I think???? Not sure why the EPA let that capability through their emissions controls but you might look for a BIN from a GTO if you need one.

Rick

 

​​​​​​​I heard the same, I've been on the lookout for any bins of lean cruise enabled cars. In a different forum, I also read that some of the commercial software options also cannot enable lean cruise because our PCMs are locked out, I'm not too sure if that's at the OS level or the software providers faced legality issues with EPA regulations. All in all, I'm still on the look out, if anyone else has an idea or would like to mess with the checksums let me know and I'll get that XDF sent over. As stated previously, the XDF is completly barebones, you'll need to understand each parameter given just a name like C.A.G.S, there are no comments to help.
Paul

 

There are two kinds of checksum... The calibration segments have a simple checksum that is built into Tuner Pro, and the XDF basically just tells Tuner Pro where the different segments are and where to put the checksum code. (If I remember right, it's something like "add up all of the 16-bit words in this address range, and get zero." And the last two bytes are tweaked to make the requirement true.) That covers the calibration stuff, so it is sufficient for most folks.

The OS segments use a different checksum that has to be implemented in a DLL that Tuner Pro loads as a plugin. And here's where the story gets interesting...

Antus over at PcmHacking.net created such a plugin. Another user then ripped out the copyright notices and changed the GUID that identifies the plugin, and took credit for it, and is/was selling it as part of an LS tuning package that's on ebay and I'm told is expensive, buggy, and poorly supported. So that's pretty ugly. The locked XDFs were created by someone else, who probably didn't know that history. Those XDFs reference the hacked plugin. Most people won't change OS code, but if they do, they will probably need to get a copy of the hacked DLL.

Unless of course those XDFs get unlocked, so they can be revised to use the legitimate DLL, which properly credits Antus for writing it.

And thanks for disassembling the table-lookup function, that's cool.

 

By the way, I opened up a 12587603 operating system in IDA and disassembled and labeled everything I could automate... which is basically the contents of DzidaV8's XDF plus the functions that handle the PID requests (there's a table of PIDs and functions in the bin file, which is handy).

The results are on GitHub, here: https://github.com/LegacyNsfw/12587603

I also started a thread about it, here: https://pcmhacking.net/forums/viewtopic.php?f=42&t=6734