Mike Palmer

908QY4 output compare

Discussion created by Mike Palmer on Aug 9, 2006
Latest reply on Aug 10, 2006 by Mike Palmer
Tearing my hair out here trying to figure out what my little 908QY4 is doing with respect to an output compare on TCH0.
 
Basically, I want to set up an OC to occur at some point from "now" (i.e. 20uS from now...) to initiate a cascade of OCs to transmit a simple serial stream. The pin idles low and the first OC to get the ball rolling will set it high. Here's a code snippet:
 
Code:
    .
    .
    .
    //finish up bit stream configuration...    g_PID1Message |= ((unsigned int)(FW_REVISION & 0x07));    g_TCH0BitMask = 0x8000;             //send 16 bits MSB first    g_TCH0NextDelay = KTCH0MSG_FRMNOM;  //so ISR knows how long to hold this state           DisableInterrupts;                  //disable system interrupts    //configure TSC0 for output compare, rising edge to occur with interrupt.        //bit 7 0 CH0F    //bit 6 1 CH0IE --enable interrupts    //bit 5 0 MS0B  --B:A == 01 means output compare    //bit 4 1 MS0A    //bit 3 1 ELS0B --B:A == 11 means set pin next compare    //bit 2 1 ELS0A    //bit 1 0 TV0    //bit 0 0 CH0MAX        TCH0 = TCNT + KTCH0INITDLY;         //compute time of message start        TSC0_CH0F = 0;                      //clear any pending OC interrupt        TSC0 = 0x5C;                        //enable the OC interrupt                    EnableInterrupts;                   //re-enable system interrupts        //ISR will handle remaining bit transmission and will shut itself off when done.}//ProcessOutgoingDSPMessagePID0
.
.
.

KTCH0INITDLY is a constant equal to 64 ticks of the 312.5nS system clock which, should in theory, set the TCH0 output compare to match up at the current time (TCNT) plus 20uS.
 
The constant KTCH0MSG_FRMNOM is equal to 300uS worth of clock ticks (i.e. I want the first pulse to be 300uS long and the variable g_TCH0NextDelay is used in the ISR to set when the next OC (clearing the pin) will occur.)
 
The problem I'm encountering is that as soon as the "TSC0 = 0x5C" is executed, the pin transitions high immediately and stays high for 320uS (i.e. 20uS delay is added to the desired 300uS pulse width...) It doesn't appear to wait for TCNT to equal TCH0...it just immediately OCs. From that point on, my serial stream is dead nuts on and the ISR-driven OCing operates exactly as expected...until the next message is to go out, then it repeats this again.

What am I missing that's causing the first OC to occur too early like this?
 
 

Outcomes