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.
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.
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
This file might be of use... Indicates accesses to the TPU. Missing could be accesses using indirection.
TPU_Access.pdf
-Tom
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
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
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
A real mess to decipher.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
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.
Bookmarks