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
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
Hi,
Anyway, I suggest you comment the PRINTF() function and have a try.
BR
XiangJun Rong
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
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
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
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
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