Page 5 of 34 FirstFirst 1234567891015 ... LastLast
Results 61 to 75 of 509

Thread: 1997 F-Body ECM

  1. #61
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by steveo View Post
    i tried a few permutations of address lines but never got anywhere. i'd love to make a tool for that if anyone ever figures it out.
    One project I worked on, we did with scrambled address and data lines. This was not done to obscure the binary but rather to ease the layout of the PCB. Specifically, there was a problem where a bunch of data lines needed to cross and it would have required an increase in layer count of the PCB to accomplish. (that or blind and buried VIAs) Back in the day, this was not good tech to use where vibration and heat cycles were a factor. It also CO$T bigtime due to scrap costs where it went wrong.

    Writing a translator for data lines and address lines is trivial. Knowing which are swapped is the difficult part. The easy way to do this is with an ohm meter (with "beep") to determine how the traces are swapped. Armed with this a conversion can be written in a few hours. One will need only a mapping of which data&address on the processor connects to which on the FLASH. If bank switching is involved, that also needs to be mapped. On my PCM, a simple NAND gate is used. Which address line is connected to that gate is also needed.

    If anyone wants this done, pm me with details of the swaps and I will write a console app to convert.
    -Tom

  2. #62
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    This is the cheapest interface that can work for you. It was used to flash ls1 pcms, so it is proved to work with larger messages.

    https://www.scantool.net/obdlink-sx/

    The only drawback, it doesn`t support x4 mode.
    There is a free tool to load an updated firmware. The firmware file is available to look at also. I am not sure how it is compiled but upon a request you might be able to get a source code and make it x4 compatible.

    Pcm can be flashed in x1 mode, so that shouldn`t bother you. It is just 4 times slower. With that chip size the write times will be acceptable and close to obd1 pcm write time.

    The main difference between x1 and x4 is that in x4 mode the rounding of the signal is removed and it is true square type of transition and the timings are cut by 4.

    The 12 bytes frame size limit is software limitations. When the PCM enters datablock mode the limitation is removed and you can send as long as you want.
    This device looks OK... the message limit is 47 bytes I think (from manual). Given this, the overhead is 3 for header, 7 for message, 2 for sixteen bit checksum. I think the checksum is provided by the stn1100 so 35 bytes could be transferred in a frame.
    This would mean that you would send multiple frames for the download with the last of them having download and execute bit set.

    Is this the way it works (?)
    -Tom

  3. #63
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I found this on another forum. It is confirmed on a saturn pcm and a diesel pcm with the same intel memory chip.

    by the way specifically it was the A1-A13, A2-A12, A3-A11, and A10-A14 pairs that were swapped
    Still might not be the case with lt1 but it`s worth to try.


    This device looks OK... the message limit is 47 bytes I think (from manual). Given this, the overhead is 3 for header, 7 for message, 2 for sixteen bit checksum. I think the checksum is provided by the stn1100 so 35 bytes could be transferred in a frame.
    This would mean that you would send multiple frames for the download with the last of them having download and execute bit set.

    Is this the way it works (?)
    Actually the buffer with elm commands is upto $C0 long message without headers and checksums. With the ST command set you can send and recieve upto 2k long messages. I think the pcm supports Mode 36 80 and Mode 36 00. Just split the frame in multiple messages and load them backwards. The last message should be download and execute.

  4. #64
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    {6D 10 F0 36 [[80 (00 70) (00 18 10) //86 86 36 CE 76 80 3C 30 9D 86 38 31 39 18 38 18 EC 02 FD 18 7C CD EE 00 18 08 18 08 18 08 18 08 4F 9D 8F C6 40 E7 00 18 E6 00 E7 00 FB 18 7F F7 18 7F 24 03 7C 18 7E 9D 89 C6 C0 E7 00 9D 8C 18 E6 00 E1 00 27 07 4C 81 19 23 D6 20 12 08 18 08 3C FE 18 7C 09 FF 18 7C 38 26 C5 86 86 20 02 86 85 36 CE 76 80 3C 30 9D 86 38 31 39 00 00 00 00//]] [29 0A]} [56]

    ...

    [29 0A] this is the block checksum. It is used by the pcm to check data integrity. It is word+word+word 16 bit type checksum caculated from data contained in[[.....]]
    .
    I am having a bit of trouble with this checksum. I think it to be byte+byte+byte with the count extended to 16bit. Here is the code I think it uses from the PCM... please correct if I missed the point here. Adding 16 bit words also results in a problem when/if frames have odd number bytes.

    Code:
    ************************************************
    * CHECKSUM INCOMMING FRAME
    ************************************************
    DDC3  BB 1C 06    	ADDA   $1C06           ; CHECKSUM OF MESSAGE
    DDC6  B7 1C 06    	STAA   $1C06           ; UPDATE
    
    DDC9  B6 1C 05    	LDAA   $1C05           ; EXTEND CHECKSUM TO 
    DDCC  89 00       	ADCA   #$00            ; 16 BITS
    DDCE  B7 1C 05    	STAA   $1C05           ; 
    
    DDD1  39          	RTS                    ; DONE
    It seems also, I have made a number of errors in the "hello world" execution frame I posted. Not the least of which is that I forgot to reset the cop and watchdog timers... this will result in a reset (no harm done). I plan to update with a fix soon

    The makeshift tool I am using to send download frames works but is not great for debugging. Takes way too much time to set things up.

    Current problem I am working through is that the PCM accepts the frame, but does not respond in any way. Then after it times out the d/l it just keeps on as if I had sent nothing. Here is the test frame I am sending after removing security and sending a mode 34 to get ready. Mode 34 responds with a $44-- ready to download.

    Code:
    Frame content:
    6d 10 f0 36 80 00 16 00 00 00 86 55 b7 10 3a 86
    aa b7 10 3a cc 50 a0 b7 18 06 f7 18 06 01 20 08
    6a e2
    Just plays possum after. Wondering now about how the content of address and length in the mode $34 command might affect the following mode $36 command.

    -Tom

  5. #65
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Code:
    6d 10 f0 36 [80 00 16 00 00 00 86 55 b7 10 3a 86
    aa b7 10 3a cc 50 a0 b7 18 06 f7 18 06 01 20 08]
    08 72
    The checksum is byte+byte+byte checksum-16 type of. I noticed the error but forgot to make a note.
    In this frame the checksum will be 08 72, $16 byte long with 000000 load address.

    On newer pcm when you download a frame with wrong checksum you will get 77 response. I suppose that is not added in the code so that`s why the pcm stay silent. Or it might just crash. Try loading with 36 00 with wrong checksum just to see how it will respond.

    Mode 34 just check if the memory region is available for download and is not in outside range. Than the pcm enters upload loop.
    The following mode 36 request can be changed and it should work.

  6. #66
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    Download progress

    Quote Originally Posted by kur4o View Post
    [CODE]


    On newer pcm when you download a frame with wrong checksum you will get 77 response. I suppose that is not added in the code so that`s why the pcm stay silent. Or it might just crash. Try loading with 36 00 with wrong checksum just to see how it will respond.

    Mode 34 just check if the memory region is available for download and is not in outside range. Than the pcm enters upload loop.
    The following mode 36 request can be changed and it should work.
    -------------------------------------------------------------------------

    Very happy to report some progress on this end. Thanks Kur4o for all your help... the program I wrote to parse Srecord file and generate a frame had a flaw. Now corrected, I was able to download a simple program this morning. Checksum and CRC were OK, but it ate some of the data. Now PCM responded with
    Code:
    6C F0 18 76 80 78 9E
    The '78' reply has the meaning :"BLOCK TRANSFER MESSAGE CORRECTLY RECEIVED\n",

    Still lingering problems though... why do I need to send the Mode $36 message twice. The first time I send it, no response. Hmmmm

    There are still some things I don't understand in the download section. Needing to get right to the bottom of all this.

    -Tom

  7. #67
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Code:
    download and execute Main LOOP $10
    <6D 10 F0 36 80 03 56 00 00 80 20 3D 20 00 FF FF 7E 02 ..
    >6C F0 10 76 00 73 00
    I think that before the pcm handles control to the download routine it must send 73 as a response that means all is ok.

    78 is usually send in multi message answers that require more time. The meaning should be wait I am busy, not ready yet.

    To clear the meaning of most of the responses you will have to go through the code again.

    Another thing I noticed that the response came from $18, If you send a frame to $10 and get a response from $18 there is something wrong.

  8. #68
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    Code:
    download and execute Main LOOP $10
    <6D 10 F0 36 80 03 56 00 00 80 20 3D 20 00 FF FF 7E 02 ..
    >6C F0 10 76 00 73 00
    I think that before the pcm handles control to the download routine it must send 73 as a response that means all is ok.

    78 is usually send in multi message answers that require more time. The meaning should be wait I am busy, not ready yet.

    To clear the meaning of most of the responses you will have to go through the code again.

    Another thing I noticed that the response came from $18, If you send a frame to $10 and get a response from $18 there is something wrong.
    To the best of my knowledge, the following responses apply...
    Code:
    	"TRANSFER SUSPENDED\n",									// 0x071
    	"TRANSFER ABORTED\n",									// 0x072
    	"BLOCK TRANSFER COMPLETE / NEXT BLOCK\n",				// 0x073
    	"ILLEGAL ADDRESS IN BLOCK TRANSFER\n",					// 0x074
    	"ILLEGAL BYTE COUNT IN BLOCK TRANSFER\n",				// 0x075
    	"ILLEGAL BLOCK TRANSFER TYPE\n",						// 0x076
    	"BLOCK TRANSFER DATA CHECKSUM ERROR\n",					// 0x077
    	"BLOCK TRANSFER MESSAGE CORRECTLY RECEIVED\n",			// 0x078
    	"INCORRECT BYTE COUNT DURING BLOCK TRANSFER\n"			// 0x079
    The Mode $34 command I am sending is:
    4C 18 F1 34 00 00 00 00 00 00 <crc>

    The Mode $36 command I am sending is:
    6d 18 f0 36 80 00 51 00
    00 00 ce 10 00 86 55 b7
    10 3a 86 aa b7 10 3a cc
    50 a0 b7 18 06 f7 18 06
    86 80 a5 25 27 e7 a7 25
    7a 00 50 26 e0 86 f0 97
    50 18 ce 00 40 86 80 a5
    2e 27 fa 18 a6 00 a7 2f
    18 08 18 8c 00 4f 2e c5
    20 eb 48 65 6c 6c 6f 20
    77 6f 72 6c 64 21 21 21
    0a 0d 00 1e b4 4c

    This now includes watchdog/COP reset. Some timer and interrupt settings still affect this, I need to add a re-init section...

    It may be that my tool for sending extended frames has a flaw. I will drag out the scope and have a look. I should also try to download using $10/Tside as target.

    Thanks again,
    Tom

  9. #69
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    Download

    Hi, wanted to update the status of my project. I am still having troubles getting the download right. Much of my equipment is home built so there may be finger problems in all that but I am working through them.

    I am now able to send long frames to download the PCM. This works at times and not at others. I am trying to find out why. Stepping back here are som things I have found:

    I tried some of the suggested commands. Here is an edited list of which commands worked
    and details that came up as I debugged...
    Note that the commands and responses below need CRC appended to them.
    ------------------------------------------------------------------------------
    STOP NORMAL COMMUNICATION
    <6C FE F0 28 00
    >6C F0 FE 68 01 00 00
    SEND $6C,$FE,$F0,$28,$00
    REPLY $6C $F0 $10,$7F,$28,$00,$11: Mode Not Supported

    Note: I have found that only the following modes are
    supported when a physical frame is addressed with
    destination of $FE: all nodes. I believe this command is
    needed where the system has a number of nodes on the
    class 2 line.

    $14 CLEAR DIAGNOSTIC INFORMATION
    $20 RETURN TO NORMAL
    $22 REQUEST DIAGNOSTIC INFO BY PID
    $25 STOP TRANSMITTING REQUESTED DATA
    $3C READ DATA BLOCK
    $3F TEST DEVICE PRESENT
    $A1 BEGIN HIGH SPEED MODE

    I have replace this in my code with a physical frame
    addressed from tester to the pcm as follows:

    SEND $6C $10 $F0 $28 $00
    REPLY $6C $F0 $10 $68 $00: Seems to be a working MODE $28 command


    PCM UNLOCK
    <6C 10 F0 27 01
    >6C F0 10 67 01 00 00

    SEND $6C $10 $F0 $27 $01
    REPLY $6C $F0 $10 $67 $01 $58 $3D

    SEND $6C $10 $F0 $02 $91 $94
    REPLY $6C $F0 $10 $67 $02 $34: Reply is Security Access Allowed


    Note: I had success unlocking my PCM. I was previously able to find (in two different
    ways) the key value. In my case however I got into troubles because the effect of
    unlock and stop normal communications last only 5 seconds. There is a time out that
    issues a MODE $20 return to normal communications when it expires.


    ------------------------

    When I get things working, here is the result of a few different attempts with appropriate parameters and others with errors to generate the fail codes...
    6C F0 18 76 80 78 9E DOWNLOAD OK: SENT 6D 18 F0 36 80 00 55 00 00 00 ... <CSH> <CSL> <CRC>
    6C F0 18 76 81 41 6D IMPROPER DOWNLOAD TYPE: TYPE $81
    6C F0 18 76 80 42 06 CAN'T DOWNLOAD TO SPECIFIED ADDRESS: ADDRESS $010000 is too high
    6C F0 18 76 80 42 06 CAN'T DOWNLOAD TO SPECIFIED ADDRESS: ADDRESS $000400 is above internal ram
    6C F0 18 76 80 42 06 CAN'T DOWNLOAD TO SPECIFIED ADDRESS:
    6C F0 18 76 80 43 1B CAN'T DOWNLOAD NUMBER OF BYTES REQUESTED: LENGTH $0455

    Please note that all this is addressed for the Eside but is in fact placed in Tside memory and executed there.

    I hope at some point, that I can explain how/why all the problems I have had are happening. One thing I noted is that it *seems* like the interrupt system is still causing code to run during download. This would be no problem except it seems to be updating in locations I am downloading to. Thus the code gets wiped. I had thought that MODE $28 would take care of all that but not so.

    There are two modes that I have never seen details of... $A8 and $AE. I wonder if anyone knows of these and if they are used in download?

  10. #70
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    If you want to keep pcm and any other module on the bus quite after mode 28 is send, try sending 6c fe f0 3f message every 2.5 seconds. All modules have timer for mode 28 duration and it is exactly 5 seconds.

    When you enter mode 34 the pcm have limited time available to upload the code and run it, before it resets. I doubt the pcm will have interupts enabled during upload, it is more a reset after you execute the code the pcm resets.

    The code needs to be indefinite loop and the pcm should be able to run and communicate only from the code you send in ram. First thing needed is to disable interrupts, and reset watchdog timer every xx cycles.

    A good strating point to look at is the gm main ram loop uploaded at the start of flash. Keeping both processors quite might help with the interupts.

    Mode AE is device control mode, similar to mode4 on earlier pcms. It works like sending a special command to add 2 degress of timing or enable solenoids or relays. It is pcm specific what is available for control.

    A8 is some gm test mode. There is not much info about it.

  11. #71
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi,
    I feel bad to be imposing with stuff that I should have been able to figure out by now but...

    Here a screen shot of my d/l app
    DLCAP2.jpg

    read it bottom to top why... just have not fixed it yet. Starts with a bunch of setup for elm. Turns off the background. Sends the $3f tester present that restarts the 5S timer. opens the security. Turns off background and resets timer. found it helps to make it stable if I send a null request for download. That is a mode $34 with 0 length at address 0. I think it is NOP. Then comes the real mode $34. Looking in the code I see it isn't responded to: and I get no response as expected. Then sending the mode $36 transfer with the execute type set. This looks to go OK because the response is code 78: Block Transfer Message Correctly Received.

    In any case, this is where I am. One more thing... When you try to download the Tside. it may force you to use 4X. Is that true?


    Thanks again for your help.
    -Tom

  12. #72
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I still insist the response on successful upload must be 73, not 78.
    The loading address at 1900 might not be suitable for initial upload, try 0000 and see what happens.
    Try running both sides as per the quote and upload GM code to see does it work as expected. Single side upload can lead to undesired effects.
    request mode 36 $10 accsess
    <6C 10 F0 34 80 03 56 00 00 80
    >6C F0 10 74 00 44 00

    request mode 36 $18 accsess
    <6C 18 F0 34 80 03 F3 00 00 00
    >6C F0 18 74 00 44 00

    download and execute Main LOOP $18
    <8C FE F0 3F
    <6D 18 F0 36 80 03 F3 00 00 00 20 31 20 2F 00 00 00 00 ..
    >6C F0 18 76 00 73 00

    download and execute Main LOOP $10
    <8C FE F0 3F
    <6D 10 F0 36 80 03 56 00 00 80 20 3D 20 00 FF FF 7E 02 ..
    >6C F0 10 76 00 73 00
    Pcm can`t execute highspeed on it`s own. It must be requested by the tool. When the pcm recieves A1 request it sets a register to command the dlc to enter highspeed. Actually the pcm doesn`t care since the highspeed is handled by DLC. Dlc is also set to revert to x1 mode on the first x1 message it receives when is in x4 mode.

    Figuring this stuff by looking at the code is next to impossible or it will take alot more time than you can think of. Some experiments reveal stuff much faster.

  13. #73
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    Download code snips

    Hi,
    I want to reply to all your thoughts, this post is just on the first bit

    Quote Originally Posted by kur4o View Post
    I still insist the response on successful upload must be 73, not 78.
    I think response 73 is reserved for download without execute. In my dictionary of code responses: Code $73 - Block Transfer Complete/Next Block. This seems to match with what I see. Here is a screen shot of my app when I download without execute...

    DLCAP3.jpg

    I have tried loading to $0000, $1810 and $1900. Code seems to get hit no matter where I place it.

    Also... regarding response code sent, here are some commented code snips. First is where I believe the testing is done to verify the parameters place downloaded code in ram and not elsewhere

    Code:
    DD0B  B6 1B FF    	LDAA   $1BFF           ; GET LENGTH BITS 16:23
    DD0E  85 7F       	BITA   #$7F            ; TEST FOR EXECUTE DOWNLOAD FLAG
    DD10  27 05       	BEQ    $DD17           ; 
    
    DD12  CC 74 41    	LDD    #$7441          ; IMPROPER DOWNLOAD TYPE
    DD15  20 21       	BRA    $DD38           ; 
    
    
    DD17  B6 1C 11    	LDAA   $1C11           ; TEST ADDRESS OUT OF RANGE FLAG
    DD1A  85 40       	BITA   #$40            ; 
    DD1C  27 05       	BEQ    $DD23           ; 
    
    DD1E  CC 74 42    	LDD    #$7442          ; CAN'T DOWNLOAD TO SPECIFIED ADDRESS
    DD21  20 15       	BRA    $DD38           ; 
    
    DD23  85 20       	BITA   #$20            ; TEST LENGTH ERROR FLAG
    DD25  27 05       	BEQ    $DD2C           ; 
    
    DD27  CC 74 43    	LDD    #$7443          ; CAN'T DOWNLOAD NUMBER OF BYTES REQUESTED
    DD2A  20 0C       	BRA    $DD38           ; 
    
    DD2C  B6 1B FE    	LDAA   $1BFE           ; READ REQUESTED MODE
    DD2F  81 34       	CMPA   #$34            ; REQUEST DOWNLOAD- TO PCM
    DD31  26 13       	BNE    $DD46           ; 
    
    DD33  CC 74 44    	LDD    #$7444          ; READY FOR DOWNLOAD
    DD36  20 0C       	BRA    $DD44           ;
    This gives detail of how codes 42, 43 and 44 are arrived at.

    Next snip is where dl frame is received and evaluated
    Code:
    DD77  7D 1B FF    	TST    $1BFF           ; TEST FOR EXECUTE FLAG $80
    DD7A  2A 23       	BPL    $DD9F           ; BRANCH TO CONTINUE DOWNLOAD
    
    DD7C  CC 76 78    	LDD    #$7678          ; BLOCK TRANSFER MESSAGE CORRECTLY RECEIVED
    DD7F  B7 1C 0B    	STAA   $1C0B           ; DATA BYTE 0
    DD82  F7 1C 0D    	STAB   $1C0D           ; DATA BYTE 2
    DD85  B6 1B FF    	LDAA   $1BFF           ; 
    DD88  B7 1C 0C    	STAA   $1C0C           ; DATA BYTE 1
    
    DD8B  B6 1B FC    	LDAA   $1BFC           ; 
    DD8E  B7 1C 0A    	STAA   $1C0A           ; 3RD HEADER BYTE
    
    DD91  C6 06       	LDAB   #$06            ; MESSAGE BYTE COUNT
    DD93  BD DE 37    	JSR    $DE37           ; SEND MESSAGE TO THE DATA LINK
    
    DD96  21 28       	BRN    $DDC0           ; BRANCH NEVER??
    
    
    * EXECUTE CODE AT ADDRESS IN BYTE 5 AND 6
    DD98  FE 1C 03    	LDX    $1C03           ; 
    DD9B  AD 00       	JSR    $00,X           ; EXECUTE DOWNLOAD FROM ADDRESS
    
    DD9D  20 21       	BRA    $DDC0           ; 
    
    DD9F  CC 76 73    	LDD    #$7673          ; BLOCK TRANSFER COMPLETE/NEXT BLOCK
    This gives detail to how codes 78 and 73 are arrived at.

    In some places frames are not responded to. Also I note that the execution is JSR $00,X. This means that the stack shouldn't be re-assigned if the routine plans to return. While my download routine does not return, my re-init of the stack could be creating troubles for interrupt code.

  14. #74
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    Download code snips II

    Quote Originally Posted by kur4o View Post
    Try running both sides as per the quote and upload GM code to see does it work as expected. Single side upload can lead to undesired effects.
    Interesting... download to both sides may set/clear some flags. Hmmmmm

    Quote Originally Posted by kur4o View Post
    Pcm can`t execute highspeed on it`s own. It must be requested by the tool. When the pcm recieves A1 request it sets a register to command the dlc to enter highspeed. Actually the pcm doesn`t care since the highspeed is handled by DLC. Dlc is also set to revert to x1 mode on the first x1 message it receives when is in x4 mode.

    Figuring this stuff by looking at the code is next to impossible or it will take alot more time than you can think of. Some experiments reveal stuff much faster.
    It does seem to me that when DL commands are issued, the code places the DLC in 4X mode. In the code

    Code:
    ************************************************
    * DATA LINK CONTROL GET FRAME
    ************************************************
    * 1X MODE
    DC50  8E 1C 2A    	LDS    #$1C2A          ; SET STACK
    DC53  0F          	SEI                    ; DISABLE INTERRUPTS
    DC54  20 09       	BRA    $DC5F           ; GET FRAME
    
    * 4X MODE
    DC56  8E 1C 2A    	LDS    #$1C2A          ; SET STACK
    DC59  CC 18 13    	LDD    #$1813          ; CONFIGURE DATA LINK CONTROLLER
    DC5C  FD 10 60    	STD    $1060           ; FOR 4X MODE
    
    * INITIALIZE CHECKSUM
    DC5F  4F          	CLRA                   ; ZERO FRAME BYTE COUNT 
    DC60  5F          	CLRB                   ; AND CHECKSUM
    DC61  FD 1C 05    	STD    $1C05           ; 16 BIT SUM
    
    DC64  B6 1C 11    	LDAA   $1C11           ;
    The Eside seems to target $DC50 while the Tside goes to $DC56. There is a mindblowing structure of recovery if the 4X generates an error. There may be a way to have the Tside fall back to 1X. I will try some experiments on this. I have had a download on the Tside by sending the download frame a number of times. It just seems like the code was written with the exact tester they planned for in mind. All this goes away if I get another module and generate test data using another 68HC58 DLC.

    I have some time today and will give this another try.

  15. #75
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Quote Originally Posted by Tom H View Post
    There is a mindblowing structure of recovery if the 4X generates an error. There may be a way to have the Tside fall back to 1X. I will try some experiments on this. I have had a download on the Tside by sending the download frame a number of times. It just seems like the code was written with the exact tester they planned for in mind. All this goes away if I get another module and generate test data using another 68HC58 DLC.
    For 1X fallback, you need to check for "break received" on the DLC, I've extracted it from 98 "black box" PCM code. Anyway, SPS code always goes back to 4X, but if you skip the 4X switch it will work correctly in 1X.

    Anyway, I wanted to show off a little, here's a shot of working T-side read using PCM Hammer derived software :) The main kernel barely fits in the 1kB RAM, but I managed to squeeze it in there :)



    I still have some issues communicating with E-side, but it all goes in a good direction :)

Similar Threads

  1. 94-95 LT1 $EE Y-body vs. F/B-body PCM differences
    By johnny_b in forum GM EFI Systems
    Replies: 5
    Last Post: 01-15-2023, 02:41 PM
  2. Tuner Pro XDF 1999-2000 F Body + Y Body
    By john h in forum OBDII Tuning
    Replies: 33
    Last Post: 02-02-2020, 11:12 PM
  3. Replies: 31
    Last Post: 09-20-2018, 06:00 AM
  4. F-body engine install to B-body
    By serge_an in forum GM EFI Systems
    Replies: 4
    Last Post: 09-22-2016, 02:51 PM
  5. 95 F-body Fuel Pump with 95 B-Body Engine/Tank
    By EPS3 in forum GM EFI Systems
    Replies: 7
    Last Post: 09-19-2016, 02:40 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •