1997 F-Body Tools

[Tom H]

Quick update... Face of this tool now looks this way. I have improved several things..
- Serial connection checks that the selected port is available and that the HomeBrew cable is connected.
- New version of the HomeBrew cable eliminates generation and checking of CRC. I now do this in software
such that CRC covers end to end. Not just the J1850 link is covered but also the serial nrz link and the usb link.
- Simplified interface to the cable should help if someone wants to port it to another cable

Future plan includes 4X

Tool.JPG

Kur4o: Is this more what you had in mind?

-Tom

[kur4o]

That looks much better, Real efficient and simplified design without crap load of confusion.

A note on improvement will be to add some debug logging in a separate tab or window, in case something bad happens mid flash, user can troubleshoot the problem.
On reading it will be good if the eeprom area of both banks is read too[if not already done], for easier files identification.

You can also add some dummy program mode, that will just dump bin to pcm, without actual writing to happen, to check for stable communication.
Something like simulated flash.

[JimCT_9C1]

Thank you Tom and kur4o for keeping on with the goal of creating a read/write flash tool for these pcms!

Been away for a while. I'll the give read/upload from post#34 a go, although not sure how far I'll get using my adapter cables vs HBC. The new interface looks clean. I second kur4o's suggestion to keep a debug or log somewhere in case it's needed.

The file format of 192k stacked bin (3x64k: Tside Bank0, Tside Bank1, Eside) is a nice direct way to lay out the bin. As pointed out in post#42,44 this format will make things easier going forward with definition files, etc.

Eventually, it would be handy to be able to read/load bins into the tool from disk that may be in other formats such as non-padded 144k (post#24,43), 145k cal (post#38) or other(?) format. Once in the tool,they could be saved to disk in 192k format for editing or written to pcm. Similar to Bin Converter utility in FlashHack.

Thanks again to you and all contributors for great work and progress!

Jim

[Tom H]

The file format of 192k stacked bin (3x64k: Tside Bank0, Tside Bank1, Eside) is a nice direct way to lay out the bin. As pointed out in post#42,44 this format will make things easier going forward with definition files, etc.
Jim

Seems I can't leave well enough alone... I made a slight change to the format: I added a 4K comment field to the front of the file. This means if you had a bunch of modified files, you could access the comment with just the notepad editor and read your comments. By default I fill this field with date and time, but you could add any comments you like. Things like made this change to this table and so on. I will try to post an example later today.

My code is tied to the HBC. Won't accept any serial port that doesn't boot with a matching string. Also, no longer is CRC done in the cable. This means that crc covers the transfer end to end. Much more secure of error. Last up the HBC checks the downstream and upstream flow for errors. Since my receiver is independent of the transmitter, the sent command is also received and fed back to software. This ensures that what you send on the bus actually got there. Finally support for xon/xoff.
There is new software for HBC that must be used. When all is done I will post it with everything else.

In an hour or so I can probably post a sample file from my bench PCM.


Still looking for a test PCM. If you have a brick or an unused PCM from OBDII years it's golden

-Tom

[Tom H]

Actually didn't take much time to make a binary. I dumped the content of both FLASH (both pages for TSide) in about 4 minutes. This is still with X1 speed.

Here is the output file. I added a few comments to show why I added the bit at the front. You can open it with just your notepad (open with ...) to see the comments stored with the code.This should help keep track of what mods are in the file and so on. One more thing though don't change the comments with notepad. This would probably offset the entire content of the file and make it a producer of bricks.

Here is the output file of my first run. You can change the extension to .bin and you will have what I started with.

-Tom

[JimCT_9C1]

Thanks for sharing, Tom.

Took a quick look and played with it a little bit.

One thing I would suggest is to place the comment/scratch area at the end of the file rather than the beginning; starting after the 192k bin data. This will avoid having to deal with offset memory addresses in definition files etc, and also avoids the potential problem you pointed out of inserted or deleted comment bytes offsetting the following bin data in the file.

I verified that TunerPro would correctly read, interpret, edit, and write files with additional information appended after the bin data. I tested using LT1 OBD1 xdf and bin files. I added and edited comments via Notepad, as well as cut and pasted the comment block from your file and edited that, before and after editing the bin data. Random length comments, separators, etc all worked with no need or effort to try to maintain a fixed block size or structure. The only downside was the need to drag to the bottom of the file after opening with Notepad to view or add comments. I think the robustness to accept unstructured input and not affect the bin data outweighs this minor inconvenience.

Interested to hear what other potential users may think.

Thanks again for all you've done!

Jim

[Tom H]

Jim,

I changed the format as you suggest. The only difference is that to view the comment (identify what the file contains) you need to scroll to the end. No big deal.

The Upload/Read part of the program is just about done now. I had trouble with the reading taking more time than windows permitted before marking the window as unresponsive. To fix this all the program is now multi-threaded so that controls such as progress bars and whatnot can all be updated with ease.

Here is the latest image of the main screen:

Tool2.jpg

Once you build the HBC, let me know and I will send over test software.

Now starting on the programming. Kur4o provided all the programming code we need to download into PCM RAM. I can re-use the same code was written for the upload section in most cases.

I need to get out to the local U-PULL-A_PART people and see if I can score another PCM. No luck till now, I think most of these were melted down up here in the salt belt.

-Tom

[Tom H]

Reading/upload is now complete except for the request from Kur4o for debug logging. I will get a look at that while the search for an LT1 OBDII PCM goes on...

There may be some interest in duplicating this capability for use with another cable. I have enclosed a transcript of the Class II bus for anyone interested.

In the file attached the first line is just to ensure the correct port is selected and opened
Lines 2 through 15 set up the download of code into internal ram
Lines 16 through 105 are downloading of the code to support modes $35 and $37 (not supported by the PCM native code)
Line 106 causes the downloaded code to execute, line 107 is the acknowledgement
Lines 108 through 9323 are the upload of flash from TSide bank 0, TSide bank 1 and ESide
Line 9324 causes the downloaded code to exit and reset the PCM, Line 9325 is the acknowledgement
Last two lines.. not necessary but are a request to normal activity on the ALDL

I hope to get to the programming side soon.

-Tom

[JimCT_9C1]

Thanks for the updates, Tom!

I'll catch up and take a look, been away from this for a couple weeks.
Great progress, thanks for the continued hard work!

Jim

[Tom H]

Hi,
Project is going ok, but with a few wrinkles. I have the module used to program the TSide loading into the PCM now. I can do all the easy work prior to programming like turn on/off vpp, read the mfg codes, checksum the part. I have looked through the zero the flash and erase the flash routines, they look OK. In addition most of the "feed the ESide fro programming" looks ok. There is trouble with the programming software however. There is no way to set the bank. Half the software looks like it wants to do a complete programming (that would be OK if we had the space to buffer the complete load somewhere), while the other half looks like it will only program the upper bank.
So that needs a bit of attention. I have already corrected two faults in the code and wonder if this module was ever used before. Alternative is that points of entry other than the start of the routine were used. I will spend a bit of time looking through this and changing it.

Main problem going forward is that I need to revive all that I did looking at bootstrapping. This is necessary because making bricks will be part of the debug. Probably can't avoid unless I am way too careful. Careful = slow.

I have not been able to find any OBDII PCMs locally. The Ontario/Canadian way seems to promote recycling as soon as possible. There are few of these cars around now. I am still on the hunt for any OBDII PCMs brick or working.

Looks like we will get a foot of snow today, so I will have time to go through the TSide programming module again and start to make the modifications needed.

-Tom

[Tom H]

On reading it will be good if the eeprom area of both banks is read too[if not already done], for easier files identification.

You can also add some dummy program mode, that will just dump bin to pcm, without actual writing to happen, to check for stable communication.
Something like simulated flash.

Hi,

I have not been reading EEPROM, but plan to. Thinking to add it into the TSide bank 0 buffer and into the ESide buffer.

Do other programming software use the EEPROM as safety in case of programming interruption? If yes, where can I find the details? If no, I will look into using this.

Kur4o, I am using your suggestion of the "dummy program mode" to test my programming. Works a treat, plan to include that. For now all I do is turn off VPPH and skip the erase.

At the moment, reading and dummy programming for TSide are working and stable. The 68HC11 software that does the actual programming needed work. I have added the needed handling of banks to it and all looks good.

Plan to start on ESide software tomorrow.

-Tom


EDIT: Looks like the EEPROM can be re-positioned such that it replaces FLASH for the vectors. There is a small but usable code space where backup brick prevention can be programmed. I will play with this a bit more. -T

[kur4o]

If you want to play it really safe on bricking, I can share how it was done on 94-95 lt1. EEprom can be used for easier bin identification since it have vin and Os id.

A mini bin was created that contains vectors reset code and communication code. Than we tested if this mini bin actually communicates and can be recovered.
On flashing, first was flashed that mini bin and later rest of the bin. Chances you had a hard brick was minimal even you completely loss power.
We also skip FFs to speed code flashing, not sure how viable is this with big $400 long messages. You can eventually decrease the message length to accommodate something like that. This can be implemented when you have solid flash code as a phase2.

[steveo]

in flashhack i make reading the 68hc11's onboard eeprom optional, but i would highly reccommend it.

it's also traditional to read the ram region as it is mapped, but i skip that by default and just leave 0 there. most users appreciate that.

i think flashhack's anti bricking logic is probably worth copying when you have the rest figured. me and kur4o did a lot of testing and research there and it is excellent, it leaves a very short window or just a few seconds during which the ecm is left unbootable, and even within that window, if you don't cut power the kernel stays loaded in ram and you can retry, so the only way you could fail is to cut power during that few second window. very unlikely.

using the eeprom is another option if you could write a compact enough kernel to fit in there, however that eeprom (at least in EE) was locked via the config register by GM, so during the first flash it is impossible to write. you would need to patch the bin's init code to alter the config register, write the bin fully, then reboot the ecm to have write access to that area (which i have done successfully, but it means your first write would always be at risk, right?) my flash tool writes that entire area as well, i figured one day someone might want to relocate a table there and allow really quick and safe updates to it

[Tom H]

using the eeprom is another option if you could write a compact enough kernel to fit in there, however that eeprom (at least in EE) was locked via the config register by GM, so during the first flash it is impossible to write. you would need to patch the bin's init code to alter the config register, write the bin fully, then reboot the ecm to have write access to that area (which i have done successfully, but it means your first write would always be at risk, right?) my flash tool writes that entire area as well, i figured one day someone might want to relocate a table there and allow really quick and safe updates to it

Interesting that locking of the register... I think we can get around that.

Writing the config register is locked into it's state once 64 eclocks have been run. Looking at the software (at least for '97) the code does this:

; VECTOR TO $4C46

		ORG $4C46

LOC_4C46:	JMP	$6621

		ORG $6621

LOC_6621:	LDS	#$1FFF		;  SET STACK AT TOP OF EXTERNAL RAM

		LDAA	#$01		;  INTERNAL RAM AT $0000, REGISTERS AT $1000
		STAA	$103D		;  CPU INIT

		LDAA	#$99		;  CONFIGURATION OPTIONS
		STAA	$1039		;  CPU OPTION

		LDAA	#$03		; TIMER CONFIGURATION OPTIONS
		STAA	$1024		; CPU TMSK2

		CLR	$1035		; BPROT: PERMISSIONS TO WRITE EEPROM/CONFIG REG

		LDD	$201F		; $0A02

		LDAB	$0200		; EEPROM PROGRAMMING TIMER
		CMPB	#$55		; LOOK FOR TAG: $55
		BEQ	$664B		; FOUND, NO BLOCK PROTECTION

		LDAA	#$10
		CMPB	#$AA		; LOOK FOR TAG: $AA
		BEQ	$6648		; OVERWRITE PROTECTING BPROT

		LDAA	#$11		; OVERWRITE PROTECTING PTCON, BLOCK 0

LOC_6648	STAA	$1035		; WRITE BPROT

LOC_664B	LDAA	#$15		; CONTINUE WITH BOOT

Downloading to ram a small routine that sets location $0200 to $55 will make the next run un-protected. The normal case is protected as you suggest. The download software need be only a few instructions. First set the tag location to $55, then a tight loop with no COP resetting. Once the COP expires (some nominal delay) a second routine can be run to program the EEPROM and OPTION registers. From then on all resets should go to the vector stored in EEPROM.

I think the programming can be done with no exposure to brickage. Still the problem of writing a kernel, but it need only be a boot loader for the programming software.

What have I missed? I hope to test this out v soon.

-Tom

[Tom H]

Hi,

This morning I tested the idea of reprogramming the EEPROM to hold some sort of non-volatile loader while programming. This *should* prevent making bricks even if the power is removed half way or some other interruption occurs.

This can be done in this way, there are just a few steps:

1. Record the content of EEPROM. This has been done in the software I am currently writing.
2. Run the code below to keep BPROT bits clear. This will no permit you to reload the CONFIG register and place the EEPROM at the top of page overlapping the flash.
3. Run code to program (not written yet) the EEPROM with a boot loader in case of programming interruption.
4. Turn off the EEPROM while programming to permit access to the top of FLASH.
5. When programming is complete, restore the EEPROM, reset the CONFIG register as normal

Once this is done, the code will always run the code in EEPROM, not the regular stuff in flash. At that point you can load into ram the programming and comms routines.

        ORG $0000

ENTRY:    LDAA    #$55        ; TAG VALUE
          STAA    $0200        ; SAVE
SLOOP:    BRA    SLOOP        ; SUICIDE BY COP

Thoughts?

-Tom