• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 592 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

C674 NMI Event

A. N. Macon
Prodigy 30 points

I am using a C674 with Sys/Bios 6.34 and I am trying to set up a response to an NMI event.  I see that at one point NMIs were handled as exceptions.  I tried setting this up in my code but the processor always seems to reset when I expect the NMI function to be called.

There are many comments that using the exception handler for NMIs is a legacy.  What is the correct way to handle this?

If the exception handler is the correct way, I will provide more specifics on how I implemented that functionality.

  • 0
    TI__Guru* 81335 points

    Hi A.N. Macon,

    From my understanding, Exception handler is the correct way.

    Please refer the below threads for more information.

    http://e2e.ti.com/support/embedded/bios/f/355/t/89509.aspx

    http://e2e.ti.com/support/embedded/bios/f/355/t/247586.aspx

    Thanks for the post.

  • 0 in reply to Raja
    Prodigy 30 points

    Thanks for the response - I have determined that the error was on my board - it was putting the processor into reset when the nmi input was set.  The above threads agreed with how I was implementing the NMI hook function and once the error on the board was removed, the NMI hook function was found. 

    I am now working on the return from the NMI hook function.  It is returning to main not the location in the NRP.  I am using the example code in sprufe8 (DSP CPU and Instruction Set Reference Guide) – section 6.2.4 as the example.

    If you know of any other sources of information, I would appreciate the pointer to it.

    Thank again.

  • 0 in reply to A. N. Macon
    TI__Guru* 81335 points

    Hi A.N. Macon,

    Please refer below threads which may help you.

    http://e2e.ti.com/support/embedded/bios/f/355/t/202327.aspx

    http://e2e.ti.com/support/embedded/bios/f/355/t/292704.aspx

    Please let me know if you need further help on this. I shall move this to TI-RTOS (BIOS) forum.

    Thanks.

     

  • 0 in reply to Raja
    TI__Guru* 81335 points

    Hi,

    I have moved your thread to TI-RTOS forum to get appropriate response.

    Thanks.

  • 0 in reply to A. N. Macon
    TI__Mastermind 45025 points

    Hi ,

    Have you verified that the 3 conditions that are explained in section 6.2.4 Returning From Exception Servicing of sprufe8b are all OK?

    • SPLOOPs that are terminated by an exception cannot be resumed correctly. The SPLX bit in NTSR
    should be verified to be 0 before returning.


    • Exceptions that occur when interrupts are blocked cannot be resumed correctly. The IB bit in NTSR
    should be verified to be 0 before returning.


    • Exceptions that occur at any point in the code that cannot be interrupted safely (for example, a tight
    loop containing multiple assignments) cannot be safely returned to. The compiler will normally disable
    interrupts at these points in the program; check the GIE bit in NTSR to be 1 to verify that this condition
    is met.

    Also, please have a look at the threads that Rajasekaran provided in his last post and let us know if those helped you with your issue or not.  The second thread he points out mentions the problem with exposed pipelines and recovering from an exception - I believe this is the same issue as mentioned in the second bulleted item above.  You may also be able to try the Exception_setReturnPtr() that's also mentioned in the thread, too.

    Steve

  • 0 in reply to Steven Connell
    Prodigy 30 points

    At this point, the issue is that when none of the conditions are met, that the resume is not handled correctly.  However, since the conditions occurred so many of the times (and therefore the resume could not be handled) we are looking into another way to handle the desired functionality.  Thank you for your help.