Page 4 of 34 FirstFirst 12345678914 ... LastLast
Results 46 to 60 of 509

Thread: 1997 F-Body ECM

  1. #46
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    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.
    Attached Files Attached Files

  2. #47
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    CRC, update on progress, ELM327 troubles...

    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...
    Code:
    // 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
    Code:
    #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
    Code:
    /*
    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

  3. #48
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    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.

  4. #49
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    you guys are both brilliant. i really want to get an lt1 again so i can contribute, i'll have to keep my eyes open. i don't need a car right now, but maybe an lt1 in a truck swap or some such thing

    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.
    what you suggest would involve one side running a (probably uploaded and executed) spi 'relay' loop of some kind during programming so the other side can program, wouldn't it? or how else would it be accomplished? are you sure direct comms aren't used? just curious because i had to scratch my head for a long time to realize that in $EE the ALDL bus runs in parallel but the e-side doesn't respond to messages unrelated to programming, pretty much just for the purpose of programming without having to rely on the other side as a relay or whatever.

  5. #50
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    [QUOTE=steveo;74693
    what you suggest would involve one side running a (probably uploaded and executed) spi 'relay' loop of some kind during programming so the other side can program, wouldn't it? or how else would it be accomplished? are you sure direct comms aren't used? just curious because i had to scratch my head for a long time to realize that in $EE the ALDL bus runs in parallel but the e-side doesn't respond to messages unrelated to programming, pretty much just for the purpose of programming without having to rely on the other side as a relay or whatever.[/QUOTE]

    This all is yet to be confirmed. I am sure no direct comms over the class 2 OBDII link takes place with the Eside because there is no DLC on the E board. One could see a way that SPI (ALDL the 8192 baud serial or however it ti described) could be used to program. I would like to see a more general solution, one that could be used on later PCMs as well. Will post later this morning with code to take Srecords and produce a frame including header, mode and parameters, data, checksum and crc. Then the trick becomes designing/finding hardware that can deliver the long frame. I have been thinking about the buffered obdlink hardware kur4o described. While this is not my preferred solution, it could work for sure. As long as the buffer is big enough to send a download frame, multiple mode 36 commands can be issued. With this we can fill the available ram one chunk at a time. the size of the chunk depends on the buffer size. Anything over 20 bytes or so could work. Frame overhead is

    3 bytes header, 7 bytes mode and parameters, then after the data, 2 bytes checksum, 1 byte crc =13 bytes

    Adding the overhead with the smallest data size I think could be reasonable (16) gives a working frame buffer size at the tester of 19 bytes. As in most things more is better.

    The other way to go is with the 'HC58 DLC. This being the same part used on the Tside board. That part can send and receive any length. The internal FIFOs permit the software to access the frame while it is still being received. This eliminates any constraint on how long the frame is.

    -Tom
    Last edited by Tom H; 03-09-2019 at 04:19 PM.

  6. #51
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I have completed code to generate the long mode $36 download frames. Can't thank kur4o enough for the help...

    Starting with the details of a correct frame...
    Code:
    {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

    I generated an assembler source file for the content of that frame. This represents the code we expected to be downloaded. This means that the header, mode and parameters along with the checksum and crc bytes are removed from the source code. Origin is set to match what I see in the frame.
    Code:
    	ORG $1810
    	;DB  $6D  Header is re-generated by the program
    	;DB  $10  
    	;DB  $F0  
    	;DB  $36  
    	;DB  $80  
    	;DB  $00  
    	;DB  $70  
    	;DB  $00  
    	;DB  $18  
    	;DB  $10  
    START	DB  $86  
    	DB  $86  
    	DB  $36  
    	DB  $CE  
    	DB  $76  
    	DB  $80  
    	DB  $3C  
    	DB  $30  
    	DB  $9D  
    	DB  $86  
    	DB  $38  
    	DB  $31  
    	DB  $39  
    	DB  $18  
    	DB  $38  
    	DB  $18  
    	DB  $EC  
    	DB  $02  
    	DB  $FD  
    	DB  $18  
    	DB  $7C  
    	DB  $CD  
    	DB  $EE  
    	DB  $00  
    	DB  $18  
    	DB  $08  
    	DB  $18  
    	DB  $08  
    	DB  $18  
    	DB  $08  
    	DB  $18  
    	DB  $08  
    	DB  $4F  
    	DB  $9D  
    	DB  $8F  
    	DB  $C6  
    	DB  $40  
    	DB  $E7  
    	DB  $00  
    	DB  $18  
    	DB  $E6  
    	DB  $00  
    	DB  $E7  
    	DB  $00  
    	DB  $FB  
    	DB  $18  
    	DB  $7F  
    	DB  $F7  
    	DB  $18  
    	DB  $7F  
    	DB  $24  
    	DB  $03  
    	DB  $7C  
    	DB  $18  
    	DB  $7E  
    	DB  $9D  
    	DB  $89  
    	DB  $C6  
    	DB  $C0  
    	DB  $E7  
    	DB  $00  
    	DB  $9D  
    	DB  $8C  
    	DB  $18  
    	DB  $E6  
    	DB  $00  
    	DB  $E1  
    	DB  $00  
    	DB  $27  
    	DB  $07  
    	DB  $4C  
    	DB  $81  
    	DB  $19  
    	DB  $23  
    	DB  $D6  
    	DB  $20  
    	DB  $12  
    	DB  $08  
    	DB  $18  
    	DB  $08  
    	DB  $3C  
    	DB  $FE  
    	DB  $18  
    	DB  $7C  
    	DB  $09  
    	DB  $FF  
    	DB  $18  
    	DB  $7C  
    	DB  $38  
    	DB  $26  
    	DB  $C5  
    	DB  $86  
    	DB  $86  
    	DB  $20  
    	DB  $02  
    	DB  $86  
    	DB  $85  
    	DB  $36  
    	DB  $CE  
    	DB  $76  
    	DB  $80  
    	DB  $3C  
    	DB  $30  
    	DB  $9D  
    	DB  $86  
    	DB  $38  
    	DB  $31  
    	DB  $39  
    	DB  $00  
    	DB  $00  
    	DB  $00  
    	DB  $00  
    	;DB  $29  Checksum is regenerated by the program
    	;DB  $0A  
    	;DB  $56  CRC is regenerated by the program
    	END     START;	end of program with start address specified
    Assembling that code, we come up with the Srecord (.S19) file that we want to turn into a frame...
    Code:
    S1231810868636CE76803C309D86383139183818EC02FD187CCDEE0018081808180818085B
    S12318304F9D8FC640E70018E600E700FB187FF7187F24037C187E9D89C6C0E7009D8C181A
    S1231850E600E10027074C811923D620120818083CFE187C09FF187C3826C5868620028605
    S11318708536CE76803C309D8638313900000000B4
    S9031810D4
    The Srecord file is input to the frame generator code... output looks like this
    Code:
    Input file opened
    
    Line: 1  Byte count: 75
    Record type: S1 found
    Record length: 0x23
    Record address: 0x1810
    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
    
    Checksum: 0x5b
    
    Line: 2  Byte count: 4b
    Record type: S1 found
    Record length: 0x23
    Record address: 0x1830
    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
    
    Checksum: 0x1a
    
    Line: 3  Byte count: 4b
    Record type: S1 found
    Record length: 0x23
    Record address: 0x1850
    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
    
    Checksum: 0x05
    
    Line: 4  Byte count: 2b
    Record type: S1 found
    Record length: 0x13
    Record address: 0x1870
    85 36 ce 76 80 3c 30 9d 86 38 31 39 00 00 00 00
    
    Checksum: 0xb4
    
    Line: 5  Byte count: b
    Record type: S9 found
    Record length: 0x3
    Record address: 0x1810
    Srecord indicated execution start address: 0x1810
    
    Frame content:
    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

    Since the output frame matches the original example frame, I think all the code that adds headers, mode and parameters, checksum and CRC is well tested.
    Using this frame generator we can write 6811 code, assemble it to Srecords, make a mode 36 frame. That frame can then be used to download the PCM.

    I am happy to share all code, but the archive of the visual studio project is quite large (27M). I am not sure a file that large should be loaded here (?)
    Let me know what would be of use. The actual source is quite small and the exe is tiny.

    I will make a example program the standard "Hello World" to download. Then it is on to figuring out how to bash bits to get around limits of the ELM327

    -Tom

  7. #52
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Wow, I see I'm not the only one to reverse engineer OBD2 LT1 PCM :) Nice work, but it's a shame we are doubling up... I started working on this PCM over a year ago, now I have full E-side and partial T-side disassembly done in IDA and I'm in the process of finalizing the reflash kernel. I have succesfully read and reflashed T-side, E-side is still giving me some problems (SPI synchronization).
    I'm willing to share most my work, there's a lot yet to be done on T-side - the transmission code is quite complicated.
    My goal is to make fully functional and intuitive OBD2 LT1 tuner, partially free (but not completely, coding the flash kernel in pure assembly took me almost a year and was a major PITA).

    As for the reflash, there are two routines uploaded, one to each PCM side. T-side does all the OBD data transfer functions, and relays data to E-side over SPI. E-side has routines to process SPI received data. ALDL is not used during reflash, I'm not sure if it is even connected to E-side, and even if it was, it's 8192bps vs 41.6 kbps - no brainer which interface to use :)

    ELM327 will not work for reflash, it does not accept long messages, but STN1110/STN1170 (cheap ELM327 compatible interface) will work in slow 1X mode. For Fast reflash AVT cable is the best option, which I'm using.

    I'm attaching T-side disassembly, where all the OBD Mode 34 magic goes ;)
    Attached Files Attached Files
    Last edited by dzidaV8; 03-10-2019 at 12:58 AM.

  8. #53
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Fantastic to see other folks interested!!!

    "
    Wow, I see I'm not the only one to reverse engineer OBD2 LT1 PCM :) Nice work, but it's a shame we are doubling up... I started working on this PCM over a year ago, now I have full E-side and partial T-side disassembly done in IDA and I'm in the process of finalizing the reflash kernel. I have succesfully read and reflashed T-side, E-side is still giving me some problems (SPI synchronization).
    "
    You are much farther along with this than I am --> great going!

    "
    As for the reflash, there are two routines uploaded, one to each PCM side. T-side does all the OBD data transfer functions, and relays data to E-side over SPI. E-side has routines to process SPI received data. ALDL is not used during reflash, I'm not sure if it is even connected to E-side, and even if it was, it's 8192bps vs 41.6 kbps - no brainer which interface to use :)
    "
    This confirms what I have suspected. Thanks

    "
    ELM327 will not work for reflash, it does not accept long messages, but STN1110/STN1170 (cheap ELM327 compatible interface) will work in slow 1X mode. For Fast reflash AVT cable is the best option, which I'm using.
    "
    Two questions here if you don't mind: How does one know what chip is used in a cheap interface cable? I am not sure how to probe into the USB module to determine this. 2nd Q is can the ELM or STN be re-programmed? I will look into cost, availability and tech of the AVT to see if I can get my hands on one up here in Canada.

    Thanks for the info. I have done quite a bit with the Tside and am interested to see how well I did <grin>

    If there is anything I can help out with, please just ask.

    Cheers,
    -Tom

  9. #54
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I have completed "Hello world" code and generated a download frame for testing. The object here is to download a benign file to ram proving the download code. In moving with caution, I hope to avoid creating bricks...

    The simple 68hc11 code I wrote is:
    Code:
    * Clock source	16MHZ to the PCMs 12.5829
    * Eclock	 4MHZ to the PCMs  3.1457
    * Timer is prescaled by 1, 4, 8 or 16
    * Prescale is set in TMSK2 $1024 bits 1:0
    * TMSK2 defaults to $00 on reset
    * Default setting overflow at 60hz to the PCMs 50hz
    
    REGISTERS	EQU	$1000		;
    RAMEND		EQU	$03FF		;
    
    TFLG2		EQU	$25		;
    SPCR		EQU	$28		;
    BAUD		EQU	$2B		;
    SCCR1		EQU	$2C		;
    SCCR2		EQU	$2D		;
    SCSR		EQU	$2E		;
    SCDR		EQU	$2F		;
    
    	ORG	$0000			; SET ORIGIN
    
    
    START	LDX	#REGISTERS		; POINT X AT REGISTER BASE ADDRESS
    
    ; NO NEED TO SET UP PORT... ALREADY SET BY PCM CODE OR
    ; IN THE CASE OF TEST, THE BOOTSTRAP ROUTINE
    ;	BSET	SPCR,X,$20		; SET PORT D FOR WIRE OR MODE
    
    ;	LDD	#$330C			; RATE IS INPUT /4(ECLK) /8(PRS) /13 DIVISOR = CLK/416
    ;	STAA	BAUD,X			; RATE IS CLOCK /416 (16M:  2,400  PCM: 1,890)
    ;	STAB	SCCR2,X			; ENABLE SCI
    
    DELAY	LDAA	#$80			; MASK TIMER OVERFLOW FLAG
    	BITA	TFLG2,X			; TEST TIMER FLAG 
    	BEQ	DELAY			; LOOP WAITING FOR TIMER TO OVERFLOW
    
    	STAA	TFLG2,X			; CLEAR THE OVERFLOW FLAG
    
    	DEC	TCOUNT			; DECREMENT COUNT
    	BNE	DELAY			; LOOP UNTIL EXTENDED COUNT REACHES ZERO
    
    SEND	LDAA	#$F0			; RE-INITIALIZE THE EXTENDED COUNT
    	STAA	<TCOUNT			; (~4S 16M) (~5S 12.5829M) DELAY
    
     	LDY	#HELLO			; POINT AT MESSAGE
    TXRDY	LDA	#$80			; TEST TX EMPTY
    	BITA	SCSR,X			; WAIT TO TX NEXT CHAR
    	BEQ	TXRDY			; LOOP
    
    	LDAA	0,Y			; READ MESSAGE
    	STAA	SCDR,X			; TRANSMIT
    
    	INY				; POINT TO NEXT CHAR
    	CPY	#HEND			; TEST FOR LAST OF MESSAGE
    	BGT	DELAY			; BACK TO 1S WAIT
    
    	BRA	TXRDY			; SEND NEXT CHAR
    
    HELLO	DB	"Hello world!!!"
    	DB	$0A
    HEND	DB	$0D
    
    TCOUNT	DB	$00			; EXTEND THE TIMER 	
    
    	END	START
    When loaded into Tside or Eside ram and executed, this code will output it's message every 5 seconds. After reset or power down no changes will have been made to the PCM.

    The attached file is the download frame (Mode $36) that when sent will test the setup. On my system I have named the download file with a .DFR extension (Download FRame). This is not a permitted upload type on this system, so I renamed it .bin. I am sure this will be confusing later but....

    I need to spend some time now digesting all the info that has been sent to me and getting hardware together to support download. I should mention also that the opti-spark simulator I built a while back has not yet been tested. I need to solve some questions regarding VATS before that has any hope. I will get there, but this is a long road.

    Cheers,
    -Tom
    Attached Files Attached Files

  10. #55
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    Project update

    My project continues, but with a number of twists and turns

    After finding that the ELM cable I had been using to test my PCM was not capable of download, I looked into what options there were for replacement. First, I wanted to understand VPW to see if the elm could be re-programmed. The re-programming part turned out to be a dead end. The cable I am using is a clone and not likely the PIC part I expected. Even if I was to learn to re-program it, I would still need a full suite of tools to assemble code and some sort of JTAG programmer to get the code into the part. This all is another project on it's own.

    I have a number of test boards with 68HC11 parts on them that run at 16MHZ (4M eclock). I read through the J1850 spec and wrote code to transmit frames of a length that is usable. Debug of this went OK until I tried to connect it to the ELM327. At that point, the ELM could not see the frame I sent. Turns out that the elm transmits a frame, then listens to the bus for a short (under a second even with the AT ST option set to $FF) time. After this it goes into a loop looking for input from it's serial port to the PC terminal. <sigh>
    I was able to send a frame through the elm327 and reply through my proto board. It looks like if I am to use this technique, I will need to write VPW receive code also and replace the whole elm327. I feel like I made a mistake starting with the elm327 in the first place.

    Commercially available solutions are $300 or so and still have limitations. All told there is one answer I feel works best for me that I will describe. First though a number of things I noticed from the J1850 spec and BDLC datasheet
    • - J1850 limits the frame size to 12 thus the programming routines are outside the standard
      - There is no VPW at 41.6 described in the standard. (Does anyone know for sure if the 41.6 is VPW or PWM from the standard?)
      - The BDLC data sheet has almost no description of 4X timing and so on. This is outside the J1850 standard (I think)
      - The VPW 10.4 does not actually deliver 10.4K bits/second. Pulse width and level in combination describe the bits. As such the data rate varies between 7,812 and 15,625 the named bit rate of 10.4 is an average.


    For me, given that GM has gone outside the regular standard, the best solution is to use the same MC68HC58 DLC chip that they do. Once I have completed my test setup, I will get an old PCM from the wreckers. That should be about $30 or so. I plan to remove the Eside board and re-program the Tside to become my interface. This will eliminate any need to build hardware. Also this is much easier than trying to collect the parts and produce a circuit board.
    The finished interface will support 4X mode, frames of any length for programming. I need to do all this just to get back to the original project I started on.....

  11. #56
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    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.

  12. #57
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I found interesting thread for a pcm with similar components.

    https://pcmhacking.net/forums/viewtopic.php?f=8&t=4671

    It has the same memory chip as tside and bank switching look similar.

    Raw bin file is scrambled due to address line swapping. Did you managed to find something about that issue.
    One thing that is still missing in obd-1 pcm hacking is a bin descrambler from raw bin to usable bin.

  13. #58
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    One thing that is still missing in obd-1 pcm hacking is a bin descrambler from raw bin to usable bin.
    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.

  14. #59
    Fuel Injected! Terminal_Crazy's Avatar
    Join Date
    Oct 2015
    Location
    Lancashire England
    Posts
    410
    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.
    I tried a little looking at the $EE Images.
    I'd presumed the DATA lines were scrambled.
    I hadn't considered the ADDRESS lines.

    Would other .bin files generally have a constant phrase in the such as the © DE Corp in the $EE... although you'd probably know some findable data sequence.


    Mitch
    '95 Z28 M6 -Just the odd mod.
    '80 350 A3 C3 Corvette - recent addition.

  15. #60
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Thank you again... great thread. I need to work on searching existing topics a bit better!

    Great info re x1 / x4 mode. That info isn't even in the data sheet. I don't think my HC11 can keep up with bit bashing on x4 so not needing it is great. Rx is almost done just starting to test the input side of the proto board now.
    -Tom

    Quote Originally Posted by kur4o View Post
    I found interesting thread for a pcm with similar components.

    https://pcmhacking.net/forums/viewtopic.php?f=8&t=4671

    It has the same memory chip as tside and bank switching look similar.

    Raw bin file is scrambled due to address line swapping. Did you managed to find something about that issue.
    One thing that is still missing in obd-1 pcm hacking is a bin descrambler from raw bin to usable bin.

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
  •