Protocol for reading the PCM Flash Memory

[Keith@HPTuners]

Make sure key is on Position, engine off.. and enough battery power.

Disable normal message transmission on all nodes
Send: 6C FE F1 28 00
Rec: 6C F1 <active node> 68 00

Read Seed - Data Link Security Access
Send: 6C 10 F1 27 01
Rec: 6C F1 10 67 01 <2 byte Seed>

Send Key - Data Link Security Access
Send: 6C 10 F1 27 02 <2 byte Key>
Rec: 6C F1 10 67 02 <Sucess status?>

Request High Speed Mode From All Nodes
Send: 6C FE F1 A0
Rec: 6C F1 <active nodes> E0 AA

Begin High Speed Mode
Send: 6C FE F1 A1
Rec: 6C F1 <active node> EF

Scan Tool/Test Device is Present
6C FE F1 3F

<DOWNLOAD BOOT LOADER>


Request Upload
Send: 6C 10 F1 35 01 <2 byte size> <3 byte start address>
Rec: 6D F1 10 75 01 54 (Request Response)
Rec: <Data block>
Send: 6C 10 F1 76 00 54 (Block Transfer Response OK)
Repeat

Return to Normal Mode
Send: 6C FE F1 20
Rec: 6C F1 <active nodes> 60

[Keith@HPTuners]

6C,10,F1,35,01,LH,LL,AH,AM,AL,CS

PCM replies

6C,F1,10,75,01,CS

LH/LL = High/Low Byte of length of data requested
AH/AM/AL = High/Mid/Low Bytes of Address of data

Reply equals happy success (35+40 = 75)

Next, the PCM will reply:

6D,F1,10,36,01,LH,LL,AH,AM,AL,DC,CS

(Note, I think the 6D means Physically Addressed
Block Transfer mode or something like that!)

DC = the XOR checksum (I think) of the data that
you are about to be forcefed.

Then the thing spits "length" bytes of data at you.

You XOR it.. if your XOR and the DC above match you'd
send the following to the PCM:

6C,10,F1,76,00,CS

Indicating that the data was happy.

Now, repeat that for addresses 0x00000 thru 0x80000
and read out an LS1 PCM ;D

One thing is very intersting.. notice how there is a 2 byte packet size field.. Makes ya wonder what cables might just do the job.

[Hera]

Magnus, I think I found your Seed and KEY for a GTP

Request: 4/14/2003 9:42:12 AM.078125064 (+0.0000000000 seconds)

30 00 05 6C 10 F0 3C 08 1B 0..l.ð<..

Answer: 4/14/2003 9:42:12 AM.093750064 (+0.0156250000 seconds)

31 00 09 6C F0 10 7C 08 00 BA 8E 56 38 1..lð.|..ºŽV8

Request: 4/14/2003 9:42:12 AM.109375064 (+0.0000000000 seconds)

30 00 05 6C 10 F0 27 01 37 0..l.ð'.7

Answer: 4/14/2003 9:42:12 AM.125000064 (+0.0156250000 seconds)

31 00 07 6C F0 10 67 01 70 3C 48 1..lð.g.p<H

Request: 4/14/2003 9:42:12 AM.140625064 (+0.0000000000 seconds)

30 00 05 6C C0 F0 3C 08 6B 30 00 04 8C FE F0 3F 0..lÀð<.k0..Œþð?
13 30 00 05 6C C0 F0 27 01 87 30 00 04 8C FE F0 .0..lÀð'.‡0..Œþð
3F 13 8B 00 01 01 73 ?.‹...s

Port closed

Yes?

[Keith@HPTuners]

Magnus, I think I found your Seed and KEY for a GTP

Request CAL ID
30 00 05 6C 10 F0 3C 08 1B 0..l.ð<..

CAL ID:
31 00 09 6C F0 10 7C 08 00 BA 8E 56 38 1..lð.|..ºŽV8


Request SEED
30 00 05 6C 10 F0 27 01 37 0..l.ð'.7

Seed:
31 00 07 6C F0 10 67 01 70 3C 48 1..lð.g.p<H

Your seed is $703C, the last # on your packet is a csum of the data to send on the bus.

[Chris@HPTuners]

I made some progress on the upload process. Apart from the seed/key that is. I haven't tried any of it yet on a PCM using Magnus' prog. But here it is anyway FYI (some of this overlaps with Magnus' earlier post).

There are three main parts:
1. seed/key
2. download the upload routine to RAM (must be between $FF8000 and $FFC000)
3. request an upload utilising the routine you just downloaded to RAM.

Disable Normal Message Transmission
Test Device Present
send: 6c fe f1 3f

Data Link Security Access - Read Seed
send: 6c 10 f1 27 01
recv: 6c f1 10 67 01 <s1> <s2>

Data Link Security Access - Send Key
send: 6c 10 f1 27 02 <k1> <k2>

Return to Normal Mode
send: 6c 10 f1 a0
recv: 6c f1 10 e0 aa

Test Device Present
send: 6c fe f1 3f

Begin High Speed Mode
send: 6c 10 f1 a1

Request Download to PCM (mode $34)
- specify number of bytes to send and start address
send: 6c 10 f1 34 00 00 00 00 00 00
recv: 6c f1 10 74 00 44

Block Transfer Message (mode $36)
- call this a number of times depending on how big your routine is
eg.
send: 6D 10 F1 36 00 00 80 FF 80 00 (eg. 128 bytes, start loc FF8000)
..data..
recv: 6d f1 10 76 00 73


Request Upload from PCM (mode $35)
- your routine should respond to the upload request
- your routine should then request a block transfer to your node # using mode $36)
- then send the data
eg.
send: 6C 10 F1 35 01 00 80 00 00 00 (eg. 128 bytes, start $0x0000)
recv: 6c f1 10 75 01 54 <= your routine does these
6d f1 10 36 01 00 80 00 00 00 <= your routine does these
..data..

Block Transfer Message Response (OK)
send: 6C 10 F1 76 00 54

repeat...
eg. next might be:
send: 6C 10 F1 35 01 00 80 00 00 80
recv: 6c f1 10 75 01 54
6d f1 10 36 01 00 80 00 00 80

etc...

I haven't worked out how control actually passes to the routine you downloaded yet. It may be just triggered by the download mode $34 code. Which resides on the PCM (but not for the entire image just the RAM area i think).

Some questions i still have:
1. the key generator routine - help! I can probably provide many seed/key pairs, but crypto just aint my thing

[Tyrithe]

And my problem is getting the seed/key pairs to try and work out the algorithm. No guarantees on success, but I'm kinda itching to try and find it...

tyr

[Chris@HPTuners]

here's some:

seed 2590, key 0328
seed 4470, key 2309
seed 136A, key 293A

also, *i think* that if your VIN is written to $6000-$8000 then your PCM is ready to autolearn security and it will be copied to $4000-$6000 segment? If it is already in the $4000-$6000 segment then your PCM has already autolearned and locked to the BCM. Maybe we should have a thread on this seperately.

Again, i need to try this myself

[Chris@HPTuners]

one more thing, i just found out how the code is exec'd. It works like this.

The mode $34 (request download) handler routine, calls a routine that handles subsequent calls to primarily mode $36 (block transfer) but also modes $A0, $A1, $28, $27 and also $34 again. This routine is located in my PCM at $0x0A7E. Interestingly the mode $27 call only returns $00 $00, so it is obviously assuming that to get here you must have unlocked the PCM etc. etc. Also, the call to mode $34 has bounds checking to make sure you can only write to RAM from $FF8000 to $FFC000. The important thing is not so much the mode $34 request addresses you supply. infact the number of bytes and start addr numbers are only used for the bounds checking. The subsequent mode $36 call is what really determines where your code is loaded to and your entry point.

Also, the GM mode $35 (request) routines also have bounds checking to the locs $5000-$8000 (in my PCM anyway) so Mangus you might wanna try just those locs for a simple upload without downloading your own routine. Notice it doesn't include the VIN etc. which is stroed at $4000+ in my PCM.

Anyway, the subseqent mode $36 code is where the action is. This routine recieves your loader routine which then takes control of things and does basically whatever you want. But to read the entire PCM you need to bypass the GM bounds checking so your loader should have at least a new mode $35 (request upload) hander routine. Your routine should respond to a mode $35 request and then initiate a mode $36 (block transfer) to your PC Dev $F1. Your PC code should respond correctly and also your PCM routine should check for correct responses etc. You then use this to read out the entire PCM. Also, since you are in control, who cares about what buffering capability the cable has? You can send the data as fast or as slow as you want to the PC. Finally your routine should reset the PCM to resume normal operation.

Importantly, when you are downloading your routine you are sending block transfers like this with submode $00 for all blocks. Except for the start of you code, which you must send as the last block with submode $80. The address you send with a submode $80 will then be exec'd on completion of the download:

2nd part code - 1st block
send: xx 6D 10 F1 36 00 00 80 FF 90 80 (128 bytes, loc FF9080)
<$80 bytes data><2 bytes cksum>

3rd part code - 2nd block
send: xx 6D 10 F1 36 00 00 80 FF 91 00 (128 bytes, loc FF9100)
<$80 bytes data><2 bytes cksum>

...etc...

then for the last (start of code):

send: 8C 6D 10 F1 36 80 00 80 FF 80 00 (128 bytes, start loc FF8000)

Control will then pass to your routine at $0xFF8000.

i'm 100% sure this will work, although of course you must already know your seed/key or know the routine to calc the key from the seed. Means hopefully only have to desolder/resolder once ;D

Flashing the PCM is a similar deal, i will post that in a similar thread once I confirm the reading part is working. Hopefully with an ATV2 cable ;D

[Casey]

"This routine is located in my PCM at $0x0A7E."

That is the routine used if the PCM is not programmed.

Sub 0xE16 does a check to see if 0X7FFFE and 0x1FFFE
have #$4AFC in both locations. If it does, the PCM operates normaly.

The normal routines used to check the mode requests
are down around 0x40CXX (on mine)

There you will find 2 indexed tables (on mine)
0x3A7E J179_Functional

0x3A88 J2190_Physical



Below those tables are the indexed sub routines for those modes.

0x3AA0 J1979_Functional_Subs

0x3AD6 J2190_Physical_Subs


Look around 0xFFF600 for the VPW hardware....

Supersportx2

[Chris@HPTuners]

i dont agree. the normal mode $34 recieve handler calls this code. sure it checks the bytes you mentioned (twice) but it drops out a mode $A2 request (programming prompt) if seg1 fails but if seg2 fails or everything is ok then it runs the code is my take.

i can't see it being bypassed unless the seg1 check fails.

[Casey]

Well then I must be missing something.

The Mode $34 routine already handles the response
and byte 6 info.

Byte 6:

$41 Improper download type
$42 Illegal address specified
$43 Byte count illegal
$44 Ready for download


Why would they check it twice?
What am I missing gameover?

Supersportx2

[Chris@HPTuners]

what is missing is that the mode $36 code refernced by the jmp vector table doesn't do anything much (see below) except return some kind of error.

ROM:0003D020 mode36_start: ; Move Multiple Registers
ROM:0003D020 movem.l d0/a0,-(sp)
ROM:0003D024 jsr sub_3D766 ; Jump to Subroutine
ROM:0003D02A move.l a0,($FFFF9C26).w ; Move Data from Source to Destination
ROM:0003D02E moveq #$22,d0 ; '"' ; Move Quick
ROM:0003D030 jsr sub_3B466 ROM:0003D030 ROM:0003D036 movem.l (sp)+,d0/a0 ; Move Multiple Registers
ROM:0003D03A rts ; Return from Subroutine

which means that the $0x0A7E ref'd by the mode $34 code must do all the work. Also, the dissassembly seems to lead me that way.

in the code the errors you mention mean:

$41 - tried to use a submode other than $00
$42 - the address you entered was outside the bounds for mode $34 ($FF8000-$FFC000) or $35 ($5000-$8000)
$43 - you tried to send more than $1000 bytes
$44 - everything is ok go for it

Here's the code at the end of mode $34 handler:

ROM:0003CEBC move.b ($FFFF9857).w,-7(a6) ; success return code $44
ROM:0003CEBC ; final msg is 6c f1 10 74 00 44
ROM:0003CEC2 moveq #6,d0 ; d0 = 6 bytes to send
ROM:0003CEC4 lea -$C(a6),a0 ; a0 = headr byte
ROM:0003CEC8 jsr (sub_D4E).l ; send response
ROM:0003CECE jsr (sub_7E2).l ; **here**
ROM:0003CED4
ROM:0003CED4 loc_3CED4: ; CODE XREF: ROM:0003CD82j
ROM:0003CED4 ; ROM:0003CE0Aj
ROM:0003CED4 movem.l (sp)+,d0-d2/a0 ; Move Multiple Registers
ROM:0003CED8 unlk a6 ; Unlink
ROM:0003CEDA rts ; Return from Subroutine

The call to $0x07E2 eventually gets you to the real mode $36 block transfer routine.

ROM:000007E2 sub_7E2: ; CODE XREF: checks_A_E36+4Ep
ROM:000007E2 ; ROM:0003CECEp
ROM:000007E2 move sr,-(sp) ; Move Data from Source to Destination
ROM:000007E4 ori #$700,sr ; Inclusive-OR
ROM:000007E8 movem.l d0/a0,-(sp) ; Move Multiple Registers
ROM:000007EC jsr (check_CAL_ID_E16).l ; returns d0=0 if ok
ROM:000007F2 tst.b d0 ; Test an Operand
ROM:000007F4 bne.s loc_802 ; br if not ok
ROM:000007F4 ; else...
ROM:000007F6 jsr sub_6EA56 ; Jump to Subroutine
ROM:000007FC jsr (sub_DF0).l ; Jump to Subroutine
ROM:00000802
ROM:00000802 loc_802: ; CODE XREF: sub_7E2+12j
ROM:00000802 movea.l (dword_1BFA).l,a0 ; Move Address
ROM:00000808 subq.l #1,a0 ; Subtract Quick
ROM:0000080A jsr (sub_F50).l ; Jump to Subroutine
ROM:00000810 jsr (sub_6EC).l ; Jump to Subroutine
ROM:00000816 jsr (sub_824).l ; *** here ***
ROM:0000081C movem.l (sp)+,d0/a0 ; Move Multiple Registers
ROM:00000820 move (sp)+,sr ; Move Data from Source to Destination
ROM:00000822 rts ; Return from Subroutine

then the call to $0x0824...

which eventually leads you to this:

ROM:00000992 move.b ($FFFFBE80).w,d3 ; recieved mode #
ROM:00000996 cmpi.b #$27,d3 ; ''' ; Compare Immediate
ROM:0000099A beq.s loc_9BA ; Branch if Equal
ROM:0000099C cmpi.b #$28,d3 ; '(' ; Compare Immediate
ROM:000009A0 beq.s loc_9BA ; Branch if Equal
ROM:000009A2 cmpi.b #$34,d3 ; '4' ; Compare Immediate
ROM:000009A6 beq.s loc_9BA ; Branch if Equal
ROM:000009A8 cmpi.b #$36,d3 ; '6' ; Compare Immediate
ROM:000009AC beq.s loc_9BA ; br if mode $36
ROM:000009AE cmpi.b #$A0,d3 ; Compare Immediate
ROM:000009B2 beq.s loc_9BA ; Branch if Equal
ROM:000009B4 cmpi.b #$A1,d3 ; Compare Immediate
ROM:000009B8
ROM:000009B8 loc_9B8: ; CODE XREF: sub_824+1CEj
ROM:000009B8 bne.s loc_9FC ; Branch if Not Equal

and then this....

ROM:00000A12 move.b var_E(a6),d3 ; = 1
ROM:00000A16 beq.w loc_84E ; br if zero
ROM:00000A16 ; else...
ROM:00000A1A jsr (sub_12C0).l ; Jump to Subroutine
ROM:00000A20 move.l d0,d6 ; Move Data from Source to Destination
ROM:00000A22 jsr (block_transfer_A7E).l ; Jump to Subroutine
ROM:00000A28 bra.w loc_834 ; Branch Always
R

then the $0x0A7E code does the work...

It seems that it will stay in this download routine until a timer expires then it resets the PCM. Would be intersting to send a download command and then not do anything else and see what happens.

ROM:000009FC jsr (sub_12C0).l ; Jump to Subroutine
ROM:00000A02 sub.l d6,d0 ; Subtract
ROM:00000A04 cmpi.l #$50529,d0 ; timer expired?
ROM:00000A0A ble.s loc_A12 ; br if not
ROM:00000A0A ; else...
ROM:00000A0C jsr (loc_69A).l ; reset PCM
ROM:00000A12
ROM:00000A12 loc_A12: ; CODE XREF: sub_824+1E6j

[The_Highlander]

You are using PC Edit for all this?

The converter is ready.. It does 256 bytes block transfers...

[Casey]

I guess I am going to have to go through that code and read it for real. I have not spent much time on that routine as I have been working on the ETC algo..

I was under the impression that most of that shared routine was skipped. For some reason download and jump to a comm routine for read/write comes to mind.

I thought I saw a Jump A2 (ram) call before that...

Wouldn't be the first time I was wrong


Super Sport x2

[lndshrk]

Guys,

As I've said before.. that is NOT the code to be looking
at because it isn't the code that is running on a PCM
that is "programmed".

I've already shown the jump table for the messages
in a different thread.

Jim

[Casey]

Guys,

As I've said before.. that is NOT the code to be looking
at because it isn't the code that is running on a PCM
that is "programmed".

I've already shown the jump table for the messages
in a different thread.

Jim

That's what I thought as well.

I'm going to email you lndsrhk. I am talking about the indexed mode routines, and yes it does make a pass though some of that code. I just doesn't do anything in the shared routines from what I can see......


Supersport x2

[Chris@HPTuners]

okay guys i'm making progress here. I can unlock the PCM and request high speed mode and get the correct reply from the PCM. But when do i actually switch to high speed mode before or after the $A1 request? Below is the send/recv output from my code. I think i've tried every combo of when to switch the cable to high speed mode. I never get anything back after i send the mode $A1 request.

send: 01 03 07 00 04 00 0f
recv: 01 03 87 00 04 00 8f
** Connected at 57.6k **
send: 01 01 43 05 6c fe f1 28 00 cd
recv: 01 01 c3 05 6c f1 10 68 00 9f
send: 01 01 41 04 6c fe f1 3f e1
send: 01 01 41 05 6c 10 f1 27 01 dd
recv: 01 01 c1 07 6c f1 10 67 01 25 90 54
send: 01 01 41 07 6c 10 f1 27 02 03 28 0b
recv: 01 01 c1 06 6c f1 10 67 02 34 d3
send: 01 01 41 04 6c fe f1 3f e1
send: 01 01 43 04 6c 10 f1 a0 56
recv: 01 01 c3 05 6c f1 10 e0 aa c1
send: 01 01 43 04 6c fe f1 a0 44
recv: 01 01 c3 05 6c f1 10 e0 aa c1
send: 01 01 41 04 6c fe f1 3f e1
send: 01 01 26 00 28
recv: 01 01 a6 00 a8
send: 01 01 43 04 6c 10 f1 a1 57
recv:

[Keith@HPTuners]

Hmm.. it could be the B&B V2 cable junking it.

[Chris@HPTuners]

so i just confirmed i can read the PCM between $5000-$8000 in low speed mode using mode $35. As expected if i try a range outside of this it errors. Below is an example of reading 6 bytes.


send: 01 03 07 00 04 00 0f
recv: 01 03 87 00 04 00 8f
** Connected at 57.6k **
send: 01 01 43 05 6c fe f1 28 00 cd
recv: 01 01 c3 05 6c f1 10 68 00 9f
send: 01 01 41 04 6c fe f1 3f e1
send: 01 01 41 05 6c 10 f1 27 01 dd
recv: 01 01 c1 07 6c f1 10 67 01 25 90 54
send: 01 01 41 07 6c 10 f1 27 02 03 28 0b
recv: 01 01 c1 06 6c f1 10 67 02 34 d3
send: 01 01 41 04 6c fe f1 3f e1
send: 01 01 41 0a 6c 10 f1 35 01 00 06 00 50 00 46
recv: 01 01 c1 06 6c f1 10 75 01 54
recv: 00 01 01 c1 12 8c f1 10 36 00 00 06 00 50 00 ff ff ff ff ff ff 06 50 3e
send: 01 01 41 06 6c 10 f1 76 00 54 80

[Chris@HPTuners]

Hmm.. it could be the B&B V2 cable junking it.

Agree it's a possibility but do you think i should switch to high speed mode after the mode $A0 and send the mode $A1 in high speed mode? Or send the mode $A1 and then switch to high speed mode?

It would seem kind stupid that the cable would junk the response since it supports high speed mode itself so why would it junk the commands required to send/recv using it? Strange...