Page 1 of 3 123 LastLast
Results 1 to 20 of 52

Thread: Protocol for reading the PCM Flash Memory

  1. #1
    HP Tuners Owner Keith@HPTuners's Avatar
    Join Date
    Sep 2002
    Location
    Chicago, IL
    Posts
    6,926

    Protocol for reading the PCM Flash Memory

    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
    We got this guy Not Sure, ...

  2. #2
    HP Tuners Owner Keith@HPTuners's Avatar
    Join Date
    Sep 2002
    Location
    Chicago, IL
    Posts
    6,926

    Re: Protocol for reading the PCM Flash Memory

    Quote Originally Posted by lndshrk

    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.
    We got this guy Not Sure, ...

  3. #3
    Tuner in Training
    Join Date
    Sep 2002
    Location
    Posts
    19

    Re: Protocol for reading the PCM Flash Memory

    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?

  4. #4
    HP Tuners Owner Keith@HPTuners's Avatar
    Join Date
    Sep 2002
    Location
    Chicago, IL
    Posts
    6,926

    Re: Protocol for reading the PCM Flash Memory

    Quote Originally Posted by Hera
    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.
    We got this guy Not Sure, ...

  5. #5

    Re: Protocol for reading the PCM Flash Memory

    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


    I count sheep in hex...

  6. #6
    Tuner in Training
    Join Date
    Oct 2002
    Location
    Atlanta, GA
    Posts
    11

    Re: Protocol for reading the PCM Flash Memory

    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

  7. #7

    Re: Protocol for reading the PCM Flash Memory

    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

    I count sheep in hex...

  8. #8

    Re: Protocol for reading the PCM Flash Memory

    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










    I count sheep in hex...

  9. #9
    Senior Tuner
    Join Date
    May 2003
    Location
    Santa Clarita, Ca
    Posts
    1,412

    Re: Protocol for reading the PCM Flash Memory

    "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

  10. #10

    Re: Protocol for reading the PCM Flash Memory

    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.

    I count sheep in hex...

  11. #11
    Senior Tuner
    Join Date
    May 2003
    Location
    Santa Clarita, Ca
    Posts
    1,412

    Re: Protocol for reading the PCM Flash Memory

    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

  12. #12

    Re: Protocol for reading the PCM Flash Memory

    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


    I count sheep in hex...

  13. #13

    Re: Protocol for reading the PCM Flash Memory

    You are using PC Edit for all this?

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


  14. #14
    Senior Tuner
    Join Date
    May 2003
    Location
    Santa Clarita, Ca
    Posts
    1,412

    Re: Protocol for reading the PCM Flash Memory

    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

  15. #15
    Tuner in Training
    Join Date
    May 2003
    Location
    SLC, Utah
    Posts
    33

    Re: Protocol for reading the PCM Flash Memory

    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

  16. #16
    Senior Tuner
    Join Date
    May 2003
    Location
    Santa Clarita, Ca
    Posts
    1,412

    Re: Protocol for reading the PCM Flash Memory

    Quote Originally Posted by 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
    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



  17. #17

    Re: Protocol for reading the PCM Flash Memory

    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:
    I count sheep in hex...

  18. #18
    HP Tuners Owner Keith@HPTuners's Avatar
    Join Date
    Sep 2002
    Location
    Chicago, IL
    Posts
    6,926

    Re: Protocol for reading the PCM Flash Memory

    Hmm.. it could be the B&B V2 cable junking it.
    We got this guy Not Sure, ...

  19. #19

    Re: Protocol for reading the PCM Flash Memory

    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
    I count sheep in hex...

  20. #20

    Re: Protocol for reading the PCM Flash Memory

    Quote Originally Posted by Magnus
    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...
    I count sheep in hex...