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.

TMS570LC4357: Using ARM effectively

Part Number: TMS570LC4357


Hi,

I'm somewhat new to ARM architecture and have some esoteric questions.  I've done C/C++ programming on ARM for decades, but mostly on Linux or some RTOS, so haven't had to deal with some of the more obscure stuff.

The immediate question I have is on the CPSR.  According to some documentation, when an FIQ handler is entered, the I (IRQ) bit is set (to mask out IRQs).  But, I'm seeing the F (FIQ) bit still clear.  This seems to indicate that FIQs could still happen (stacked interrupt), but I'm pretty sure the FIQ stacking is not happening.  Can someone clarify this behavior to me?

The code I have is:

uint32 _mask_IRQ_FIQ()
{
__asm("\tmrs r0, CPSR");
__asm("\tand r0, r0, #0xc0");
__asm("\tlsr r0, r0, #6");
}

In FIQ handler (notification handler)...

uint32 intmask = _mask_IRQ_FIQ();

and intmask is 0x2.

Thanks.

  • Hi Peter,

    Cortex R4/5 does not support interrupt nesting inherently. If you do need nested interrupts it needs to be managed completely by the application code. There is no hardware mechanism to aid with this other than the pending interrupt status flags.

    The below application can be handy for this

    Nested Interrupts on Hercules ARM Cortex-R4/5-Based Microcontrollers (ti.com)

    --

    Thanks & Regards,

    Jagadish.

  • Hi, Jagadish,

    I don't want/need nested interrupts.  My question is why, in the FIQ handler, the F bit in the CPSR is _not_ set, to indicate that the FIQ interrupt is masked off (disabled).  The I bit _is_ set, and indicates that the IRQ interrupt is masked off, which is indicated in the ARM documentations (since IRQ is lower priority than FIQ).

    In my mind, the FIQ handler should be seeing _both_ F and I bits set, indicating that neither FIQ nor IRQ interrupts can be processed from this point (FIQ from being nested and IRQ from being lower priority).

    Any insight into this behavior would help me understand better how ARM works.

    Thank you very much.

  • My question is why, in the FIQ handler, the F bit in the CPSR is _not_ set, to indicate that the FIQ interrupt is masked off (disabled).

    From a search found Interrupt and Exception Handling on Hercules ARM® Cortex®-R4/5-Based Microcontrollers in which section 2.5 Fast Interrupt Request (FIQ) contains:

    The FIQ is implemented as a non-maskable interrupt in the Hercules MCU’s. This means, that once activated by the application (by clearing the F bit in the CPSR, see Section 2) it could not be masked again. The only way to mask the FIQ once activated is to perform a reset of the CPU system.

    Does that answer your question?

  • Ahh, that _does_ answer my question, and agrees with my observations.

    However, as a follow-on question, if FIQ is _not_ maskable, will the FIQ interrupt handler be interrupt-able (via another FIQ), making it stack-able?  I'm not seeing this happening.  Perhaps the FIQ interrupt is "level triggered" and until the handler exits, it can't be re-armed (and re-triggered).  Any insight?

    Thank you very much.

  • Hi Peter,

    will the FIQ interrupt handler be interrupt-able (via another FIQ), making it stack-able?

    No, FIQ handler cannot be interrupt-able.

    FIQ handlers are not reentrant that means 

    Non reentrant functions cannot be interrupted.

    --

    Thanks & Regards,

    Jagadish.

  • will the FIQ interrupt handler be interrupt-able (via another FIQ), making it stack-able?

    In the External interrupt requests section of the ARM Cortex-R Series Programmer's Guide found:

    In Cortex-R series processors, it is possible to configure the processor so that FIQs cannot be masked by software. This is known as Non-Maskable FIQ and is controlled by a hardware configuration input signal that is sampled when the processor is reset. They will still be masked automatically on taking an FIQ exception.

    And in the Interrupts section of the Cortex-R4 and Cortex-R4F Technical Reference Manual r1p4 says the following about Non-maskable fast interrupts (NMFI):

    When NMFI behavior is enabled, FIQ interrupts cannot be masked by software. Enabling NMFI behavior ensures that when the FIQ mask, that is, the CPSR.F bit, is cleared by the reset handler, fast interrupts are always taken as quickly as possible, except during handling of a fast interrupt. This makes the fast interrupt suitable for signaling critical events. NMFI behavior is controlled by a configuration input signal CFGNMFI, that is asserted HIGH to enable NMFI operation. There is no software control of NMFI.

    The Interrupts section also describes how:

    • Software can detect whether NMFI operation is enabled by reading the NMFI bit of the SCTLR
    • When NMFI is enabled how an instruction writing b1 to the CPSR.F bit leaves it unchanged.
  • Ah, you are providing me more info than I can absorb or use at the moment, but I really appreciate the insight into how all this is put together.

    I need to hunker down and study the ARM architecture, with its 7 modes and how they interact.  I found several resources at the TI forum and on the Web in general that would help me.  Unfortunately, I have to juggle between learning useful stuff and getting work done for now.

    Slowly but surely.

    Thank you very much.

  • Hi Peter,

    We can close this thread if you are happy with the answers.

    --

    Thanks & Regards,

    Jagadish.

  • Hi, Jagadish,

    Please leave this thread open for the time being.

    I have lots of questions on ARM that I'd like to pose in the near future, and would prefer them to be collected in one thread verses scattered over many threads.

    Unfortunately, I'm very busy right now getting Launchpad sub-projects to work and can't organize my questions and thoughts well enough to write cohesive questions.  As I mentioned, I need to do my homework and read up on the several articles and videos on ARM architecture and design and digest enough to not waste others' time.  But, hopefully soon.

    Thank you very much.

  • Hi Peter,

    Okay, we will keep open this thread.

    --

    Thanks & Regards,

    Jagadish.