Does anyone "really" know the Basics?

[FastFieros]

Well, here it is 2003. I hope everyone is ready to get this OBDII PCM available for use as a custom engine install.

Here is what I have tried to understand over the last 2 weeks. Please keep in mind I have just started learning this stuff. I will make mistakes but hopefully someone will give some direction to resolve.

I think we should start with talking to the PCM. If we cannot download and upload, theres really no BIN file in the world that is going to help. Currently the method by average users is > pop the 28F400BX off the board and place it in a EMP-20 or 21 device and flash it. Easy off, hard back on and failures do occur. Now theres DHP. They seem to flash with Tech 2's thorough the OBDII port. Then theres GM SPS software that definitely uploads to the PCM, but I have not seen anyone ever mention that the Tech 2 can download from the PCM. Then theres HyperTech. Now they can download from the PCM to the hand unit and change indivdual preferences on limited things. Now, are they changing a downloaded file and reuploading the file in the changed state?

Then there's the PCM questions. Does anyone have a schematic of the PCM for the L67? I am curious what all the chips are on the board. We know the 68332 and the 28F400BX, but there are 10 or so more chips there also. The reason for the needing to know this is the Motorola docs indicate there is a BDM (background debugger mode) and you can tap into this and watch the code execution. Not sure what you would see, but I am curious what it looks like.

Then theres the Tech 2. This I have read is called a ICE (In circuit emulator). Seems the Tech 2 is designed to take over the BDM and execute programs designed to Flash chips, change table parameters. Sounds like it does that very well.

Then there are those BIN files. What are you supposed to do with those besides Hex Workshop. I have looked at those Hex numbers enough to see that figuring tables there is a chore. You seem to need to know the S record lenght. Then the data lenght, or something like that. I see why TuneCat works so great now when it comes to downloading a BIN and bringing it right up and changing those table values. Too bad theres not a $?? for the L67.

Someone enlighten if you are supposed to convert those BIN files with a disassembler or shift the numbers around, or what is the first steps in resolving the issue with those?

Somewhere along the way you need a test bench, or a car with OBDII you dont mind possibly frying the PCM in. I am working on the test bench idea today since my only running OBDII is my 2003 truck.

So, it would be nice if we had a project manager to lay out the direction of what needs to be done in some order for the end result of being able to Flash Via the OBDII port.

Thanks and fill in what we need here guys.

Loyde

Arrgh, my spelling!!!!!!!!

[Lynoise]

Now theres DHP. They seem to flash with Tech 2's thorough the OBDII port.

I have been wondering how they do this. I was not sure if they used the Tech2 or some other hardware.

Then theres GM SPS software that definitely uploads to the PCM, but I have not seen anyone ever mention that the Tech 2 can download from the PCM.

As far as I know the Tech2 byitslef cannot download from the PCM. And SPS files are broken up into multiple files so its not a standard binary.

Then theres HyperTech. Now they can download from the PCM to the hand unit and change indivdual preferences on limited things. Now, are they changing a downloaded file and reuploading the file in the changed state?

I would LOVE to know the anser to this myself. If they download, edit, then upload or just upload a premade image.

Then there's the PCM questions. Does anyone have a schematic of the PCM for the L67? I am curious what all the chips are on the board.

Again I would LOVE to know this info... anybody?

The reason for the needing to know this is the Motorola docs indicate there is a BDM (background debugger mode) and you can tap into this and watch the code execution. Not sure what you would see, but I am curious what it looks like.

I have hooked into the BDM on the 68332 on my PCM (L36 and L67). The BDM allows you to do anything really. You can upload code to RAM and run it (Flash anyone). You can dump the Flash to a file (easily!).

Then theres the Tech 2. This I have read is called a ICE (In circuit emulator). Seems the Tech 2 is designed to take over the BDM and execute programs designed to Flash chips, change table parameters. Sounds like it does that very well.

How sure of this info are we? If the Tech2 is just a BDM interface (ICE) then we are golden . I have traced the pins needed for BDM on the PCM and it doesnt look like they go to the OBD2 port (I may be wrong though). I obviously have a BDM interface and if I could hook it up through OBD2 port I would be in heavan (no more soldering onto the CPU!)

Then there are those BIN files. What are you supposed to do with those besides Hex Workshop. I have looked at those Hex numbers enough to see that figuring tables there is a chore.

Yep its a PITA but needed cause those who know (DHP) are not willing to share the wealth on that info (understandably cause they have TONS of time into figureing them out [maybe... there are easier ways to figure them out.. but none of us work at GM ])

I see why TuneCat works so great now when it comes to downloading a BIN and bringing it right up and changing those table values. Too bad theres not a $?? for the L67.

As far as I know TunerCat is for OBD1 only.

Someone enlighten if you are supposed to convert those BIN files with a disassembler or shift the numbers around, or what is the first steps in resolving the issue with those?

There is no (cheap) disassembler out there (that I have found) that will work on the 68332. You just have to find the data you want to change and change it in the BIN. As for changing code (DHP does this I think) you need either a Disas. or the orig code from GM.... and a compiler that works (cant find one of those either).

Somewhere along the way you need a test bench, or a car with OBDII you dont mind possibly frying the PCM in

I had a test bench up and running but my power supply wasnt up to the task. I just swap out my PCM in my car with another one so I dont fry the one in it.

So, it would be nice if we had a project manager to lay out the direction of what needs to be done in some order for the end result of being able to Flash Via the OBDII port.

I think that was Magnus' idea with this board. If you think we need someone to take charge and control what is being worked on by others I think that should be taken up with the rest of the board. I think I agree with you but to what extent I am not sure. We definitely have a lot of brain power here but we are all working on our own little projects. We need some more organization to get things done.

Hope this helps.
-Mark j

[Lynoise]

Ohh and BTW right now I have no access to an OBD2 system... my car was wrecked about a month ago and havent gotten it back yet.

[FastFieros]

I was just rambling about the project manager deal. I see there are people that do hardware, people that do software. Which comes first?

Anyway, on the Tech 2 ICE to BDM. Here is what I have an understanding of. The BDM is indeed on board and usually is configured with 10 pins. It is my reading to understand that there is a chip on the PCM board that can stream the data both ways. So it is done on one serial line. That is why I wanted a chip layout of the PCM's to see what all these chips are and do. I have read so many PDF's with chip configurations to try and match them, but it appears Delphi is capable of producing some of there own chips and may have a bit steam flow control method that INtel and Motorola will not have documented. That will mean BDM access will have to be done at the CPU32 level. I have read the access for BDM is to be kept close to the CPU as possible.

>>>>>>>>>>>>&g t;>>>>>>>>>>>> >>>>>>
Here is a sample of the file I have. I will have to host the pics and tables on my website and link to them looks like..................................

Hardware and BDM Protocol
Motorola has defined a standard pinout for the debug connector, which is compatible with most of the development tools. Older versions have only eight pins and the newer ones add two additional pins for enforcing bus error and memory interface monitoring. Pins 2 to 10 of the new connector version are equivalent to the pins 1 to 8 of the older one.

Figure 1: Standard Ten Pin BDM Connector

Table 1 describes the function of these pins. Hardware dimensions of the connector are equivalent to the jumper array, which has 100 mils ( 2.54 mm ) spacing.

Pin Number Pin Name Description

1 DS Data strobe from target MCU. Not used in current interface circuitry
2 BERR Bus error input to target. Allows development system to force bus error when target MCU accesses invalid memory
3 VSS Ground reference from target
4 BKPT/DSCLK Breakpoint input to target in normal mode; development serial clock in BDM. Must be held low on rising edge of reset to enable BDM
5 VSS Ground reference from target
6 FREEZE Freeze signal from target. High level indicates that target is in BDM
7 RESET Reset signal to/from target. Must be held low to force hardware reset
8 IFETCH/DSI Used to track instruction pipe in normal mode. Serial data input to target MCU in BDM
9 VCC +5V supply from target. BDM interface circuit draws power from this supply and also monitors 'target powered/not powered' status
10 IPIPE/DSO Tracks instruction pipe in normal mode. Serial data output from target MCU in BDM


Table 1: 10 Pin BDM Connector Description

[FastFieros]

BDM uses 17 bit serial synchronous communication with the CPU32 processor. All data and command transfers are performed in an MSB first format. An internal CPU32 receiver is implemented by shift and latch registers. The CPU32 latches every input bit value on the DSI line at the time of rising edge detection of the DSCLK signal. Because of the DSCLK edge detection is performed synchronously with the system clock, the maximum DSCLK frequency is equal to one half of a system clock frequency. A 17 bit input word is latched after 17 rising edges on the DSCLK line then the CPU32 microcode sequencer is started to perform instruction or process extension words. Transmit latch register is updated by the CPU32 continuously. The transmit shift register and DSO pin reflect changes of the latch register until the first low level of 17 bit protocol is detected on the DSCLK line. Then the state of the DSO line can be read as a MSB received bit. Then the transmit shift register is not updated by the transmit latch register until all 17 bits are read. The DSO line is changed only after rising edges of the DSCLK line during the rest of transfer.

Figure 2: General CPU32 BDM Command Format

Command and data transfers initiated by the development system should clear bit 16. The current implementation ignores this bit; however, Motorola reserves the right to use this bit for future enhancements. The CPU32 returns 17 bit status or value every time 17 bits are send to it. The meaning of 17 bit status is described in Table 2. Some commands except the first command word need an additional address and data words. Figure 2 shows the general BDM instruction format without 16-th bit.



Bit 16 Data Message Type

0 xxxx Valid Data Transfer
0 FFFF Command Complete; Status OK
1 0000 Not Ready with Response; Come Again
1 0001 BERR Terminated Bus Cycle; Data Invalid
1 FFFF Illegal Command


Table 2: BDM Status or Values Returned by CPU32

Table 3 contains possible BDM commands for the CPU32 processors family. I have noticed, that the new ColdFire family processors use same basic command set with additional real-time commands. Changed RSREG and WSREG commands need to address more registers and that is why an additional register address word is necessary for these instructions. Another big change can be seen with ColdFire BDM cable, because of the ColdFire has single-stepping flip-flop built inside.

Command Mnemonic Code Additional Words and Notices

Read D/A Register RREG 218r receive two words with value from CPU32
Write D/A Register WREG 208r send two words with value to CPU32
Read System Register RSREG 258s receive two words with value from CPU32
Write System Register WSREG 248s send two words with value to CPU32
Read Memory Location READ 19tt send 2 word address and receive 1 or 2 words value
Write Memory Location WRITE 18tt send 2 word address and 1 or 2 words value
Dump Memory Block DUMP 1Dtt receive 1 or 2 words value from next memory location to location selected by previous READ command
Fill Memory Block FILL 1Ctt send 1 or 2 words value for next memory location to location selected by previous WRITE command
Resume Execution GO 0C00 Pipe is re-filed from RPC location
Patch User Code CALL 0800 Current program counter is stacked at the location of the current stack pointer and two additional words define subroutine start address
Reset Peripherals RST Asserts RST 0400 Asserts RESET for 512 clock cycles, but the CPU is not reset by this command
No Operation NOP 0000 NOP performs no operation and may be used as a null command


Table 3: CPU32 BDM Commands Summary

Table 4 describes the meanings of the last variable nibble or byte values in command codes.


Symbol Value Mnemonic Meaning

r 0 to 7 D0 to D7 Data Register
8 to F A0 to A7 Address Register

s 0 RPC Return Program Counter
points where execution will continue
1 PCC Current Instruction Program Counter
points to first byte of last executed instruction
it contains 00000001 when double bus fault
appears immediately after reset
8 ATEMP Temporary Register A
9 FAR Fault Address Register
A VBR Vector Base Register
B SR Status Register
C USP User Stack Pointer
D SSP Supervisor Stack Pointer
E SFC Source alternate function type of bus cycle
MOVES instruction and BDM memory transfers
F DFC Destination alternate function of bus cycle
MOVES instruction and BDM memory transfers

tt 00 BYTE 8 bit data in least significant byte of one word
40 WORD 16 bit data transferred in one word
80 LONG 32 bit data transferred in two words

[FastFieros]

If you want to read this whole doc it is located here....

http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html

Loyde