1997 F-Body ECM

[Tom H]

Have been sorting through the code for mode $34 & $36 for some time now. There are a bunch of different buffers and queues, code that depends on flags I don't yet know the purpose of and so on. Typical disassembly ?s.

One thing I am questioning is if the standard "header:frame:checksum" format is followed in mode $36. The DLC is set up for this format as is the ELM327. I need to see if/how the ....data.... you suggest is handled.

I have detailed most of the supported modes and found all of them. Different modes supported depending on which target ECM, physical vs. functional addressing and other conditions ( such as access to the data transfer)

I will keep plugging away on this, hope to complete soon.

-Tom

[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]


Here is some sample mode 36 message.
MODE is 36 80 it could be 36 00 also. It depends on pcm. 80 means download and execute. 00 means download only. Some PCMs don`t support multi message download and they execute on both 00 or 80.
(00 70) is the lenght of the message. The message lenght is contained between //...//
(00 18 10) is the ram address you want the message to get loaded. It is always 3 byte length.
[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[[.....]]
[56] this the checksum of DLC. it is calculated from data contained in {....}
this is 8-bit CRC with the following attributes

8 Bit CRC
Polynom 0x1D
Inital value 0xFF direct
Final XOR value 0xFF
Reflection IN false
Reflection Out false


So you have 2 different checksums to calculate. The DLC checksum is usually handled by the tool.
If the upload is successful you are likely to get a message containing 73.

[Tom H]

Thank you for all your help! The additional clarification is a great boost.

Looks to me as if the ELM327 is a non-starter for download. To send anything like the format you have given, a large buffer is needed internally OR the translator needs to start the transmit before all the characters have been placed in it;s fifo.
I guess a different setup will be needed. Setback but a thing that is not too difficult.

I will go through the code. I had already found the process for the 2nd byte (execute the code). Along with that are a great number of checks and standard replys (things like invalid address if not in ram )

Again, thanks for the help and I will get back over the next few days.

-Tom

[steveo]

you know if you want any help with the software end of things i'd be happy to do things like.. you know.. write a tool and UI for a flash tool or whatever? help write and clean up an XDF? i did it for $EE and i'd do it just for fun with this thing. just holler.

[kur4o]

I scored a sample of how a programming event communication should look like without errors.
It turned out that $18 is tside during programming. Did you managed to figure how the obd2 messages are transfered to eside.

The only elm device that can do the job is the obdlink devices. They have big enough buffer to handle reading/writing. They don`t support high speed mode x4 so it is still unclear if they will work in x1 mode with that flash routine.

[Tom H]

First up: Thank you for all your help in this, I am enjoying the challenge this puzzle holds and much of the info that has been shared made things much easier....

I have generated comment for most of the download code now. Still a few questions, but working through them. The project has grown larger because it is my belief that the ELM327 I have been using to attempt download will not cut it. The ELM device is set up for frames of seven or at most eight data bytes. I get as far as the response "Ready for Download" Code $44. I didn't figure out how the data got in until reading the posts.

The three byte header + 7 data + crc is OBDII standard. Looks like the programming modes uses a format outside the ELM's capability. For download an arbitrary number of bytes are generated in the frame and the number could be over 2000 if using the ram provided by the port replacement unit (space between the PRU registers at $1810 and start of FLASH at $2000). As a result of this, I plan to build a download board <sigh>
If anyone knows of programming of GM PCMs using the ELM327 PLEASE let us know. IF I am wrong about this, I am spinning my wheels...


Ok so once over the shock of the scope creep, I started planning. If you look at Kur4o's post #43 from yesterday, he outlines all the requirements. I worked through the CRC part today. If anyone is interested, I will put the code at the bottom of this post.

My understanding of the code is that the Tside download is not used for FLASH. It looks to me like the Eside (0x18) is used to transfer from tester to RAM. The code we develop or find to program can target Eside or Tside.

I will post snips of the code once confirmed.

OK, so here is the CRC code. There is no CRC code in my PCM beacause this all is done inside the DLC in hardware. The DLC can receive and/or transmit frames of any size. The command register is used to set up data transfer. Once done, a frame can be any length as long as the tx fifo is not permitted to under run. This is true on the receive side as well. The status byte checked with each receive byte tells if a completion code is ready, this signals EOF.


This is just used to test the CRC class...

// J1850.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

using namespace std;


int main(int argc, char *argv[] )
{
	UINT8	uR;
	UINT8	uLength;
	CRC_Gen	crc;

//	UINT8	uFrame[] = { 0x00, 0x00, 0x00, 0x00 };	// 59
//	UINT8	uFrame[] = { 0xF2, 0x01, 0x83 };		// 37
//	UINT8	uFrame[] = { 0x0F, 0xAA, 0x00, 0x55 };	// 79
//	UINT8	uFrame[] = { 0x00, 0xFF, 0x55, 0x11 };	// B8
//	UINT8	uFrame[] = { 0x33, 0x22, 0x55, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF};	// CB
//	UINT8	uFrame[] = { 0x92, 0x6B, 0x55 };		// 8C
	UINT8	uFrame[] = { 0xFF, 0xFF, 0xFF, 0xFF };	// 74

	uLength = sizeof(uFrame) / sizeof(UINT8);

	crc.Initialize();
	uR = crc.CalcCRC(uFrame, uLength);

    return 0;

Simple class so I can re-use the CRC generator as needed

#include "stdafx.h"


CRC_Gen::CRC_Gen()
{
}


CRC_Gen::~CRC_Gen()
{
}


void CRC_Gen::Initialize()
{
	uRemainder = 0xFF;
}


UINT8	CRC_Gen::CalcCRC(UINT8* pFrame, UINT8 uLength)
{
	while (uLength > 0)
	{
		uData = *pFrame;

		uData = crc_lut[uData];
		uRemainder = crc_lut[uRemainder];

		uRemainder = uData ^ uRemainder;

		uLength--;
		pFrame++;
	}

	return(~uRemainder);
}

Note that the table crc_lut is where all the action is

/*
8 Bit CRC
Polynom 0x1D
Inital value 0xFF direct
Final XOR value 0xFF
Reflection IN false
Reflection Out false

X8 + X4 + X3 + X2 + 1
X7 + X6 + X2(C4 hex)
*/

#include "stdafx.h"

class CRC_Gen
{
public:
	 CRC_Gen();
	~CRC_Gen();
	void	Initialize();
	UINT8	CalcCRC(UINT8* pFrame, UINT8 uLength);

private:
	UINT8			uData;
	UINT8			uRemainder;
	const UINT8		crc_lut[256] = {
		0x00, 0x1d, 0x3a, 0x27, 0x74, 0x69, 0x4e, 0x53,
		0xe8, 0xf5, 0xd2, 0xcf, 0x9c, 0x81, 0xa6, 0xbb,
		0xcd, 0xd0, 0xf7, 0xea, 0xb9, 0xa4, 0x83, 0x9e,
		0x25, 0x38, 0x1f, 0x02, 0x51, 0x4c, 0x6b, 0x76,
		0x87, 0x9a, 0xbd, 0xa0, 0xf3, 0xee, 0xc9, 0xd4,
		0x6f, 0x72, 0x55, 0x48, 0x1b, 0x06, 0x21, 0x3c,
		0x4a, 0x57, 0x70, 0x6d, 0x3e, 0x23, 0x04, 0x19,
		0xa2, 0xbf, 0x98, 0x85, 0xd6, 0xcb, 0xec, 0xf1,
		0x13, 0x0e, 0x29, 0x34, 0x67, 0x7a, 0x5d, 0x40,
		0xfb, 0xe6, 0xc1, 0xdc, 0x8f, 0x92, 0xb5, 0xa8,
		0xde, 0xc3, 0xe4, 0xf9, 0xaa, 0xb7, 0x90, 0x8d,
		0x36, 0x2b, 0x0c, 0x11, 0x42, 0x5f, 0x78, 0x65,
		0x94, 0x89, 0xae, 0xb3, 0xe0, 0xfd, 0xda, 0xc7,
		0x7c, 0x61, 0x46, 0x5b, 0x08, 0x15, 0x32, 0x2f,
		0x59, 0x44, 0x63, 0x7e, 0x2d, 0x30, 0x17, 0x0a,
		0xb1, 0xac, 0x8b, 0x96, 0xc5, 0xd8, 0xff, 0xe2,
		0x26, 0x3b, 0x1c, 0x01, 0x52, 0x4f, 0x68, 0x75,
		0xce, 0xd3, 0xf4, 0xe9, 0xba, 0xa7, 0x80, 0x9d,
		0xeb, 0xf6, 0xd1, 0xcc, 0x9f, 0x82, 0xa5, 0xb8,
		0x03, 0x1e, 0x39, 0x24, 0x77, 0x6a, 0x4d, 0x50,
		0xa1, 0xbc, 0x9b, 0x86, 0xd5, 0xc8, 0xef, 0xf2,
		0x49, 0x54, 0x73, 0x6e, 0x3d, 0x20, 0x07, 0x1a,
		0x6c, 0x71, 0x56, 0x4b, 0x18, 0x05, 0x22, 0x3f,
		0x84, 0x99, 0xbe, 0xa3, 0xf0, 0xed, 0xca, 0xd7,
		0x35, 0x28, 0x0f, 0x12, 0x41, 0x5c, 0x7b, 0x66,
		0xdd, 0xc0, 0xe7, 0xfa, 0xa9, 0xb4, 0x93, 0x8e,
		0xf8, 0xe5, 0xc2, 0xdf, 0x8c, 0x91, 0xb6, 0xab,
		0x10, 0x0d, 0x2a, 0x37, 0x64, 0x79, 0x5e, 0x43,
		0xb2, 0xaf, 0x88, 0x95, 0xc6, 0xdb, 0xfc, 0xe1,
		0x5a, 0x47, 0x60, 0x7d, 0x2e, 0x33, 0x14, 0x09,
		0x7f, 0x62, 0x45, 0x58, 0x0b, 0x16, 0x31, 0x2c,
		0x97, 0x8a, 0xad, 0xb0, 0xe3, 0xfe, 0xd9, 0xc4 };
};

I don't claim to be a software guy, but I have tested this code and I think it's OK.

-Tom

[kur4o]

https://www.scantool.net/

These are the only elm devices that are tested to work for reading/flashing Gm PCM.
All have a 192 bytes buffer out of the box that support elm commands. They also have extended commands that enables upto 2-3k bytes messages.
The usb version has the smallest buffer.
The only drawback is the lack of high speed mode, which might be fatal if the main communication loop that is loaded at RAM is set to communicate only in high speed. You might check if there is multiframe support for mode 36 00[download only], so you can split the message in smaller pieces.

A homebrew board is also easy to do, If you are interested I will try to get you a schematic.


The main routine that is loaded at the very start is the code the processor will run from during reflash. It should have all the loops for bd2 communication and you need to land it in the processor ram space. So my guess is both processor have slightly different versions and the chips are flashed independantly. The main concern here is how the obd-2 messages goes to eside RAM. Is it direct communication, or it goes through the SPI channel from tside to eside.

After the main communication loop is loaded and the processor runs from there you can send more code to execute.
A erase code or a vpp enable code. After it gets executed there is a jump again to main control loop. It should be an indefenite loop or it could expire after x time of inactivity. A disassembly will reveal all the functions it has.

[Tom H]

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

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

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]

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]

[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

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]

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