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.

TMS320C6748: Help on using NMI interrupt

Part Number: TMS320C6748

Hello,

I need expert’s suggestions on usage of Non maskable interrupt (NMI) in TMS320C6748 DSP and CPU reset (exception) we observed when NMI is triggered.

Platform: TMS320C6748

CPU clock: 450MHz

Compiler optimization: -O3

Code location: External SDRAM, cached to L1.

 

In platform, we have utilized DSP NMI pin to connect external device to generate interrupt after periodic intervals, so it means we are using NMI as a functional interrupt. NMI ISR has small implementation to start UPP peripheral for data capture.

Under normal execution (I will say idle condition), NMI interrupt works perfectly without any issue. But we see abrupt DSP reset when NMI interrupts code piece which is doing some mathematical operations in a loop. We tried to debug this issue with the help of exception registers, but couldn’t find anything, as NMI and Exceptions share same interrupt vector.

 

Following is the code piece where NMI interrupt works fine,

.

.

.

While (execute_pending_task())

{}

.

.

 

Following is sample code piece, which when interrupted by NMI, causes DSP reset,

.

.

float mean = Get_Mean_Over_Float_Vector(pData, sampleCount);

float x = ((mean*y) / offset) * (1 - fastA);

.

.

We need help on this scenario, and here are our questions,

  1. Is it recommended to use NMI interrupt as a functional interrupt in embedded application?
  2. Can we use NMI interrupt and Exceptions same time, and identify cause of interrupt/Reset using EFR, IERR registers?
  3. Does interruption to software pipeline (SPLOOP) instructions by NMI can cause some un-desired behavior? And if Yes, is there any precaution/implementation we need to have in place to avoid this situation?
  4.  Can the interrupt latency and variation in latency of normal interrupts be brought down to similar levels as for NMI interrupt latency and variation in latency (e.g. by using compiler options such as --interrupt_threshold)?

We observed typical latencies of ~500 nano seconds for NMI interrupt and ~1 micro seconds latencies for normal interrupts when CPU is clocked at 450MHz.

 

Thank you.

Shri

  • Hi,

    1. You could use the nmi interrupt.
    2. This should be possible. Looping the RTOS experts to confirm/correct my understanidng
    3. Again I'll let the design team elaborate here.
    4. You can try and set interrupt priorities, this should speed up the irq handling.

    Best Regards,
    Yordan
  • Shri,

    I will respectfully disagree with Yordan on item #1, which by extension makes the other questions moot. Although it is technically true that you can use NMI as a functional interrupt, it should be considered as a forbidden choice.

    Many highly optimized routines use careful interrupt masking (DINT/RINT pairs) to allow the best use of the C6000 pipeline architecture. If an NMI occurs inside one of those DINT/RINT pairs, that algorithm will fail.

    Within a maskable interrupt's ISR, DINT can be the assumed state so pipelining can be used to advantage, and an NMI at that time would cause application failure.

    The CPU & Instruction Set Reference Guide talks about details of NMI behavior that can destroy an SPLOOP.

    NMI as an interrupt pin is intended to signal that something very bad has happened and the system needs to shut down. This could be when the Power Good signal goes low and the system needs to try to save limited status to allow later recovery after a reset or power cycle.

    With the addition of exceptions being enabled, NMI becomes even more destructive because it can then break the pipeline within the 5 delay slots after a branch instruction. There is no way to successfully return from that.

    I suspect the additional latency that you measure is due to the OS automatically saving a lot of registers for maskable interrupts, and not doing that for NMI, or perhaps saving fewer registers for the NMI. There could also be many other explanations depending on what you are doing and how you are measuring the change. The average difference should not be that large, unless you have a lot of interrupt-disabled loops for optimized math operations - and those would have a good chance of being broken by returning from an NMI.

    Please make the job easier for yourself and the success of your program, and switch to using normal maskable interrupts.

    Regards,
    RandyP
  • Hi Randy,

    Thank you for the reply. Yes agreed, NMI could crash when optimized math operations are executed, and this behavior I have observed on my system.
    To avoid use of NMI, I am now working on finding and optimizing latency for normal GPIO interrupts. And I shall update on finding.

    I have a question on option "--interrupt_threshold", will it be good idea to set interrupt threshold 1, to have lower latencies for interrupt? Will it help or cause any other issue?

    Thank you
    Shri
  • Shrikrishna B said:
    Does interruption to software pipeline (SPLOOP) instructions by NMI can cause some un-desired behavior? And if Yes, is there any precaution/implementation we need to have in place to avoid this situation?

    If an interrupt occurs while a software pipeline is executing out of the loop buffer, the loop will pipe down by executing an epilog and then service the interrupt. The interrupt return address stored in the IRP or NRP is the address of the execute packet containing the SPLOOP instruction. The TSR (Task State Register) is copied into the ITSR (for interrupts) or NTSR (for NMI or exeptions) with the SPLX bit set to 1. On return from the interrupt with the ITSR or NTSR copied back into the TSR with the SPLX bit set to 1, execution is resumed at the address of the SPLOOP(D) instruction, and the loop is piped back up by executing a prolog. ILC and RILC need to be saved/restored by Interrupt Service Routine.

    Please note there has been a known issue with earlier version of C6000 CGTools 7.4.x regarding interruption of SPLOOP which the compiler team has resolved. For details refer to :

     

    Hope this helps.

    Regards,

    Rahul

  • Hello Rahul.

    Thank you for details. I will plan a task to test NMI crash behavior with compiler 7.4.21 update, and shall update here.

    Regards,

    Shri.