Here are my findings for the unused pins:
Printable View
Here are my findings for the unused pins:
Thank you for this. I believe you may have given them to me earlier in my investigation. Problem I have is that one pin lacks Rs and Cs to make the connection to the pin. I wanted to see if someone knew what the function was or if it was used on some other car.
I guess the function was still born. It will be interesting to see if TPU uses the input to modify spark or fuel.
Thanks,
Tom
Some troubles to report (all my fault). As my code got larger it crossed a location that the GM code TPU initialization uses. I had not taken enough care to see this happening and lost some hours debugging. Now I understand, the problem is simple but when it happened I figured watchdog timer, NMI, blowen stack and hundreds of other problems. My code now jumps over the location and all is back to normal.
I need to re-run a bunch of testing to be sure result is not corrupt. <sigh>
-Tom
Hi,
So my ESide does not use the sci, but GM seems to be big on code re-use. And why not, their code is very well written and tested. Perhaps this code snip will be of some use:
This is a commented section of code from TSide that is the interrupt service for sci.Code:*************************************************
* VECTOR AT $FFD6
*
* SCI INTERRUPT
*************************************************
4D8C B6 10 00 LDAA $1000 ; READ PORT A
4D8F 97 7A STAA @$7A ; SAVE IT
4D91 84 DF ANDA #$DF ; SELECT FLASH BANK 0
4D93 B7 10 00 STAA $1000 ;
4D96 CE 10 00 LDX #$1000 ; POINT AT REGISTERS
4D99 1F 2D 20 09 BRCLR $2D,X,$20,$4DA6 ; BRANCH RX NOT READY: SCCR2
4D9D 1F 2E 20 2A BRCLR $2E,X,$20,$4DCB ; IF NO CHARACTER, DONE: SCSR
4DA1 BD BF 35 JSR $BF35 ; PROCESS RX BYTE
4DA4 20 25 BRA $4DCB ; DONE
4DA6 1F 2D 80 09 BRCLR $2D,X,$80,$4DB3 ; BRANCH TX NOT ACTIVE
4DAA 1F 2E 80 1D BRCLR $2E,X,$80,$4DCB ; IF TX REG NOT EMPTY, DONE
4DAE BD C1 2A JSR $C12A ; PROCESS TX BYTE
4DB1 20 18 BRA $4DCB ; DONE
4DB3 1F 2D 40 14 BRCLR $2D,X,$40,$4DCB ; BRANCH COMPLETE NOT ACTIVE
4DB7 1F 2E 40 10 BRCLR $2E,X,$40,$4DCB ; IF TX NOT COMPLETE, DONE
4DBB 86 26 LDAA #$26 ; SET FOR RX, WAKE MODE
4DBD A7 2D STAA $2D,X ;
4DBF CE 18 02 LDX #$1802 ; IOR CHIP PORT B
4DC2 1D 00 40 BCLR $00,X,$40 ; DISABLE ALDL OUTPUT
4DC5 15 7D 40 BCLR @$7D,$40 ; UPDATE EXPANDER PORT A SHADDOW
4DC8 15 7E 01 BCLR @$7E,$01 ; CLEAR IGNORE MESSAGE FLAG
4DCB 13 7A 20 08 BRCLR @$7A,$20,$4DD7 ; FIND PREVIOUS BANK
4DCF F6 10 00 LDAB $1000 ; RESTORE TO BANK 1
4DD2 CA 20 ORAB #$20 ; IF PREVIOUS
4DD4 F7 10 00 STAB $1000 ;
4DD7 3B RTI ; DONE
-Tom
Now that TPU's initialization problems are behind me (? i hope), I got a few things done this morning.
I wrote bootstrap code that initializes the TPU and reads&buffers it's registers (all of them). The code then waits 12.5ms and re-reads&buffers the result. The results can then be moved into excel for analysis. I have done a bit of this and can see a number of the undocumented locations that are not used in the code. This gives me a better look at how the internal TPU code is working with the signals.
While messing with the above code, I had a good look at the interrupt structure. While I still have no life on the ignition signals, I was able to get the interrupts to fire on the fuel side. That will enable me to understand all of the registers connected with fuel or at least I hope so. I will get back to this tomorrow.
-Tom
Thanks for the input on the SCSSI. After some trials and some bricks I managed to make the eside talk while the engine is cranking.
First I tried to reenable comms at oc4i. It didn`t worked as expected. I ended oraa $20 to the SCCR2, which make the comms worked on a very rare random basis.
I was tired of experiments and skipped the scssi disable code in the irq. This made the eside talk. It is not clear what will happen on a higher rpms, so I think to put a rpm threshold and reenable the comms at oc4i after the rpms drop. I will also cut all aldl chatter on the bus. I suspect the interrupt is activated on any aldl bus activity.
I wish I have an opti simulator for testing. How hard will be to make one like yours with a knob to regulate rpms.
The plan for cracking the tpu from the backdoor is solid. You can chart the unused pins ram locations and possible found more things left on the table from factory.
Tpu and eside exchange data each run of the irq. Eside calculates cyl fire id and sends it back to the tpu. I also found some code used for loss of sync[cyl ID] situations and resync on the fly. Really good job from GM.
You are welcome to the code on request. It isn't sophisticated and not finished in a nice way. Just a crude tool I knocked out to try and get an understanding. There is no "knob" to adjust RPM but it can easily be added. Do you have any dead PCMs? If yes, why not fit the code into the EEPROM and run it there. I think this was what was in my mind when I started things. My board is a tester from way back in the 1990s. It runs at 4MHZ but with 0 effort will just scale to the 12 used by GM.
Let me know what you need, and I will post. Easy way to work will be through bootstrap. I can give code, instructions++
-Tom
Good fortune this morning, I got working with the fuel side and started to characterize some of the parameters. I don't have a great scope, but it looks to me as if the injector pulse width defined in the 16b registers at $1400 - 0E work like this:
GM's crystal frequency
12.5829 MHZ
12582900 HZ
Resulting Eclock frequency
3.145725 MHZ
3145725 HZ
Clock period
79.473E-9 Crystal
317.892E-9
Injector pulse width for locations $1400, $1402, $1404, $1406, $1408, $140A, $140C, $140E
n * 15.259E-6
Still a bit of uncertainty if the divisor is 48 or 50. If I squint just right I can see one or the other. One of these days I need to trade up from my army surplus scope. I will bypass the drive circuits&FETs to measure and resolve this Q.
Also got the ignition to fire this morning. Real happy with that. On we go...
-Tom
That is some great breakthrough. Now can we find out what is the usage of high res signal. Is it only used for spark triggering or it does affect fueling also.
Cranking is really hard without high res signal but that is because the pcm needs some cranking before setting the code. I also traced some tpu bits changed on the error.
The pcm outputs 5v on low and high res pins and the opti drives the signal low on empty slot I guess.
The simulator should be pretty easy if I had a spare pcm.
n * 15.259E-6
That scalar is used for all time based units in the tpu. It will be nice to confirm it. Now it is something more of a guess based on Gm conversion data of bpw.
I thought you might already have what you would need. Otherwise, almost any of the single board computers available for a few $s can easily do. It is logistically easier if the part is 5V based but almost anything will do. Doesn't need to be Motorola at all. A PIC or an old intel 8051/31 type board would be ideal. In fact now that I think of it... your PC could output the pulse train through a parallel port under dos. I wouldn't want to use windows/linux/some big OS because the timing will be un-steady due to latency. Also the larger OSs might be slower and limit "RPM". Even so, you could try it under windows and see if it meets your need.
-Tom
Still working on TPU but,
I have a question regarding MAF. My understanding is that the MAF unit produces a frequency that is interpreted by the TPU. Is the frequency proportional to air flow or air flow mass? I know mass will be affected by temperature (IAT) and pressure (Barometer) the question is, does the MAF unit factor all this in or is it actually a measure of air flow and uses software to come up with the mass rate? I think the MAF might be mis-named (?)
If anyone can provide some clarity it will be a help.
-Tom
Maf is a mass air flow, It measures mass with a heat element being cooled. It is supposed to compensate for temperature and pressure, however humidity kind of screw the reading. However in the code there is only baro correction and some temperature correction for subzero temperatures. The corrections might not be output related but different engine requirements at that range.It also updates so quickly that gm put some smoothing routine to compensate for rapid changes.
The TPU outputs 4 maf values and eside gets an average of them for final calculation. It uses the raw TPU output for a maf table lookup and takes the value from table and interpolates between 2 adjacent cells. The first byte of RAW output is the vector for the table lookup and the second byte is the interpolation factor 0-255 or 0.01-0.99.
I will try to find a 68hc11 pcm to run a custom code for opti simulation. For variable rpm output I think a table for 1 high res pulse vs time vs rpm needs to be done and low res will just follow the high res.
I took a deep dive into injector offset. This parameter is set in the TPU at address $14B2. I believe the calculation goes like this:
-Read ignition voltage from A/D ch0
-Apply a transfer function to the voltage value such that points on the table are further apart under abnormal conditions and close together in the normal working area
-Transfer function is then used in an interpolation routine
-The output is an 8b value, a 16b value is developed by multiplying by 2
-That 16b value is the one applied to the TPU
Given the table for a '97 Z28, this is the stock graph. PS... missed some of the graph. Red is transfer function, green is injector offset. Decimal point missing in the voltage...
Attachment 15126
I plan to try various values for offset to determine how this is applied into the calculation of end of injection and/or pulse width. More work is needed on my end to understand when this parameter is calculated. I see it done in at least two places with code that is for the most part the same. Not sure why it is duplicated.
-Tom
It is done at reset and than at oc4i.
The update of offset value is every 100ms and it is stored at the TPU every 112.5 ms. I am sure it will be the same or close at the 96-97 code.
It will be nice to figure how it is handled by the tpu. The 16bit value is converted to ms by the same factor for BPW and low res signal.
I suspect that tpu adds the offset to the BPW before commanding the injector. Since you are at the injectors side, do you think that there is a setting in the tpu to fire injectors in batch mode. Does it use some average bpw value or still use the ind cyl bpw but fire 4 of them at the same time with the bpw set different for each cylinder.
Thank you for the details.
I wrote a simple test that writes a table of values to $1400 and $14B2. I believe $1400 to be injection pulse width and $14B2 to be injector offset. While monitoring the injection signal, I changed both PW and Offset. I looks like the two are added and the pulse width is the sum of both. Next is to measure pulse width vs EClock.
-Tom