This is going to be a long thread, so bare with me. I am walking thru the $0d non cc TCC handling routine at LAE65. The problem I am having is very early in the routine where it does a 2D lookup of the lower load limit for the TCC to lock.
LAE6F LDAA L02A7 ;MPH
LDAB #205 ;Scalar for lookup
MUL ;MPH x scalar
ASLA ;x2, now scaled to 10 mph increments for lookup
LDX #L515E ;Lower load limit for TCC to lock
JSR LF15E ;2D lookup

I am using a data log with the speed at 67 MPH.
Lo2A7 should contain 134 or 0x86

Load Acc A = 134 .... 0x86
Load Acc B = 205 ..... 0xCD
Mult A & B Acc D = 27470 ... 0x6B4E
shift Left ACC A = 12 .... 0x0C
Load Acc X = 0x515e (table address)

jump to F15e Here is where I run into a problem

LF15E PSHX ;Push table addr. to stack
PSHB ;Push offset to stack
LDAB #$10 ;Multiplier for lookup, 16 counts/row

the LDAB instruction assumes 16 counts / row, however L515E is only 9 elements

L515E FCB 13 ; 5.0 0
L515F FCB 13 ; 5.0 10
L5160 FCB 13 ; 5.0 20
L5161 FCB 13 ; 5.0 30
L5162 FCB 17 ; 6.6 40
L5163 FCB 20 ; 8.0 50
L5164 FCB 22 ; 8.6 60
L5165 FCB 23 ; 9.0 70
L5166 FCB 23 ; 9.0 80

??? how can this lookup work?

 

$0D or $0DA ? 16196395, 16197427 might want to pick Eaglemark brain
http://www.gearhead-efi.com//

 

The look-up arg has been modified as such:

It loads the MPH (0 - 255 MPH), and multiplies it by 205 (now 0 - 52275). 67 MPH being 13735.

Then by only using reg A of the result there is an inherent divide by 256 (now 0 - 204). 67 MPH being 53.

Then the ASLA which is a multiply by 2 for 0 - 408, which can overflow. 67 MPH being 106, which is still within the table. And at the correct location within the table.

However, since there is no upper limit check the routine fails once above 80 MPH. It will either wrap into the lower area of the table (on overflow), or use the next tables values on no overflow.

It may also be that the HAC is incorrect. It usually pays to check the hac against the actual code.

RBob.

 

Thanks RBob. So the MUL instruction loads the A and B registers, with A being the MSB? The main problem I had was that the table at 515e is only 9 elements, and the offset expects 16 elements.

LF15E PSHX ;Push table addr. to stack
PSHB ;Push offset to stack
LDAB #$10 ;Multiplier for lookup, 16 counts/row

the LDAB instruction assumes 16 counts / row, however L515E is only 9 elements

L515E FCB 13 ; 5.0 0
L515F FCB 13 ; 5.0 10
L5160 FCB 13 ; 5.0 20
L5161 FCB 13 ; 5.0 30
L5162 FCB 17 ; 6.6 40
L5163 FCB 20 ; 8.0 50
L5164 FCB 22 ; 8.6 60
L5165 FCB 23 ; 9.0 70
L5166 FCB 23 ; 9.0 80

Doesn't this overflow the table everytime?

OKAY, I think I get it now. Because I now properly understand the MUL double accumulator trick, I end up pointing at 5164, or 60MPH. Thank You so much.

 

> So the MUL instruction loads the A and B registers, with A being the MSB?

Correct MUL -> A * B = D (D being A & B together).

The one comment here is incorrect:

It should be "save for exit", IOW, the value in reg B isn't used in the routine and is restored to the original value upon exit.

> accumulator trick, I end up pointing at 5164, or 60MPH.

At 67 MPH the look up arg is 106 (see above). Divide by 16 and it is 6.625, which puts it about 2/3's of the way between 60 and 70 MPH in the table (the look up routine interpolates between rows).

Say a MPH of 100 is used. That becomes:

((100 * 205) / 256) * 2 = 160

Which divided by 16 is: 160 / 16 = 10. Which puts us past the end of the table and into the next one. To be specific at the 25 MPH row of the Upper Load Limit table.

Now for a rollover it gets tricky, if the MPH is 165 the look up arg is:

((165 * 205) / 256) * 2 = 264

The value 264 can't be held in 1 byte, so it rolls over to 8 (264 - 256 = 8). Which wraps back to the correct table but in the wrong location (5 MPH).

RBob.

 

Thank You again RBob. I did figure out the interpolation, but in my source, everything above 10 mph has the same value, so no interpolation necessary. Even with the table I used in this example, it's only 1 count between 60 and 70. I was fine once i was pointed into the table. I am however concerned about speeds above 80mph as most people doing this upgrade have engines well capable of exceeding that speed. I was thinking about replacing JSR F15E with a JSR 7100 ( or some available location) and then adding code that sets the MPH to 80 if it is over 80 so that the problem of pointing in the wrong place in the table doesn't happen. Then doing the JSR to F15E and a return to make sure it goes back correctly. Is this a common fix? Or would it make more sense to create a new table and point to it? Well, looking at your example, anybody going over 159 mph will have that problem anyway even with a bigger table, so I guess you could build a blended fix to correct both high speeds and a small table, however in my case, I doubt the truck will see over 90 mph more than once in its lifetime. I drive like an "old man".

 

Im not sure why that is the way it is in the code. Its been so long since I did the hack I cant remember if I looked into it or not. Might be worthwhile to double-check a $0D binary to see if thats what the code actually is. Basically what will happen is that it will continue into the next table. The max # of rows can be 17 (0th row + 16 numbered rows), so it will wrap into the next table once the value goes over 80 MPH.

There are a number of mistakes in the $0D from what I recall. Its easy enough to fix since the hack is fully assemble-able and uses indirect addressing. Just fix the code, and re-assemble.

 

Dimented, I just finished comparing 2 different $0d binaries with exactly that in mind. I actually did that before I saw your post. They were exactly the same in the part of the code for non cc TCC lockup. The tables at 515e were slightly different, but not a lot. I thought about fixing the code inline, but then all my labels would be incorrect. I have all the labels as the physical address of their location, it would throw everything off and confuse me a lot, it is really simple to just jsr to a code snippet to take care of the overflow problem. I will assemble it and publish it on this thread soon. Right now I am trying to figure out why Dave W can't get his 700R4 to lockup. All the parameters I have looked at so far seem to be just fine for lockup, but it appears to never happen. However, I am not 100% convinced that his datalog is correct yet.

 

Does he have +12VDC power to the brake input pin on the PCM??? The PCM has an internal circuit that prevents TCC if the brake switch input not present. I ran the stock TCC settings from BJYN when I first swapped to my 7427 in my TBI 350/700r4 G20 van and it would lock the TCC at 32-34 mph. With stock settings above 85 MPH the TCC locks on a manditory lockup regardless of throttle position.

 

That was one of the first questions I asked him, and his reply was yes he does have it wired that way.

 

All the labels should be entered in as lables. Its OK if the label no longer matches the address it actually points to. I wouldnt be too hung up if they change. Really in programming the location of the code is unimportant unless your subject to a memory constraint. When you can, its preferable to do things inline and recompile. What I do is each segment of code I write or mod uses its own custom labels so it can be ID'd as custom, as well as track the changes. Heres the format I used in the OD MAF code:

Sample label: L[XXX][Y][ZZ]

XXX = 3 or 4 letter unique label descripter
Y = 'P' for calibration, 'RV' for bra revision, or not present if used in code branching
ZZ = 1 or 2 digit label/bra ID number

The ZZ in this case is an incrementing number assigned to progressive labels (ie LJMP00, LJMP01, etc.)

 

You are correct of course, It really doesn't matter if the labels match the addresses. I just use them as a lazy way to find stuff in bins. I thought about the ability of using the code as a patch when I thought about jumping to an unused location. That way, anyone concerned about exceeding the limit of the table could just patch the binary. This is especially good for non-programmers. I am not sure yet if that is a good idea or not. Your thoughts....

 

Okay, Just to get this straight in my head, L0085 bit 5 is output to pin E10 correct. Apparently pin E10 is not changing state on Dave W's setup. I can't see any reason why it doesn't change state, all his pre-conditions for TCC lockup appear to be met.

 

Output for TCC is either E10 or E11, cannot remember which. The one for PWM TCC is the one you want.

 

Okay fast, you have me confused a little bit here. In your writeup for doing a 427 swap, it says E10, but E11 is the PWM TCC pin. If L0085 bit 5 is pin E11 then his TCC would never lockup. Nor will mine when I install it. Where is a reference to which locations to write to and read from on a pin by pin basis?

 

The PWM TCC output is used in the 4L80-E and non-CC auto applicaitons. The standard on/off TCC output is used in the 4L60-E applications.

And, as fast said, there needs to be a +12V signal at the brake switch input for lockup to take place. There is an internal output for each TCC line thats only enabled when +12V is present. The TCC will IMMEDIATELY unlock regardless of the PCM state when that signal is lost (brake pedal depressed).

 

 

Okay Dimented the 12 volt signal is hooked up exactly as Fast documented. Your second post confused me. Was I completely wrong about the routine at AE6F? I assumed it was for non cc transmissions (700R4). I find that making assumptions usually gets me into trouble, which is why I am posting this. I understand how The code got to AE6F, I will have to backtrack to understand how it gets to CBF0. I see it is the hardware config routine, I just need to work from CA43 to see if anything could cause it not to lock up the TCC.

 

I looked at it some more. if I understand it, AE65 checks preconditions for nonCC TCC lockup, and if conditions are met, it sets 0085 bit 5 to a 1. Then CBFO writes a duty cycle to the PWM TCC output based on whether or not bit 5 is set. Max DC is 7FFF and min DC is 7F00. If bit 5 is not set, ie TCC not commanded to lock, what does setting the PWM TCC output to min DC do? I am so confused right now, my head aches. My eyes are starting to bleed from looking at this code for days, Can someone clarify how this is supposed to work or at least give me a hint here.

 

Its not as hard as you think. The PWM output is just used as an on/off output for the TCC in the non-CC applications. Keep in mind that the segment I showed there is only run when a manual or non-CC auto is present. Otherwise, it is never executed. When b5 is set to 1, the DC is set to 100%. If b5 is set to 0, the DC is cleared. Ive verified this on the bench with a load on the output. Simple on/off action. At 0% DC theres still a very small amount of leakage current, but not enough to have any sort of effect.

Think of it this way: The output runs at something like 2048 Hz as a square wave. The MSB is a scalar that sets the frequency (if I recall), and the LSB sets the duty cycle (%DC = value/255). The DC itself sets how much time the wave spends at full output as opposed to no output. 50% duty cycle means that the output is on for 50% of the time, and off for 50% of the time. 10% duty cycle means that the output is on for 10% of the time, and off for 90% of the time. To prevent TCC solenoid chatter, the output is either fully ON or fully OFF in the non-CC applications.

 

Now, as far as the TCC, have you verified that the TCC solenoid has power? Stupid question, but still worth asking. You should see +12V at the TCC input at the PCM (pin E11, or whatever the PWM output is). The output does not put out a voltage. Rather, it acts as a current sink to ground. When its on, it completes the circuit. In almost all GM switching apps, everything is switched to ground to avoid having large +12V leads to the PCM and possible shorts.

 

If you want to test the TCC output directly, you can replace the $7F00 for the off DC with $7FFF in the code and reburn the chip. When the key is turned to the ON position, but engine is still off, the TCC solenoid output pin should be at (or very near) 0 V when it is back-probed with a DVM. When you restore the $7F00 for the off DC, the output should be at +12V. If its at +12V the whole time or at 0V the whole time, there is an issue or something is not configured right in the PCM.

 

I wrote that swap guide weeks after I swapped and I am human, but if pin E11 is the PWM TCC pin, that is the one that the non cc trans TCC is on.

 

Fast, please don't take offense, I understand. If it weren't for you, many of us wouldn't even be able to begin doing the swap. I am thinking however you might want to go to the sticky and edit it.

And Dimented.... I can't believe how much I have learned from doing this, THANK YOU.

 

I'd like to take a moment and say "Thank You" to everyone who has posted information in this thread.

I typically think of myself as an "A Game" TGO member. I seem to be completely stumped as to why I am unable to get a test bench set up to operate a TCC Solenoid. I admit, I'm using a fuel pump relay (coil measures 56 ohms), not a TCC Solenoid (typically about 27 ohms coil). When I program $7FFF or $7F00 I an unable to complete the ground path (PCM E11) for the test solenoid. I'm using an ohm meter to verify the relay contacts are closing.

What I know about my test bench set up. The fuel pump relay works for a few seconds when I turn on the ignition switch. The fuel pump relay will work when the distributor is spinning and the ignition switch is on. Other things that work on the test bench when the distributor spins (ignition switch on), spark to spark plugs, noid lights on the injectors flash, IAC resets when the ignition switch is turned off (initial ignition switch off).

I verified the fuel pump relay works. I've come to the conclusion that maybe $7F?? is not controlling the non-CC TCC lock up? Maybe $7F?? is only active when the distributor is sending a reference pulse to the PCM?

Thanks again everyone,

dave w

 

Keep in mind that the brake switch input needs +12V or nothing happens. As I said earlier, the TCC outputs are gated to that internally in the PCM. Also, you should use a DVM instead of a relay. Much easier to see whats going on. You can measure the resistance between the pin and the case. Should be very high when inactive, and nearly 0 ohms when the ouput is active.

I can check on my bench tomorrow, but Im pretty sure that output is only tied to the brake switch.

 

No, its not address $7F00 you need to change! Heres what you need to do:

Go to address $CBFF. Change the double byte value to $7FFF (from $7F00 in the stock binary) and the TCC output should be active with the +12V brake switch input.

 

I'll try the changes described.

dave w

 

$CBFF value 7FFF worked!

Now what I need to figure out is if I can get a bench test data log to show the same log as posted below. I'm thinking when $CBFF is always 7FFF, then I should always see a TCC in Lock-Adjust Mode "TRUE. The picture below is from the vehicle I've converted to the '427 PCM. I'm thinking having TCC in Lock-Adjust Mode "True" confirms the .bin file is configured correctly, and that the +12VDC brake switch is correctly wired.

dave w

 

The data log bench test showed all "false" TCC in Lock-Adjust Mode with CBFF set to 7FFF. I'm not sure my above assumption was correct? Does not really matter, because I would not use a chip in a vehicle with CBFF set to 7FFF.

Anyway, I find the actual vehicle data log somewhat of a positive indicator that I have everything correct for TCC control. I still need to change the actual pin wiring of the TCC control wire. Problem is, the vehicle is not available for me to work on, and I won't be able to fix the wiring anytime soon.

dave w

 

Dave try to data log using tunerpro instead. It may be a problem with the data logging that you are chasing.

 

I'm using TunerPro RT. The screen shot is the exported .csv file.

dave w

 

what adx are you using?

 

I'm using V5 with A217_OD_v250.adx

dave w

 

When you make that change, it wont show in the datalog. That actually overrides the PCM and commands the TCC on at the hardware level.

 

That is good to know.

Does the screen shot showing the data log from the vehicle confirm the TCC configuration correct? Is TCC in Lock Adjust Mode "True" the correct information from the data log when the PWM TCC is set to "ON"?

dave w