1997 F-Body ECM

**kur4o** · 01-12-2020

I have another theory. The chip has built in rom with $800 bytes and some bootloader. At reset the $800 bytes are copied to ram and the loop is executed from there. Later eside can take control and rewrite the $800 bytes with user specified code. In 94-95 the code is what the pcm needs, so it is not updated. In 96-97 the code needs some changes and eside loads new custom code for the new features of the pcm.

The TPU might have different memory layout and the shared memory there can be seen at $0-$2df compared to eside 1400-16df.

I looked again at the data and it seems like 8byte instruction scheme. Each 8 bytes represent some instructions sequence and the second byte is likely 00 or randomly around 80 or 40.

It could be some form of calibration data.

**Tom H** · 01-13-2020

This post is a little off the current topic, but perhaps of use to some folks who have "bricked" a PCM. I am looking at the ESide with a view to placing the processor in bootstrap mode. There is a 40 pin connector that is not populated located opposite edge from the black connector. It's on both T & Eside boards. I believe this was used by the developers and the folks doing the calibrations. The connector attached to a 3rd board with a two port memory. There is still code set up to drive this test board that exists in the release code. An example of this came up when looking at the TPU... Location $3B85 is set in the calibration to a location in the TPU that the engineer wants to monitor. Production code sets it to zero, but when in use it would be set in the $1400 - $17FF range.

In any case, back to the bricked PCM problem... The un-stuffed connector has connection for TXD, RXD, Ground, ModeA, ModeB and +5V on that connector in the first 8 locations. I believe that was such that the test board could re-flash. We can use these signals in the same way to run test code. Our test code can easily re-flash the part to un-brick. I hope to get the bootstrap mode working today/tomorrow. When this gets done, I will publish some pictures with the pinout and an intro of how to run test code on the ESide board.

-Tom

**kur4o** · 01-13-2020

The un-stuffed connector has connection for TXD, RXD, Ground, ModeA, ModeB and +5V on that connector in the first 8 locations

That will be awesome if you can figure it out how to use it.
It is only been speculated how to implement the headers but never done. I traced most of the pins to the memory chip, but there might be more for the processor. Anyway to reflash the chip on board a 12v source will be needed for the VPP pin on the flash chip.

I managed to find a 2000 diesel bin, and made a quick disassembly. The TPU doesn`t have the extra data written as per 96-97 code. It is set up more like the 94-95 code. I will try some earlier diesel bins to find some data for comparison.

**Tom H** · 01-13-2020

Hi,

I was able to place the ESide in bootstrap mode, just a little more complicated than I thought. I had forgotten the bit about the bootstrap places port D in wire or mode. I needed a 10K pullup there. Second is that the RX is not defaulted in my case. This is because the ribbon between E & T sides has been removed. This required a second pullup OR to be driven by my usb<-->serial cable. Since I had no connection, this floated and started a download with no valid data = crash.

This download mode is the same as I used for my 68HC11 based Opti-simulator. Thus I have the needed software to include the initial 0xFF. Probably won't get to this for a few days to try things out. Wife has some complaints re time spent.

Details to follow...

-Tom

**Tom H** · 01-13-2020

Originally Posted by Tom H

Hi,

I was able to place the ESide in bootstrap mode, just a little more complicated than I thought. I had forgotten the bit about the bootstrap places port D in wire or mode. I needed a 10K pullup there. Second is that the RX is not defaulted in my case. This is because the ribbon between E & T sides has been removed. This required a second pullup OR to be driven by my usb<-->serial cable. Since I had no connection, this floated and started a download with no valid data = crash.

This download mode is the same as I used for my 68HC11 based Opti-simulator. Thus I have the needed software to include the initial 0xFF. Probably won't get to this for a few days to try things out. Wife has some complaints re time spent.

Details to follow...

-Tom

I have run code on the ESide this morning, this is yet another tool in the box to unravel the TPU.

The code I ran is a simple "Hello World!" sort of thing. It just sits there kicking the 68HC11's COP and the PRU's watchdog while sending the message over and over. Plan is now to get a better look at the TPU. Suggestions re code to write are welcome.

Code:

* Clock source	12.5829 to the test boards 16MHZ
* Eclock	 3.1457 to the test boards 4MHZ
* Baud rate for ESide 1,887.4HZ

REGISTERS	EQU	$1000		;
RAMSTART	EQU	$0000		;
RAMEND		EQU	$03FF		;

SCSR		EQU	$2E		;
SCDR		EQU	$2F		;


	ORG	$0000			; SET ORIGIN

START	SEI				; MASK INTERRUPTS
	LDX	#REGISTERS		; POINT X AT REGISTER BASE ADDRESS

LOOP 	LDY	#HELLO			; POINT AT MESSAGE START

	LDAA	#$55			; RESET 68HC11 COP
	STAA	$103A			; COP ARMED
	LDAA	#$AA			; 
	STAA	$103A			; COP RESET

	LDD	#$50A0			; RESET THE PORT REPLACEMENT
	STAA	$1806			; WATCHDOG TIMER
	STAB	$1806			;

WAIT_TX	BRCLR	SCSR,X,#$80,*		; WAIT TO TX NEXT CHAR

	LDAA	0,Y			; READ MESSAGE BYTE
	STAA	SCDR,X			; TRANSMIT OVER SCI

	INY				; POINT TO NEXT CHAR
	CPY	#HEND			; TEST FOR LAST OF MESSAGE
	BEQ	LOOP			; BACK TO 1S WAIT

	BRA	WAIT_TX			; SEND NEXT CHAR

HELLO	DB	"Hello world!!!"
	DB	$0A
	DB	$0D

HEND	EQU	*

	END	START

Again, details to follow...

-Tom

**Tom H** · 01-13-2020

Thank you for the info dzidaV8!

Looks like I have a bunch of reading ahead.

-Tom

**Tom H** · 01-16-2020

Hi,

This is a quick note to describe how the 68HC11 bootstrap mode can be used to further learning details of the PCM. The second use would be to revive a bricked PCM.

To place the processor in bootstrap mode, drive both modea and mode pins low and power the board. After reset, TX should be driven to a break condition until you start the download. After the first character of your binary is sent, the tx will echo all the received bytes.

Assemble your program to run within the internal ram. Small, light, compact is the only way here. Prepend the binary with an FF character and send to the board using 1,888 baud. Once these steps are complete, the bootstrap loader will execute your program at $0.

The connections to the board are given in the attached picture. Please note that bootstrap mode uses wire or mode. This means that a pullup on the TX is needed OR that your program needs to change the setting. I added the resistor (10K) for simplicity and because the mode affects other pins on the port. I did not want contention with some other chip, and the resistor avoids this. For best practice, I also added a 10K pullup to the RX side. This just defaults the RX to prevent a "download" from starting before I connect the serial.

I am attaching a few files... I have a program that takes an Srecord file and turns it into a bin, complete with the leading "0xFF". Ask me if you want the source, but it isn't something I am proud of... sort of a hack job to "geterdone". Just a console app but it got carried away re-using some Srecord parsing code that already existed. Nuf said.

Second attach is an HC11 program to dump areas of memory in srecords. Please note that bootstrap enforces the EEPROM to exist at 0xFE00 - FFFF. So without re-program of the config reg, you can't see that bit. This is of no trouble to me, as the intent is to figure out the TPU.

Questions: please ask and I will help if I can BUT the major project for me needs to be the TPU. All info and code is offered at your risk and you need to understand the boot mode well before you proceed. I have not written code to erase and clear the FLASH as yet. I will do this later perhaps

I had trouble attaching the .exe and .asm files. I renamed them as .exe.txt and .asm.txt. I hope these will get through OK.

-Tom

**dzidaV8** · 01-13-2020

Originally Posted by kur4o

I have another theory. The chip has built in rom with $800 bytes and some bootloader. At reset the $800 bytes are copied to ram and the loop is executed from there. Later eside can take control and rewrite the $800 bytes with user specified code. In 94-95 the code is what the pcm needs, so it is not updated. In 96-97 the code needs some changes and eside loads new custom code for the new features of the pcm.

The TPU might have different memory layout and the shared memory there can be seen at $0-$2df compared to eside 1400-16df.

I looked again at the data and it seems like 8byte instruction scheme. Each 8 bytes represent some instructions sequence and the second byte is likely 00 or randomly around 80 or 40.

It could be some form of calibration data.

I agree with you, and I think we shouldn't consider the TPU as a microprocessor, I'm pretty sure it's an FPGA matrix with a tiny bootloader, like in 68332 micros. The binary opcodes for 68332 TPU are really dense in data packing (i.e. only two MSb define the major operation, the rest are operands), so there might be no obvious repetition in 16 or 8 bits looking at the binary.