1997 F-Body ECM

[kur4o]

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.

[Tom H]

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...

	"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

[Tom H]

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?

[kur4o]

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.

[Tom H]

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

[kur4o]

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.

[Tom H]

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

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

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

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.

[Tom H]

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

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

************************************************
* 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.