P11 GM PCM

[DWS]

Thanks for the links, quick peek seems to be good info I need.

A template/jig would be nice, but I'm hitting a bunch of different PCM's lately. I just solder in a header to the ulink and plug it into whichever PCM i'm messing with.

I bought 5 PCM's from a member on here, just got them in this morning. I'm told I'm the first to crack into the P05's, it's basically a E40 hardware wise, right pins and it reads and writes using the E40 config.

I worked out the pin out for a couple P04's I got in the lot, so going to test and make sure I got things right. Clearly I'll have a lot of bin files to play with lol. Only have 1 car that runs any of these PCM's though, so the focus is more or less on the P11 until I can get another vehicle to toy with.

Now that I know what to look for and the basics on how to do this stuff, it seems pretty easy, hardest part is figuring out the CPU part number. I've just been lucky and have been having help with that process.

If/when I publish this info, I'll have to make a thread per PCM type and make an index or something. Forums are great but not real good for easy finding the data per pcm and such. It's way better than facebook though!

I also have a P01 which I'm sure is nothing new to discover there and another P11 I need to poke at and see if it has the watchdog enabled or not. The board name/letters matches the one I have w\o watchdog so I think that might be a pattern if it matches up.

I'm also building a database of PCMs based on serv + calibration/hw number and logging details like cpu, flash, fitment, iac driver (for p01/p59/p04), watchdog, etc. It might be easiest to publish the info to a fairly simple website and allow user submissions too.

I like the concept in that segment swap thread, I had the same basic idea. I figured a script to find all of the memory calls in the OS and try to somewhat automate the identification of the stored settings. Clearly I need to do it manually first and on more than one PCM to get a grasp of it. This adventure has been hitting like every skill I've built up, it's almost like I trained my whole life for this stuff with out even knowing it lol.

Either case, it's been really interesting to learn so far. Once I have more time to dedicate to breaking down the bin files, I'll have to see how far I can get. I read there's like 600+ settings that can be mapped (more or less based on os etc).

[Lunatic]

I'm not sure if this is of interest to anyone, but I've attached a .BIN file from one of these P11 ECU's. (2003 Cavalier, 5 speed, Ecotec 2.2 engine).
Immo/VATS is off and perhaps it could be of use to examine, reverse engineer, etc.
VIN-1G1JC52F537286653 (Seen on lines 402D-403D)
OS-12593523

[AngelMarc]

How did you manage to disassemble that?

[DWS]

It's a royal pain with the case glued together. Back then I had a cheap china desoldering gun and the big ground pins were a massive fight. I have a nice Hakko one now that would probably do a ton better. Even after desodlering, the glue is on the board a little holding it down to the case so fun working it out.

Being able to flash them over OBD2 is basically a must in the long term, not sure if there's been any progress on that though, I just helped with some of the hardware pinout research.

[antus]

From a quick disassembly it looks like watchdogs are at FFFA27 and 800806 and DLC is FF6000 (we ignore the high byte as its a 24 bit address bus internally and makes no difference if its FF or 00 or anything else). This lives in Common-Assembly.h in the kernel dir. There is a parameter block at 0x4000 but the seed / key looks a little different so would need to see an example of an unlock from another tool to see where it is exactly here and then determine which algorithm number through trial and error with the algos in PCM Hammer. From this it can also be determined what kernel load address to use and if the stack needs to be moved on kernel init to clear out some ram (Kernel.S). With this information that is enough to add P11 to the PCM Hammer Kernel (build.cmd) and app (PcmIinfo.cs) and see what happens. At least, if this is a VPW PCM in the first place. Being a different series of flash chip that may also need to be defined by ID in the FlashChip.cs file. Then on a lucky day it works first try, or on a regular day something unexpected happens or we get a crash and it's time to start experimenting. If it does work for read then the VPP enable and disable needs to be identified and lock/unlock updated (Kernel.S) as this seems to vary more than other parts of the process between VPW PCMs.

Watchdogs patterns:

Code: Select all

move.b  #$55,($FFFFFA27).w 
move.b  #$AA,($FFFFFA27).w
bset    #7,($FF800806).l
andi.b  #$5F,($FF800806).l 
rts

DLC Patterns:

Code: Select all

cmpi.w  #$6780,($FFFFF600).w
seq     ($FFFF9207).w
bne.s   loc_5A2
moveq   #$B,d3
lea     (unk_494).w,a2
lea     ($FFFFF608).w,a3
move.w  #$A,(a3)

loc_588:
move.w  (a2)+,($FFFFF60A).w
dbf     d3,loc_588
moveq   #$B,d3
move.w  #$10A,(a3)

loc_596:
move.w  (a2)+,($FFFFF60A).w
dbf     d3,loc_596
move.w  #$20A,(a3)

loc_5A2:
move.w  #$370,($FFFFF606).w
move.w  #$85,($FFFFF600).w
rts

After a bit more looking it seems the above matches the P10 and it also has the same SIM_BASE as P10, so treating it exactly like a P10 would be a good starting point.