This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FIQ interrupt "nesting" support in StarterWare?

Hi,

Sorry if I am not using the right terminology below, and/or if "nesting" was not the right term to use ...

Suppose I have both IRQ and FIQ enabled, and then have

IntChannelSet(SYS_INT_GPIOB2, 0); // mapped to FIQ
IntChannelSet(SYS_INT_USB0, 2); // mapped to IRQ

Suppose my USB interrupt handler is taking a long time... will my GPIO interrupt have to wait until the USB handler is finished, or will FIQ "interrupt" IRQ in StarterWare, out-of-the-box?

In other words, what is meant on the wiki by, "StarterWare doesn’t support nesting of interrupts within host interrupts" ?

Thank you!!
Jonathan

  • Hi Jonathan,

    Suppose I have both IRQ and FIQ enabled, and then have

    IntChannelSet(SYS_INT_GPIOB2, 0); // mapped to FIQ
    IntChannelSet(SYS_INT_USB0, 2); // mapped to IRQ

    Suppose my USB interrupt handler is taking a long time... will my GPIO interrupt have to wait until the USB handler is finished, or will FIQ "interrupt" IRQ in StarterWare, out-of-the-box?

    Your GPIO interrupts will not have to wait . Since you have routed GPIO interrupt to FIQ, your GPIO ISR can preempt your USB ISR !

    In other words, what is meant on the wiki by, "StarterWare doesn’t support nesting of interrupts within host interrupts" ?

     "StarterWare doesn’t support nesting of interrupts within host interrupts" means, one FIQ cannot preempt another FIQ. Same is applicable for IRQ.

    FIQ and IRQ are called host interrupts. That is why, in wiki its given StarterWare doesn’t support nesting of interrupts within host interrupts.

    Suppose  you reassign the interrupts below priority

    IntChannelSet(SYS_INT_GPIOB2, 0); // mapped to FIQ

    IntChannelSet(SYS_INT_USB, 0); // mapped to FIQ

    In this case, your GPIO ISR cannot preempt your USB ISR.

     

    Regards,

    Sujith.

  • Thank you, Sujith!

    Just a side note: When combining the uartEcho and gpioCardDetect examples, FIQ_STACK_SIZE in init.S had to be increased (default value was 0x8; increase to 0x100 was sufficient) .

    At the default FIQ stack size of 0x8, the FIQ (gpio) could indeed interrupt the first call to the IRQ handler (uart + delay), but then IRQ would then return to CPUAbortHandler ("system crash"?)

    At an increased FIQ stack size of 0x100, the FIQ preempts the IRQ, which returns to main() safely. Not sure if this is FIQ stack is too large...?

    -Jonathan

  • Hi Jonathan,

    Excellent! Sorry that I missed that information. The FIQ stack size you can determine entirely on your system memory available, may be for testing on EVM, we have plenty of memory available :) . If you need an optimal stack size, you can analyze th FIQ stack size and keep it there.  (May be, you can follow the conventional method by populating the stack with a known value say 0xA5, and then executing the code to generate FIQ and seeing upto what SP the known value is changed).

    If you use only GPIO with minimal local variables in the ISR, the stack size even can be lesser.

    Cheers,

    Sujith.