Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

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

  1. #1

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

    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 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.

    Click image for larger version. 

Name:	IRQ_time_delta_blowouts.png 
Views:	12 
Size:	18.0 KB 
ID:	30090

    It is occuring at about at 200ms interval.

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    No: Pin 28 is:
    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:
    = 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...

  3. #3
    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....

  4. #4
    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)

    Click image for larger version. 

Name:	isr_period_improved_15usmax.png 
Views:	12 
Size:	19.3 KB 
ID:	30103

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts