Page 8 of 34 FirstFirst ... 34567891011121318 ... LastLast
Results 106 to 120 of 509

Thread: 1997 F-Body ECM

  1. #106
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi,

    I got side tracked on some engine math that might be of general interest. Probably somewhat specific to my PCM but I expect this will be done in similar ways in other PCMs. This is my just my understanding and if you find errors or can jump in with a better explanation, please do!

    I got looking at the TPU chip and the math behind the computer measuring engine speed. I believe that $1482 in the TPU is updated each low resolution pulse with a count of prescaled clocks that happen between low res pulses. This is a function of the TPU and may be different depending on the loaded microcode but I suspect it is the same for all LT1s.

    Since low res pulses happen four times per revolution, 15RPM would represent 1 fire event per second. The TPU clock is based on the CPU E clock. The CPU crystal frequency is 12.5829MHZ, Eclock is a divide by four function resulting in the frequency of Eclock being 3,145,725HZ. My understanding of the TPU is that the clock counted in Location $1482 is a prescale of Eclock with a divide by 48 circuit. This clock frequency is 65535.9375 which we can round up to 2^16. I note that this is the same frequency used by the VATs I wrote about a week or so back.

    The software uses the count to arrive at various "divide by n" RPM numbers. Various scales are used depending on the purpose. The intent is to have the scale fit the lookup table and RPM range as needed.

    In my Eside half of the PCM I see a good number of scaled RPM variables are used. In my case I see:
    RPM/5
    RPM/6
    RPM/8
    RPM/25
    RPM/62.5
    RPM/500

    The variable used to generate each of the scale factors is generated using the 15RPM constant that results in 1 ignition per second. Divide that by the desired scale, then multiply by 512. Examples...

    Scale 15/Scale Variable/Denominator
    5 3 1536
    6 2.5 1280
    8 1.875 960
    25 0.6 307.2
    62.5 0.24 122.88
    500 0.03 15.36

    The Tside has similar code. The variables differ because the prescale is no the same in the timer inside the CPU.
    My Eside code uses various scaled counts and also uses the TPU count directly for various (yet unknown to me) functions. With this I now have hundreds of places where scaled RPM is used.

    -Tom

  2. #107
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I believe that $1482 in the TPU is updated each low resolution pulse with a count of prescaled clocks that happen between low res pulses.
    That`s the part that I have missed for a long time. Now it is all clear. It also corresponds with what`s already known as a scalars for low res signals. The tpu cycles each 0.015234ms which equals to 65642 samples per second. Pretty close to your math which might be even more accurate.

    The scaled rpms are similar accross most of the same years, processor PCM. It must be some universal conversion from time to rpm.

    Tside samples low res signal straight from ??[IC3I interrupts] at 0.00507ms per cycle or 196607.8125 samples per second.
    I wonder why GM slashled the samples per eside. The low res signal in the logs is derived from tside calculations and is very hairy and jumpy. That might be the reason for slash more stable readings at higher rpms.

    On a side note, Is there a dedicated chip on 96-97 pcm that drives the ICM and coil. Dis you managed to trace that part.
    I also ripped some knock modules of different years, engines and most looks almost identical. The `00 blackbox pcm have the an extra 8 pin chip that is missing in earlier applications. I will try to compile some pics for comparison.

  3. #108
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by kur4o View Post
    On a side note, Is there a dedicated chip on 96-97 pcm that drives the ICM and coil. Dis you managed to trace that part.
    I also ripped some knock modules of different years, engines and most looks almost identical. The `00 blackbox pcm have the an extra 8 pin chip that is missing in earlier applications. I will try to compile some pics for comparison.
    I will take a look at the ignition chip soon but...

    For just now, I am focused on the TIO part, trying to decode the microcode. It is the heart of this PCM and without understanding it everything done is trial and error. What would I give for a datasheet?

    Another TIO address... $14D6/7

    PARAMETER VALID FLAGS | ENABLED INJECTORS
    BIT 0001 INJECTOR 0 ENABLE
    BIT 0002 INJECTOR 1 ENABLE
    BIT 0004 INJECTOR 2 ENABLE
    BIT 0008 INJECTOR 3 ENABLE
    BIT 0010 INJECTOR 4 ENABLE
    BIT 0020 INJECTOR 5 ENABLE
    BIT 0040 INJECTOR 6 ENABLE
    BIT 0080 INJECTOR 7 ENABLE
    BIT 0100 NOT USED
    BIT 0200 NOT USED
    BIT 0400 NOT USED
    BIT 0800 NOT USED
    BIT 1000 NOT USED
    BIT 2000 BAROMETRIC PRESSURE VALID
    BIT 4000 ENGINE COOLANT TEMPERATURE (ECT) VALID
    BIT 8000 SOME_PARAMETER VALID

    Does this match with your understanding? Can you tell us what "SOME_PARAMETER VALID" actually is??

    -Tom

    PS: The order of the injectors may not be correct. Could follow fire order or not.

  4. #109
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Sounds like you're on a good path to figuring out the TPU!
    Here's my disassembly of E and T sides with your info added.

    I'm working on Ghidra 68HC11 implementation so we could transfer the work to Ghidra and work on it together.
    Attached Files Attached Files

  5. #110
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Quote Originally Posted by dzidaV8 View Post
    Sounds like you're on a good path to figuring out the TPU!
    Here's my disassembly of E and T sides with your info added.

    I'm working on Ghidra 68HC11 implementation so we could transfer the work to Ghidra and work on it together.
    Thank you for sending along the LT4 info, there are a bunch of things that are new to me and I have only seen 1% of it so far. -Thank you

    I need to look into Ghidra and find out what it is. So far I have only worked with tools I wrote. I have looked at IDA a little but have not yet ported my info into that too. My own tool set is very basic and simple W lots of head bashing. It would be good to transfer all the details into some sort of tool that would be of use to others.

  6. #111
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    I have put some effort into the timer chip since my last post. Trying to figure out the architecture from the assumed function and the microcode is not a easy path. That said, I have perhaps made some discoveries that may be of help.

    I will go over what I think I know first, then describe how far I have got. I do hope this isn't just a time sink.

    ========
    The timer and microcode for it exist on the ESide and in the ESide FLASH
    The timer microcode is loaded using the following sequence:
    - Hardware reset to the timer
    - Configure timer for loading microcode $16F0 <-- $03
    - Load one 64b microcode word, 16b at a time
    $16E0 <-- part ? of word
    $16E2 <-- part ? of word
    $16E4 <-- part ? of word
    $16E6 <-- part ? of word
    - Complete the loading by writing the address into $1400 (lower 8b are address)

    I assume that the load registers $16E0-6 represent one 64b entry in the microcode store. I suggest this because looking at the code my PCM uses, I find an area that is filled with zeros. From the patent document, there is a suggestion that no-ops are used in certain places. I believe that often zeros are used for no-op.

    There is a block of 17 microcode words that contain all zeros. This block begins on a 64b boundary, so I believe that is also the boundary for each microcode. Can't yet prove it, but I believe it. If designing a part like this, it's a straight forward way to complete the loading.

    Moving on (if you accept that all...), my next question is "which part of the word does each of the registers represent?". There are a good many ways this could be done but:
    - The microcode is loaded 16b at a time. Convention places the high order first in a 16b write.
    - Following convention would load bits
    63-56 : 55-48 from the first word of the table
    47-40 : 39-32 from the 2nd
    31-24 : 23-16 from the 3rd
    15-08 : 07-00 from the 4th

    Another way that *could* make sense reverses the registers
    15-08 : 07-00 from the first word of the table
    31-24 : 23-16 2nd
    47-40 : 39-32 3rd
    63-56 : 55-48 4th

    I wrote some programs to try and analyze. In one program I try configuring an array of 256 microcode words each four ways I thought might represent the loading architecture. The problem is how to assess which might be correct. My thinking went like this...

    - In all cases, you might expect that a register the CPU reads would be written internally by the timer.
    - One exception to the above is if the CPU reads, modifies and writes status bits. This is done in some places.
    - I believe internally, all the addressing is 16bit. All timers and parameters are 16b. Patent confirms.
    - I expect that the PWR field will exist for every register that the CPU only reads.

    So far I have found a field that contains each of the written registers. This suggests that that field contains the PWR bits from the patent. It does not firm up which way the microcode is loaded though because the load order only affects a sequence that crosses a 16b boundary. I have found the match in different load orders.

    =========
    My plan is to continue as far as I can with this analysis and eventually execute test code on the ESide to confirm. I will update if/when there is progress.

    -Tom

  7. #112
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    This file might be of use... Indicates accesses to the TPU. Missing could be accesses using indirection.



    TPU_Access.pdf

    -Tom

  8. #113
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    The later CPU32 Motorola chips might be helpful in figuring the LT1 TPU out. They have integrated TPU on a FPGA matrix that can also be custom microcode programmed.
    Have a look at the documentation:
    https://www.nxp.com/docs/en/applicat...te/TPUPN00.pdf
    https://www.nxp.com/docs/en/reference-manual/TPURM.pdf

  9. #114
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi,

    dzidaV8, Thank you for your suggestions and links. The way I have been looking at the TPU has not been a success. I have written several pounds of code to look at the microstore in different ways. Even found fields within the code that address each of the two port ram locations I expect to be written by TPU. So far things have not fallen into place. Too much time spent for no result. kur4o had suggested that there might be a great number of versions with major differences... he is right.

    What I have found though...

    In the '97 version of tpu, address $16F4 is an interrupt status register on read and a clear interrupt on write. There are four active bits (mask $3C00) I have yet to identify the cause each bit represents. The service is quite easy to find though and I am still going through the code.

    Also, The NXP documents you refer to suggest that the top 16 locations of the microstore are entry points. This looks like a match with the microcode in my flash. I say this because there is a large section of NOPs between what I think is code and the last 16 entries.

    All the best for the new year to all! I will post from time to time when I come up with results.

    Cheers,
    -Tom

  10. #115
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    I think the tpu used is some form of 68hc11 processor with hardcoded rom. The data the main processor writes at reset is some form of configurations or options.
    If the TPU is preset for different engines, you can change the presets for cylinder numbers, crank signal, ignition and injectors output and so on.

    I suspect the code it runs is the built in timers in 68hc11
    Code:
    FSR:100E                                         ; Timer Counter Register (High)
    FSR:100E                                         ; mph PULSE
    FSR:100F TCNTL:          fcb   0                 ; Timer Counter Register (Low)
    FSR:1010 TIC1H:          fcb   0                 ; Input Capture 1 Register (High)
    FSR:1011 TIC1L:          fcb   0                 ; Input Capture 1 Register (Low)
    FSR:1012 TIC2H:          fcb   0                 ; Input Capture 2 Register (High)
    FSR:1013 TIC2L:          fcb   0                 ; Input Capture 2 Register (Low)
    FSR:1014 TIC3H:          fcb 0                   ; DATA XREF: IC3I+6r
    FSR:1014                                         ; Input Capture 3 Register (High)
    FSR:1014                                         ; cRANK PULSE SIGNAL
    FSR:1015 TIC3L:          fcb   0                 ; Input Capture 3 Register (Low)
    FSR:1016 TOC1H:          fcb   0                 ; Output Compare 1 Register (High)
    FSR:1017 TOC1L:          fcb   0                 ; Output Compare 1 Register (Low)
    FSR:1018 TOC2H:          fcb   0                 ; Output Compare 2 Register (High)
    FSR:1019 TOC2L:          fcb   0                 ; Output Compare 2 Register (Low)
    FSR:101A TOC3H:          fcb   0                 ; Output Compare 3 Register (High)
    FSR:101B TOC3L:          fcb   0                 ; Output Compare 3 Register (Low)
    FSR:101C TOC4H:          fcb   0                 ; Output Compare 4 Register (High)
    FSR:101D TOC4L:          fcb   0                 ; Output Compare 4 Register (Low)
    FSR:101E TCO5H:          fcb   0                 ; Output Compare 5 Register (High)
    FSR:101F TCO5L:          fcb   0                 ; Output Compare 5 Register (Low)
    FSR:1020 TCTL1:          fcb 0                   ; DATA XREF: sub_B9F2+A6r
    FSR:1020                                         ; sub_B9F2+ABw ...
    FSR:1020                                         ; Timer Control Register 1
    FSR:1021 TCTL2:          fcb   0                 ; Timer Control Register 2
    FSR:1022 TMSK1:          fcb 0                   ; DATA XREF: COMM_ROUT_sub_C75A+BF2w
    FSR:1022                                         ; __RESET-EFAw
    FSR:1022                                         ; Timer Interrupt Mask Register 1
    FSR:1023 TFLG1:          fcb 0                   ; DATA XREF: IC3I+3w
    FSR:1023                                         ; Timer Interrupt Flag Register 1
    FSR:1024 TMSK2:          fcb 0                   ; DATA XREF: COMM_ROUT_sub_C75A+BF5r
    FSR:1024                                         ; COMM_ROUT_sub_C75A+BFAw
    FSR:1024                                         ; Timer Interrupt Mask Register 2
    FSR:1025 TFLG2:          fcb   0                 ; Timer Interrupt Flag Register 2
    FSR:1026 PACTL:          fcb   0                 ; Pulse Accumulator Control Register
    FSR:1027 PACNT:          fcb 0                   ; DATA XREF: IC3I+9r IC3I+Cw
    FSR:1027                                         ; Pulse Accumulator Count Register
    A real mess to decipher.

    I found an analog for the philips knock chip, it is labelled
    014
    p57br
    45153
    It is used along with the philips chip on the same pcm.

  11. #116
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi,

    I am a bit of a skeptic re 'HC11 core. All the external registers, two port ram and so on are 16 bit. IF it is a standard micro core, I would expect an HC16 or??.

    I still think the load sequence is set up for a 64 bit word & looks to me more like what a sequencer or dsp microcode would be. I will keep plugging on it for a while, but at some point will need to accept that there isn't enough info to figure the TPU out. This would be a sad end to a long project.

    I still have a number of things to try, including loading test code into the Eside and working the timer that way.

    -Tom

  12. #117
    Fuel Injected!
    Join Date
    Jan 2012
    Location
    Poland
    Posts
    147
    Another interesting read about TPU: http://www.eslave.net/tpu/pdf/TPUMASMREF_D3.pdf
    I think it's quite possible that the chip used in LT1 PCM is what was later integrated in CPU32 and HC16 microprocessors. I highly doubt that there's a HC11 core in there.

  13. #118
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    1,470
    D84G appears in another diesel PCM which also use optical sensor similar to the optispark. I am suspecting the chip is some kind of special motorola production made specifically to work with the opti signal. By the mask you can tell for sure it is motorola unit. It is very likely to have an internal rom, due to different mapping addresses being used. And can do more than just basic calculations.

    Here is the thread that describes the diesel pcmhttps://pcmhacking.net/forums/viewtopic.php?f=8&t=4671

    Some other techniques to try. Dumping the shared memory range can give some insights. In the above thread there is some UART reading with prog11.exe.
    If we can suggest it is a HC11 core and have a UART pin you can give it a try.

  14. #119
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    This D84G chip would seem to me to be most like the patent, with a little of the '302 chip and perhaps a simpler core. I have exhausted myself trying to fit the "microcode" from my bin into the format given in the patent. Just not the same beast. The data paths in the part are all 16b (I am sure), perhaps what I thought was microcode is in fact instructions, executed by the internal core with a rom based microcode. In looking at the TPU dsidaV8 is proposing as a base, there is a library for that part which includes all sorts of common things like multiplication, testing pins and so on. I will do some more reading there.

    I have separated my test boards because the ribbon cable broke. I replaced the connectors with .025sq pins such that I can plug them together. For now, I am looking at the ESide and find that it should be easy to put the part into bootstrap mode. The UART signals come right to the header. With this done, I can download code to ram and execute. This should help me test ideas. I have already written and tested code for bootstrap mode when I wrote the Opti simulator. (gathering dust, still not tried).

    I am sure looking at all the work you folks have done (very impressed!) that you have a very good feel for the D84G chip function. I wrote this down to try to keep details straight. Perhaps others could add/correct my assumptions here... I feel perhaps I missed a bunch of things.

    Code:
    Analysis				
    				
    Timer/engine synchronization				
    	Inputs			
    		Pins		
    			High resolution signal (Opti)	
    			Low resolution signal (Opti)	
    		Registers		
    			Firing cylinder	
    			Other variables	
    			Other constants	
    	Outputs			
    		Pins		
    			Interrupts	
    		Registers		
    			Counts of high and low resolution signals	
    			Interrupt acknowledge	
    				
    Fuel injection				
    	Inputs			
    		Registers		
    			Start of injection	
    			End of injection	
    			Timer/engine synchronization flag	
    			Correction: Accumulated fuel	
    			Corrections: Other	
    			Corrections valid flag(s)	
    			Service: disable/pulse injector	
    			Other variables	
    			Other constants	
    	Outputs			
    		Pins		
    			Injector drivers	
    Spark				
    	Inputs			
    		Registers		
    			Timing	
    				Spark advance
    				Advance correction (asr, knock ...)
    			Dwell	
    				Dwell time
    				Fault detection: count of spark events
    	Outputs			
    		Pins		
    			Ignition driver	
    Knock				
    	Inputs			
    		Pins		
    			Knock sensor/filter input	
    	Outputs			
    		Registers		
    			Knock count	
    				
    				
    Vehicle Anti-Theft System				
    	Inputs			
    		Pins		
    			VATS input signal	
    	Outputs			
    		Registers		
    			Transition count	
    				
    Mass Air Flow				
    	Inputs			
    		Pins		
    			MAF input signal	
    	Outputs			
    		Registers		
    			Transition count	
    				
    Vehicle Speed				
    	Inputs			
    		Pins		
    			VSS input signal	
    	Outputs			
    		Registers		
    			Transition count
    -Tom

  15. #120
    Fuel Injected!
    Join Date
    Jan 2019
    Location
    Canada
    Posts
    477
    Hi,

    I do hope we can get an understanding of the TPU... Perhaps some group think is in order. Let's discuss a few ideas. Here is what I came up with.

    Recap:
    - There is a section of code that loads 2048 bytes into a multiplexed internal RAM.
    - The loader writes this section into the TPU as 1024 words.
    - The loader writes four 16bit words and then increments an address pointer.
    - I believe the section is written/used as two hundred and fifty six 64bit words.
    * See the code below

    I decided to try and validate my assumption by looking at the words to see if they are duplicated and at what interval. I decided to exclude the word 0x0000 because often times this is used as a default/null word. NoOps will often default to 0x0000 and zero all the other fields. My results exclude this.

    In the case where the store is 16bit, I would expect to see duplication of the word be evenly spread over each word in the store. This is not what I found. In fact looking at the store as an array of 64bit words, each of the columns that represent bits 48:63 has only 66 unique codes. Codes within this column are duplicated 160 times (again excluding 0x0000). This contrasts with duplication in the other three columns of words which result in duplication 0, 1 and 3 times.

    I then looked at the second column: bits 32:47. Here there are 217 unique codes. Once again, the duplication of codes in other columns was very low: 0, 5 and 6.

    For bits 16:31, there were 115 unique codes and duplication in other columns: 2, 5 and 0

    Last up bits 0:15, there were 124 unique codes. Duplication in other columns: 2, 22 and 27

    ===========
    My thinking is that given that all the data paths in the TPU are 16 bit, there would be no reason to code the processor section with less. That is to say, I excluded 8 bit by inspection. This is not solid, just from what I see.

    IF this storage was 16 bit based, I would expect to see and even duplication within all the 16bit fields. What I see is heavily weighted to modulo 4. When the storage is arranged as four columns of 16bit, each column has a great probability of a duplication within the column and a great probability of not matching other columns.

    My look into the TPU thus far suggests that it does not match the pattent I brought up earlier BUT does have a lot of similarities to it. All the storage sizes match and the general working matches. Once again I guess that the idea for this pattent came from this part. Perhaps it is a single processor version and that the idea for the pattent was to eliminate some of the latency of this part (?)

    ===========
    Very interested in your views.

    -Tom


    Code:
    * INITIALIZE THE MICROSTORE
    A4BE  4F          	CLRA			; SET FOR LOADING THE MICROSTORE
    A4BF  C6 03       	LDAB   #$03		; 
    A4C1  FD 16 F0    	STD    $16F0		; 
    
    A4C4  CE A8 7C    	LDX    #$A87C		; MICROSTORE IN ESIDE FLASH
    A4C7  18 CE 14 00 	LDY    #$1400		; MICROSTORE LOAD POINTER (ALT FUNCTION)
    
    A4CB  EC 00       	LDD    $00,X		; MOVE MICROSTORE FROM FLASH TO THE TPU
    A4CD  FD 16 E0    	STD    $16E0		; 
    A4D0  EC 02       	LDD    $02,X		; 
    A4D2  FD 16 E2    	STD    $16E2		; 
    A4D5  EC 04       	LDD    $04,X		; 
    A4D7  FD 16 E4    	STD    $16E4		; 
    A4DA  EC 06       	LDD    $06,X		; 
    A4DC  FD 16 E6    	STD    $16E6		; 
     
    A4DF  18 EF 00    	STY    $00,Y		; UPDATE MICROCODE WORD
    
    A4E2  18 08       	INY			; POINTER FOR NEXT MICROCODE
    A4E4  18 08       	INY			; 
    
    A4E6  C6 08       	LDAB   #$08		; INCREMENT FLASH MICROCODE POINTER
    A4E8  3A          	ABX			; TO NEXT 64BIT WORD
    A4E9  8C B0 7C    	CPX    #$B07C		; MICROSTORE LOAD COMPLETE
    A4EC  25 DD       	BCS    $A4CB		; LOOP THROUGH STORE

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
  •