pcmhacking.net

good progress!

I see there is a:
in the bin prior to putting the chip in to A0A0 mode. Not sure which register that is, assuming its a sim register. clearing a single bit. Something to check if there is another value that needs updating at the top of the Amd_WriteToFlash() command.

No FA50 registers currently ...

Also not sure where your seeing A0A0 around that.

In the Os, the write routine starts at D8588, in the kernel FFFF0000 it starts at F213C.
I cannot find that actual byte movement loop ...

However, I have a thought, scary as that might be ... Bear with me on this for a moment.
The datasheet has no mention of byte mode, only word mode!

Our write routine uses a short (16bits), we are only writing a byte (8 bits) ...

Maybe we need to write two bytes (16bits) versus the 1 byte (8 bits). Thoughts ??

Edit;
Ok, It looks like my math stupidity has proven me to be so ... STUPID! Umm, that is clearly writing half the bytes, so it's already writing two bytes (16bits) at a time!

Yeah, data sizes like word are machine dependent. In c, to find out what your compiler is calling what you can use the sizeof() macro. Or for embedded you generally use types that do specify the size. All well and good, but that doesn't tell you what is what in the data sheet. None the less thats just an interesting point for someone reading this. In this case, since the rest of the code is working so far, I'm leaning towards the main routines are correct, and because its the same platform its purely the hardware interface parts which are different even if not significantly.

When I search for A0A0 in data in the bin I get two hits. Although now I check my work I see I have two disassemblers open my desktop and that code reference is the IDB from earlier in the thread, not the bin like I have been preferring to work from.
In the idb there is a subroutine at FFFF213C which does the

RAM:FFFF215C move.w #$AAAA,($AAA).w
RAM:FFFF2162 move.w #$5555,($554).w
RAM:FFFF2168 move.w #$A0A0,($AAA).w

So then I look at the caller of that function and I see a routine at FF2520 which has the abovementioned code before calling the FFFF213C routine.

Edit: now im looking in the bin I dont see the same code in the same place. I do see a number of them at boot time and other places and they do look like they're controlling hardware, but they don't look like specifically anything to do with the flash programming. maybe its more timer code or something like that.

Well, that makes me feel better ... At least I'm not missing everything, just something!

But not about C data sizes and machine dependency or what I'm seeing in the two disassembles ... Definitely two different routines.

I think it's safe to assume the SIM addresses range from FFA30 - FFA7E, whatever we're looking for would likely be in that range (or very close), it would be being done in both disassembles.

The SIM (System Integration Module) addresses are currently defined as, IIRC we had a erie familiar issue with the P59 and SIM_CSBAR0.

darkman5001 wrote:

MudDuck514 wrote:I have an opportunity to get some PCMs from my local salvage yard. Does anyone KNOW what years the P10 vs P12 usage was?
There are 2002, 2003 and 2007 Trailblazers.
Doesn't list any other vehicles with the 4.2l, nor any of the cars.

Mike

2002 and 2003 use the P10, and 2007 uses the P12.

Here's a breakdown of the different GM platforms that use the P12 (and P10):

4.2L I6 (TrailBlazer/Envoy/GMT360/370/305 platforms):
02-05 = P10
06-07 = P12
08-09 = E67 + T42 (all are factory automatics)

I4/I5 (Colorado/Canyon/H3/GMT355 platform):
04-07 = P12
08-12 = E67 + T42 (all are factory automatics)

05-07 Cobalt SS S/C, Ion Redline, Ariel Atoms

I'm probably forgetting a few oddball ones as well, these are the main areas GM used the P12.


Gampy/Tazzi/antus/darkman5001 - GREAT progress!! I've got an extra P12 PCM, bench harness, and a Mongoose cable if we need to test on another PCM.

hmm, Iv found so long as the VPP pin is held high (12v), thats all that really counts. This was the SIM_CSORBT command having 7060 sent to it for P01/P59 (move.w #$7060,($FFFA4E).l)
And putting back to 3.3v with move.w #$1060,($FFFA4E).l

Whether thats all thats needed on the P12.. not sure. Ill have one to mess with in a few days. At least Im hoping its a P12 haha, its got the triple plugs.
I thought I had one from a while ago, but that was a P04 unit (looks like a P01/P59).

So if I read that correctly then the P12 was used on 4,5, and 6 cylinder engines. Which would be really interesting they all used a common Operating System with different calibrations like the P01/P59 did.

bubba2533,
All I know of is I5 and I6, don't know if they were used on the I4's ...

Tazzi,
It's SIM_CSOR0, However, the AMD does not use an actual voltage change like the Intel ...

Gampy wrote:bubba2533,
All I know of is I5 and I6, don't know if they were used on the I4's ...

Tazzi,
It's SIM_CSOR0,

Code: Select all

#if defined P12
	SIM_CSOR0 = 0xF322;
#else // P01/P59
	SIM_CSOR0 = 0x7060;
#endif
.
. Wacked for brevity
.
#if defined P12
	SIM_CSOR0 = 0xA332;
#else // P01/P59
	SIM_CSOR0 = 0x1060;
#endif

However, the AMD does not use an actual voltage change like the Intel ...

Ah, I didnt know that, I havent every probed on the AMD, only on the intel.

maybe we should be looking at this one? Page 40 of the data sheet. Specifically im wondering about WE# for write enable. Do we leave it high? It seems we need to during programming.