my interrupt (highest priority) jitters when i do a read from a peripheral register.
How can i prevent this? Does this depend on the different Busclocks?
Here my test code.
PWM2->SM.STS = 0xFFFF;
GPIO2->DR_TOGGLE = (1UL << 30); // Sync Out Signal
myvariable = DMA0->TCD.CITER_ELINKNO; // Read from DMA
// myvariable = GPT1->CNT; // Read from Timer
// myvariable = LPSPI1->FSR; // Read from SPI
Timer: 268 ns
SPI: 67 ns
well, your interrupt latency can really depends on many factors. If you want to get the maximum speed in interrupt service routine execution you need to ensure:
- the stack in located in DTCM (no external SDRAM)
- enter and exit from interrupt will take about 20ns if running at 600MHz
- interrupt service routine is executed from ITCM (no external QSPI even the I-CACHE enabled cannot be enough)
i set all clocks to maxium, ref manual table 18-4
my irq is already running in fast ram (between 0x00000000 - 0x00020000)
setting the clocks to maximum decreases the irq latency down to 408 ns. but it is still very high
rembember my irq handler has only two simple c source code lines. there is no stack variabe, etc.
my firmware is now running and has a lot of interrupt routines/functions for USB, Ethernet, UART, LSPI, DMA, GPIO, etc.
The GPIO IRQ on GPIO1 (only this GPIO IRQ) => GPIO1_Combined_16_31_IRQHandler has the highest level (0)
there are no __disable_irq(), etc. in the firmware, meaning i do not use any disabling function.
The irq function:
GPIO1->ISR = (1 << 24);
GPIO1->DR ^= (1 << 9);
I did some measurements and use my oscilloscope therefore. The pin GPIO1.24 is connected with a frequency generator, and pin GPIO1.9 toggles the output. my oscilloscope captures both pins.
i start the test and do a lot of UART and USB and Ethernet communication things.
The interrupts raises up to 978 ns.
Very very bad. The GPIO Irq has the highest priority in my system.
So what the hell is going on here?
How can that be? How can i improve the irq jitter?
Below are some hints regarding the issue.
Please use AN12078 (Measuring Interrupt Latency).
Any software based approach to access GPIO registers is limited by internal
bus arbitration delays, as stated in the following Community thread
“RT1050-EVK GPIO fast pin toggel”
Also, note base GPIO (IPG) clock is limited by the value of 150 MHz.
In any case, check if in Your tests I-cache is enabled, but D-cache, concerning
the registers, is disabled.