SCTIMER Interrupt jitter

[jreh]

Hi,

I've set up SCTIMER2 to run at 20nSecs/tick.  I'm using match channel 0 to generate an interrupt every 1 mSec, for now. Counter counts up at 20nS, match occurs at 1mS, resets the counter, generate an interrupt, rinse repeat.  Eventually I need to output a SPI xfer every 14.76uSecs.  But 1st I was checking to see if the ISR trips.  It does but, there's jitter of about 100uSecs!  I have only 1 interrupt enabled, (checked ISER0 & 1).  Core running at 150MHz.  No atomic sections of code.  Below is the isr code, printf only occurs if get interrupt from another source. None occur.

I don't think there's anything in there that would cause 100uS of jitter.  I've checked, on a scope, the number of interrupts are correct over a long period of time, which means it's not drifting/accumulating the error.  It's just jittering from one isr to the next.  I suspect it's the over head of context switching?

Questions;

Is this normal?

Is there a way to reduce this?

If I use DMA, instead of an ISR, to start the SPI xfer, will the jitter still be there?  If so I'll need another way to do this.  Because 100uS of jitter swamps out the 14.74uS period of SPI updates.

Thanks in advance,

Jeff

[xiangjun_rong]

Hi,

Probably the PRINTF() leads to the jitter of the CTimer ISR, pls comment the PRINTF() function, have a try. If you have more ISR, pls set the priority of the CTimer ISR in highest with 0x00 in priority register of the CTimer interrupt.

Hope it can help you

BR

XiangJun Rong

[jreh]

Thanks for looking into this, but the PRINTF is not executed in the isr.  If it did it would print out which it doesn't.

Thanks

[xiangjun_rong]

Hi，

Anyway, I suggest you comment the PRINTF() function and have a try.

BR

XiangJun Rong

[jreh]

Hi,

Commented out the PRINTF, same results.  I'm measuring by toggling a gpio pin, GPIO->NOT[pin]=pin.  Would that cause any jitter?  The amount of jitter, 100uS, won't work for our application, found another way to accomplish what we need to do.  But want to make sure that we're not doing something wrong.

Thanks

Jeff

[xiangjun_rong]

Hi，

If you have commented the PRINTF() function, but the interrupt jitter is the same, we have to consider the other issue.

If you use the DMA module, we have to consider the resource competition, as you know, if both DMA and Core access the same memory, which may result in resource competition.

I suggest you put the stack to one RAMx, the stack is used to save registers, I suggest you remove all local variable for only a test in ISR. Put the DMA destination/source memory to another RAMx lest they compete.

If you disable DMA, what is the result?

Hope it can help you

BR

XiangJun Rong

[jreh]

Hi,

Disabled the DMA.  Only interrupt enabled is the timer.  No local variables, (RAM), used in the ISR.  Striped the isr to below.

void CTIMER2_IRQHandler( void )
{
 
  // Toggle gpio pin
  GPIO->NOT[BOARD_GPIOPINS_TP1_PORT] = BOARD_GPIOPINS_TP1_PIN_MASK;
 

// Clear Match interrupt
 CTIMER2->IR = 0x01UL;
 NVIC->ICPR[1] = (1UL << 4);

 SDK_ISR_EXIT_BARRIER; // Presently does nothing, but here for future/errata
}

Still see lots of jitter.

Thanks

[xiangjun_rong]

Hi,

Can you tell us the part number of LPC family? does the running code and stack are saved in the same SRAM space?

BR

XiangJun Rong

[jreh]

Hi,

Part is LCP55S69,  presently the 2nd core is disabled.

Stack in SRAM3

Variables for app in SRAM4

Thanks

[xiangjun_rong]

Hi,

Another clue is that the LPC55S69 may use on-chip FRO as the clock source for the CTimer, the FRO has jitter I think. You can output the FRO clock to a pin and check the clock quality.

BR

XiangJun Rong