1997 F-Body ECM

**Tom H** · 03-26-2019

Originally Posted by kur4o

{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

**kur4o** · 03-27-2019

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.

**Tom H** · 03-27-2019

Originally Posted by kur4o

[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

**kur4o** · 03-27-2019

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.

**Tom H** · 03-27-2019

Originally Posted by kur4o

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

**Tom H** · 04-11-2019

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** · 04-11-2019

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.