Suggestions for cause of high priority ISR being blocked - T4.1 with external ADC

[strud]

Hi all

I am working on a high speed logging type device with an external ADC connected by SPI to the T4.1.

There is a single ISR that is triggered by the ADC data ready line going low, this is connected to the T4.1 pin 28.

I am seeing a regular blowout of the ISR interval delta even though I have tried to set the priority very high with: NVIC_SET_PRIORITY(IRQ_GPIO1_16_31, 0);

Nb: Iam a little confused as to what IRQ group I should be using for pin 28. This seems to map into D5 and then EMC_32.


I am using teensythreads https://github.com/ftrias/TeensyThreads to allow for some low priority comman line interfacing etc to take place.

I suspect that my interrupts priorities are not being set as high as I had hoped, and the threads are simply interrupting....




I guess before I go any further, can someone advise if I have mapped the correct IO group in this IRQ priority setting?

Is there a document that explains the relationship between the pin labels in the teensy 4.1 schematic and the GPIO IRQ groups?


here is a plot of the phenomenon - chart shows the ISR time delta (between calls) vs cumulative time. Typical is 7.8us and when the issue occurs this streches out to up to 50us.




It is occuring at about at 200ms interval.

[KurtE]

No: Pin 28 is:

28	EMC_32	SEMC_DATA10	FLEXPWM3_PWMB01	LPUART7_RX	CCM_PMIC_RDY	CSI_DATA21	GPIO3_IO18			ENET2_TX_EN

So in normal GPIO mode this is GPIO3 pin 18.
But assuming you are using the standard core all of the GPIO pins are switched to be in high speed mode: So this one is on GPIO08 pin 18

And all of these high speed GPIO ports all map to one IRQ: IRQ_GPIO6789 = 157, // RT1060 only

The pins are mapped to high speed in startup.c with the lines:

	IOMUXC_GPR_GPR26 = 0xFFFFFFFF;
	IOMUXC_GPR_GPR27 = 0xFFFFFFFF;
		IOMUXC_GPR_GPR26 = 0xFFFFFFFF;
	IOMUXC_GPR_GPR27 = 0xFFFFFFFF;
	IOMUXC_GPR_GPR28 = 0xFFFFFFFF;
	IOMUXC_GPR_GPR29 = 0xFFFFFFFF;
= 0xFFFFFFFF;
	IOMUXC_GPR_GPR29 = 0xFFFFFFFF;

Now you can switch some of the pins back to normal speed by updating the appropriate IOMUXC register here: probably in this case IOMUXC_GPR_GPR28
Probably the bit: 1<<18

If it were running in this mode: Each of the ports have two IRQs, one for the lower 16 bits and one for the higher 16 bits. In this case it would probably be.
IRQ_GPIO3_16_31 = 85,

Which you would need to attachInterruptVector to this one, and then enable the interrupt and set the priority. And you interface method would probably need to
update the appropriate register to clear the status and maybe the cache of it...

[strud]

Thanks KurtE, much appreciated.

It is much improved now, still some smaller time blowouts occuring however these may be caused by something I am doing in the ISR....

[strud]

I've done some work to analyse the time taken for code within the ISR and nothing in there is causing the blowouts/large jitter.

Total ISR execution time: 375ns (av) 445ns (max) 372ns (min) 6.6ns (stddev)

Unfortunately the digitalinput reads and bit manipulations etc are taking 206ns of that 375ns (but that is another story).

Nominal interrupt rate from the ADC is 128ksps -> 7.81us between interrupts.

Priority being set using: NVIC_SET_PRIORITY(IRQ_GPIO6789, 0);

Now I am getting occasional (seemingly random) increases in time between iterrupts of up to 15us (the50us spikes are no more)



Given that I have set the interrupt priority to 0, what else going on in the system is likely to be causing these seemingly random time delta spikes?

I have both SD and USB libraries in use, would they have any interrupts that would be set to this high priority?

Have I given other interrupts in these or other libraries higher priority now that I have used the general/broad interrupt priority approach?

I will take a look at what KurtE has proposed regarding better granuality on interrupts per pin.