AnsweredAssumed Answered

Measuring Long Periods via Timer Over-Flow Flag Trick.

Question asked by sean keys on Aug 5, 2014
Latest reply on Aug 7, 2014 by Edward Karpicz

I had the following code, which worked just fine before I assigned the over-flow ISR to XGATE. I'm using 800ns ticks.

 

/* code that is part of an IC ISR */    LongTime timeStamp;     /* Install the low word */     timeStamp.timeShorts[1] = edgeTimeStamp;     /* Find out what our timer value means and put it in the high word */     if(TFLGOF && !(edgeTimeStamp & 0x8000)){    /*see 68hc11 ref manual for details */         timeStamp.timeShorts[0] = timerExtensionClock + 1;     }else{         timeStamp.timeShorts[0] = timerExtensionClock;     }     unsigned long thisEventTimeStamp = timeStamp.timeLong; 

 

 

Due to new product requirements, XGATE now handles the timer-overflow ISR as well as some OC ISRs:

xgateTOFISR:     TOFISRSEM:   SSEM #1 ; try to lock semaphore   BCC TOFISRSEM; retry until locked   ;Increment the metronome request to trigger the s12 to run metronome();   LDW R7, metronomeRequestCount   LDW R6, (R7, #0)   ADDL R6, #1   STW R6, (R7, #0)   ;Clear timer overflow interrupt flag   LDL R7, #TFLGOF   LDL R6, #0x80   STB R6, (R7, #0)     CSEM #1 ;Release semaphore   RTS 

and in my NEW  S12 ISR:

 

do {   XGSEM = 0x0202; } while ((XGSEM &= BIT1) == 0);   timeStamp.timeShorts[0] = timerExtensionClock; XGSEM = 0x0200; //Clear semaphore 1 by writing mask=1 and flag=0 

 

 

My problem is that I often get bogus results when I diff the previous time-stamp. It's obvious that there are times when an over-flow is not correctly being accounted for. What's not so obvious is how to solve this.  Any input would be appriciated.

 

Thanks

Outcomes