Page 6 of 34 FirstFirst 123456789101116 ... LastLast
Results 76 to 90 of 509

Thread: 1997 F-Body ECM

  1. #76
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    looks like great progress. For me, I have set the download aside for a bit. I have run into problems with understanding the queue of messages. In code from the '97 processor there is a scheme for some sort of FIFO. This lets reply from requests complete before working through the next request. I believe it is in that code where problems exist for me. It looks like one location is in normal circumstances set to $0. When a reply to a request is lengthy, one reply is sent out each time the subroutine is called. This takes place until the request has been serviced.
    This is also the code that looks after Mode $34 commands. It seems like mode $34 requests to the Tside do not set this location and thus will not process $36 command. When I figure it out, I will describe for the forum.

    In order to figure it out I have disassembled the Mode $19 command. It makes use of this extended service location. I have completed this now but need to go back and look at the service code that parses commands from the DLC.

    Great to see your progress!!
    Cheers,
    -Tom

    PS - Does anyone have information on Mode $19 ? I thought it would be part of SAE J2190 but is not listed there. Mode $18 is listed there and they seem very similar! What am I missing here?
    Last edited by Tom H; 05-01-2019 at 05:53 PM.

  2. #77
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Mode $19 is "Read DTC Information", so it should return status of every specified DTC. I'm not sure exactly...

    I've made a huge progress last couple of days! E-side SPI comms are finally working and I have working T-side and E-side read software!


  3. #78
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    First off Congratz dzidaV8. Fantastic that you have the download/upload solved!!

    I was asking after Mode 19 because IF it is similar to Mode 18, a whole bunch of memory locations can be identified. There are a number of tables for DTCs that try to classify the use. J2190 calls them up for mode 18 as follows:

    bit 7 Warning lamp illuminated for this code
    bit 6 Warning lamp pending for this code, not illuminate but malfunction was detected
    bit 5 Warning lamp was previously illuminated for this code, malfunction notcurrently detected, code not yet erased
    bit 4 Stored trouble code
    bit 3 Manufacturer specific status
    bit 2 Manufacturer specific status
    bit 1 Current code - present at time of request
    bit 0 Maturing/intermittent code - insufficient data to consider as a malfunction

    If I can say for sure that the status is the same for Mode 18 and 19, the definition of 144 bits become determined. I can't find any definition of Mode $19 and think it may be a GM special/non-standard. I have disassembled and commented the code to the point where this all is taking shape. Just don't know the intent of the code completely.

    -Tom

  4. #79
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I had a close look at Mode 3C used to read various parameters from the PCM including VIN...

    MODE $3C

    Mode $3C is loosely defined in SAE J2190. In my PCM (calibration #?16236217?) the request looks as follows:

    H0 H1 H2 MODE BLOCK# <CRC>

    Header 0: Priority: Any, Three byte consolidated header, IFR not allowd, Physical addressing, Node to Node
    Header 1: Target address or destination can be $10 (engine controller) or $FE (all nodes)
    Header 2: Source address should be one of the off board tester/diagnostic tool addresses.

    For testing I have used $4C $10 $F0 for header values. The Mode I am looking at is $3C.

    Supported block numbers are:
    $01 through $08, $0A, $0B, $40 through $49, $A0

    The data associated with each of the blocks is returned based on a look up table.

    TSIDE
    Block# Start Data Content
    Address Length

    $01 $0E24 $06 VIN BLOCK 1
    $02 $0E29 $06 VIN BLOCK 2
    $03 $0E2F $06 VIN BLOCK 3
    $04 $0E04 $04 VIN BLOCK 4
    $05 $0E08 $04 VIN BLOCK 5
    $06 $0E0C $04 VIN BLOCK 6
    $07 $0E10 $04 VIN BLOCK 7
    $08 $0E20 $04 VIN BLOCK 8
    $0A $2000 $04 Calibration Number (binary)
    $0B $0262 $04
    $A0 $0E35 $01

    ESIDE moved by SPI to Tside RAM
    Block# Start Data Content
    Address Length

    $40 $182A $02
    $41 $182C $06
    $42 $1832 $06
    $43 $1838 $05
    $44 $183D $06
    $45 $1843 $06
    $46 $1849 $05
    $47 $184E $06
    $48 $1854 $06
    $49 $185A $05

    One interesting note...
    Block $01 is special in that while the LUT calls for 6 bytes of VIN info to be sent there is a special branch for this block only. Block 1 sends the first data as $00 in all cases, followed by the five bytes starting at EEPROM $0E24. It is not clear to me why things were done in this way.

    I wonder if a complete map of EEPROM content is available somewhere?

    There are 512 bytes of EEPROM in each of the Tside and Eside processors. Has anyone looked into the use of all this?

    -Tom

  5. #80
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Hi Tom

    Did you made any recent progress with the disassmebly?

    I have a simple question for your hardware skills.

    On eside the main routine that runs the engine is IRQ. Do you know at what rate it runs and what triggers it. Is it some external timer or it is trigger by some opti signal interrupt. It is also intersesting to find the same info for other routines but that one is the most of interest.

  6. #81
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi Kur4o

    I am making progress on the Tside code. I lack knowledge about a number of things
    that slows me down, but I am working away at it. I need to find out more about
    built in testing. I see references to balance test and others. Work goes on. I
    have not posted in a long while and need to get back to that.

    I have not yet done a dive into the Eside hardware. I will get back to you in a
    couple of weeks with info on what is driving the IRQ pin, and other stuff I
    find along the way. Time to clean up my work bench & ...

    -Tom

  7. #82
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi Kur4o,

    Had an initial look at your Q... The IRQ is pin 19 on the processor. It tracks to a pull up resistor on the underside and then to the gate array that we have little info on. The gate array house number 16195392 is in a PLCC68 package, IRQ is on
    Pin 47.

    I will have a better look at this and let you know. I plan to look through the opti connections.
    Later I will get round to connecting my opti spark emulator and see the function of the pin on the scope. Probably winter though.

    Post a bit more on this soon.

    -Tom

  8. #83
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    Great find.

    I suspect it can be driven on a fixed interval rate or some trigger event like opti low pulse signal.

    I don`t have enough knowledge on the hardware and processor speed, but how much time it will take for the processor to execute the irq subroutine. I noticed that above 3-4000 rpm some code is omited based on the cyl id. For example each #8 cylinder is fired the ve and spark tables are not refreshed. It is scattered around the code based on different cylinders. It could be the processor is slow enough.

    It also doesn`t like jumps out of the routine and turns to crap if a try to add aldl interupts. I guess it is critical time sensitive.

  9. #84
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Looking through the high res side, it is received by a quad comparator with feedback hysteresis. Signal then hits a 28pin plcc that I have no knowledge of. That part is marked 609-3700521 symbios. This could ?? be a PLL of some sort. I see diodes and a R/C network with a ground island around it.
    With a scope, we should see an inverted hi res signal on pin 4. Interesting to look at what the rest of the part does with the signal. At first I thought it was some sort of buffer, but symbios was never into that sort of simple logic.
    -Tom

  10. #85
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Quote Originally Posted by kur4o View Post
    Hi Tom

    Did you made any recent progress with the disassmebly?

    I have a simple question for your hardware skills.

    On eside the main routine that runs the engine is IRQ. Do you know at what rate it runs and what triggers it. Is it some external timer or it is trigger by some opti signal interrupt. It is also intersesting to find the same info for other routines but that one is the most of interest.
    The IRQ seems to be triggered every low resolution opti pulse, I'd have to trace the PCB but my guess is that IRQ pin is driven by TPU chip.

  11. #86
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    VATS

    In looking at distributor inputs, I am now convinced the Timer Processor Unit (TPU) is involved. That needs to be figured out to have any hope of understanding the heart of the system. The injector timing and spark timing are complex. Also the transmission monitoring is complex. I needed a simple place to start figuring the part out.

    In looking through the ESide code, I believe the VATS to be a simple function. From what I see, PCM Connector C1 (RED) pin 25 (BLUE wire) takes a toggle signal from the BCM. The ESide routine that monitors the toggle rate runs at 12.5mS intervals --> 80 times a second. The code tests a register in the TPU against the sample taken in the previous run 12.5mS earlier. In case where there is at least some transitions on the line, it tests the rate. Two thresholds for rate are set in the calibration:

    -CALIBRATION: $05B0 1456
    -CALIBRATION: $04A8 1192

    These may be specific to year/make/model, the above is what I have. All this suggests the nominal frequency sent by the BCM is 50HZ with the right key resistor in place.

    The result of all this is a couple of flags are set when the right frequency is sensed.

    One is used on the ESide to handle things like dtcs: -DTC P1626: PASS KEY FUEL ENABLE CIRCUIT CLEAR FLAG
    and cut off of fuel pump / injectors.

    The other is sent to TSide through the SPI byte 3, bit2.

    SPI ESide E_Xfr T_Xfr TSide
    BYTE03 $005E $0098 $02F3 $00AE

    BIT 0 DTC P0200: INJECTOR CIRCUIT CLEAR FLAG
    BIT 1 DTC P0200: INJECTOR CIRCUIT SET FLAG
    BIT 2 VATS FUEL ENABLE FLAG
    BIT 3 DTC P1222: INJECTOR CONTROL CIRCUIT INTERMITTENT CLEAR FLAG
    BIT 4 DTC P1222: INJECTOR CONTROL CIRCUIT INTERMITTENT SET FLAG
    BIT 5
    BIT 6
    BIT 7 ESIDE MIL REQUEST FLAG


    A Mode $23 command can be sent to read the VATS status. There are probably a bunch of other ways to do this, I only needed 1 to prove things out.

    Using an ELM327 for access I sent "23 00 00 AE 01". This is with the header pre-set to "4C 10 F0"
    The ECM responds with header: 4C F0 10 message:63 00 AE 04 00 00 00 crc: F8

    The way I believe this part of the TCU works is:

    CPU runs an oscillator at 12.5829mhz. The E clock is a divide by four 3.145725mhz. This is divided in the TPU by 48 resulting in a sample clock at 65,536hz. A nominal 50hz input will result in a count of 1310 or so. If I am correct in my assumptions, the threshold 1192 would give a top acceptable frequency of just under 55hz. Similarly, the threshold 1456 would give a bottom acceptable frequency of just over 45hz.

    The tpu it's self operates similar to the 'hc11 input capture timers. One edge (perhaps the rising edge say) latches the count. The software subtracts the previous value and tests against the threshold.

    =======================
    Some questions for you all...
    - Are all the functions of the TPU documented somewhere? If I knew all the things it does it would be a good help
    - Are the connections to the TPU documented somewhere? Looking at the connected pins would help with the first Q

    Speculation
    - I think the 8bit read followed by a 16 bit read solved a problem of synchronizing between high and low bytes. The first read 8bit latches the value. The second read results in reading high first then low, like a normal 16 operation in an hc11. I expect address 0 is not even connected to the part. I plan to test for this.

    =======================
    VATS code segment

    \
    Code:
    VATS code segment
    
    4B6C  B6 14 6A    	LDAA   $146A		; READ TPU REGISTER
    4B6F  FC 14 6A    	LDD    $146A		; 
    
    4B72  0E          	CLI			; ENABLE INTERRUPTS
    
    4B73  37          	PSHB			; STACK TRANSITION COUNT LS
    4B74  36          	PSHA			; STACK TRANSITION COUNT MS
    4B75  B3 02 24    	SUBD   $0224		; SUBTRACT PREVIOUS COUNT FROM CURRENT
    4B78  38          	PULX			; TRANSITIONS SINCE LAST TEST
    4B79  27 15       	BEQ    $4B90		; NO TRANSITIONS
    
    4B7B  FF 02 24    	STX    $0224		; UPDATE PREVIOUS TRANSITION COUNT
    
    4B7E  1A B3 20 23 	CPD    $2023		; CALIBRATION: $05B0 1456 45HZ
    4B82  22 0C       	BHI    $4B90		; 
    
    4B84  1A B3 20 25 	CPD    $2025		; CALIBRATION: $04A8 1192 55HZ
    4B88  25 06       	BCS    $4B90		; 
    
    4B8A  14 01 80    	BSET   @$01,$80		; VATS ENABLE FUEL FLAG
    4B8D  14 5E 04    	BSET   @$5E,$04		; SPI VATS ENABLE FUEL FLAG

  12. #87
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477

    TPU / TIO

    I continue to look at the "TPU" as it appears to be where most if not all of the time sensitive engine controls take place. I began by looking at it's initialization. The manner that it is initialized is the same in code for 1994 through 1997.

    I believe the "TPU" is described in a Delco patent. Delco describes the part as a microprogrammed timer processor but throughout the text refer to it as TIO. You can view the patent at: https://www.lens.org/lens/patent/089-678-009-223-680 for confirmation the Patent Numbers: 5,115,513 and/or 5,117,387. They both look to me as the same idea...

    The reason I believe this describes the part used in LT1 based vehicles is the description given in "PREFERRED EMBODIMENT" and "Architectural Overview" sections. The following is what I believe and will now seek to confirm. The following details suggest to me that the patent documents the 16195392 / TIO part.

    - The size of the microcode store is the same between the patent and the TIO part. The given size is 256 words of 64 bits. The patent states: The microcode store is preferably in the form of a ROM although RAM or other memory technology can be used instead. The TIO uses RAM and configures it with the following sequence:

    The microcode is loaded sequentially through four registers at $16E0, $16E2, $16E4, $16E6. Once four words are written, the destination microcode address is written to $1400. This initiates loading of the microcode word into RAM. The above loops through the 256 sixty-four bit words to complete loading the microcode.
    The size of both the TIO shared RAM blocks exactly matches the patent. In the patent the combination of both blocks is referred to as "Parameter RAM" comprised of "Temporary RAM" and "Shared RAM". Patent sizes the shared RAM at 128 words by 16 bits and the temporary RAM at 64 words by 16 bits.

    The code in the LT1 computers clears both shared and temporary RAM, the sizes match the patent exactly.


    In reviewing the code, the patent, the application and what I know of the system, I come to the conclusion that the TIO is described by this patent.

    I am most interested to hear if others agree or disagree and if anyone has found a match between the list of fields and the microcode loaded in the software. Here is the list of fields given in the patent:

    P2A (9) Parameter to A bus
    T2B (7) Temporary to B bus
    SUB (1) Subtract/Add
    SHC (2) Shift control
    PWR (9) Parameter Write address
    PWU (1) Write Unconditional
    EXC (4) Execute (Branch) Condition
    PNS (6) Pin/Flag Select
    PAC (2) Pin Action Control
    ENA/DIS (2) Enable/Disable
    PRB (1) Present/Requested bit
    REQ (6) Requested Address and/or Request Flag
    DEC/END (2) Decrement/END Register
    NAP (8) Next Address Pointer
    NIP (4) Next Index Pointer

    I am not sure which fields are assigned to which bits. I am trying to analyze that now.

    Also there is the question of how the sequence of bytes the software loads are formed into words. Here is what I think:
    Stated in the patent & makes sense from a 68HC11 point of view:

    Byte0 Byte1:Byte0
    Byte1
    Byte2 Byte3:Byte 2
    Byte3
    Byte4 Byte5:Byte4
    Byte5
    Byte6 Byte7:Byte6
    Byte7


    This could result in the microcode loading into a 64bit word as:
    Alternative 1 Byte7:Byte6:Byte5:Byte4:Byte3:Byte2:Byte1:Byte0

    Should the design be consistant with writing high order first:
    Alternative 2 Byte1:Byte0:Byte3:Byte2:Byte5:Byte4:Byte7:Byte6

    Consider that the word high order first statement in the patent
    doesn't apply to microcode loading:
    Alternative 3 Byte0:Byte1:Byte2:Byte3:Byte4:Byte5:Byte6:Byte7


    I have written a number of C classes to help with the analysis but as yet I can't determine the placement of fields within the microcode or the order that the byte sequence is loaded into the 64bit word. I will keep plugging away at this.

    -Tom

  13. #88
    Fuel Injected! vilefly's Avatar
    Join Date
    Sep 2017
    Age
    53
    Posts
    217

    Always wanted to know the strategy behind the optispark......this is facinating stuff.

  14. #89
    LT1 specialist steveo's Avatar
    Join Date
    Aug 2013
    Posts
    4,007
    this is brilliant research and i'm very impressed. i love that after all these years these ol' LT1 ecms are still being researched. i did always think there was a timing unit in place that i didn't understand. please don't stop

  15. #90
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I am glad folks are interested in this... I would like to get it all figured out if I can.

    I did some more looking through initialization of the TIO. First the microcode is initialized, then the temporary ram and last the shared ram. The new thing I notice is the next block to initialize is the exact size of the pointer table ram outlined in the patent and referred to as pointer table ram. PTRAM is made with 40 words of 12 bits. The PCM table in flash is 40 words by 16bit however, the MS digit is always zero suggesting that only 12 bits are of use.

    With this, I have almost enough to simulate the operation IF i can figure out the order bytes are loaded into the microcode. Writing a simulator will take a bit of time. I spent very little time working with DSPs but the flow and the techniques used by this part are quite similar. Main difference is this is all timer oriented and not a/d d/a oriented.

    I will continue to post but it will take a bit of time to grind through all the details.

    If anyone has any info on this part it will be a great help.

    -Tom

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
  •