• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 104 subscribers
  • Views 2686 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C64x+ Exception Handling Context Restore

Suresh Chandresekar
Prodigy 210 points

In the TI Documentation (spru732j-"64x+ DSP CPU and Instruction Set"), there is a discussion about restoring the context after handling the exception to go back to an executable point.  The user uses some assembly (B NRP; NOP 5) and they are back to the last known point after the exception occured.  In order for that to work, the user should check if 3 bits in the NTSR are set appropriately.  If not, you cannot return. 

My question is how do I restore the context before I return? 

The documentation only states that  "Execution of a B NRP instruction causes the saved context in NTSR to be loaded into TSR to resume execution. Similarly, a B IRP instruction restores context from ITSR into TSR."

Is that really all I need to do?  I thought that we lose control of any post-processing when I issue the B NRP?  How does NTSR processing to restore the context occur then? 

I am working on a path right now to read the Exception_Status and from each of those, restore each register, then Branch to NRP.  

 

Any help is appreciated. 

Thanks

  • 0
    TI__Guru* 84110 points

    Suresh,

    The CPU & Instruction Guide SPRU732 does the best job of explaining everything there is to know about exceptions. I am not going to point you to each part of the document that talks about exceptions and exception handling, since you can search it and find those yourself. But you do not seem to have found Section 6.2.4 "Returning From Exception Servicing"; please read through that section and the others around it to understand more about exceptions.

    Why do you want to return from an exception?

    If there is not a specific situation for which you want or need to return, then the answer is: do not attempt to return from an exception - something bad happened and nothing is fixed by returning.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 210 points

    RandyP, 

         Thank you. I have been asked to research it and was wondering if it was feasible.  I see there is an option to make it so, by restoring context and branching to the NRP, when the validity of the three register fields is accounted for. 

         What I would like to know is how to read the ExceptionStatus ExcContext data and put that back into the valid registers.   There are some that shouldn't be touched or restored, such as the possibly the return register (B3), because the Exception Handler hook function might require the use of that to return to the Exception.c executable code in the XDC.  

         It sounds like the rest of the system might be in an unknown state at the time and we should determine if developing the code to perform the recovery is within our budget.   Obviously, task restarts or soft resets could have a need for persistence of data, which means extra code to restore the persisted data from task/program after restart. 

         Thank you.

     

  • 0 in reply to Suresh Chandresekar
    Intellectual 955 points

    @RandyP: Maybe the OP is doing something like I did quite some time ago:

    Trying to "export" the exception info out of the system. One might need other processes for that.

    @OP, Do you use an OS?

    Some OSes don't handle exceptions right.

  • 0 in reply to turboscrew
    Intellectual 880 points

    Was this answered?  I have the same problem where I want to recover from an exception.  I have a multi-threaded application, but using the information from this post (and the documentation), I wasn't able to recover without crashing. 

    Do you have a multi-threaded example with exception recovery on the C64x+? 

    Thanks,

    Will

  • 0 in reply to ixworks
    Intellectual 955 points
    As such, recovering from an exception is really the same as returning from interrupt, except the two registers.
    In my case, the problem was the OS - and use of interrupt process. It didn't support exceptions. The returning was done as it was done from interrupt. And the OS saved the context before going to the interrupt process (and restored the context when returning) one could do nothing to fix the situation within the interrupt process.

    My solution was to write my own exception handler routine that stored the context and then "called" the interrupt process. On return it got back to my exception handler and returned (the right way) from there.

    The context was stored in a specific place from where the context was dumped by a crash handling process.
  • 0 in reply to turboscrew
    Intellectual 880 points
    Turboscrew, thanks. I'm guessing when you say "OS", that if our project has the BIOS enabled, and configured, we're done. is this correct?

    Was yours a multi-threaded application when you got this to work? I've seen some varied success with single-threaded only.
  • 0 in reply to ixworks
    Intellectual 955 points

    Actually no. And the OS was OSEck (4.x I think).
    And I confused with another thing in that the interrupt task didn't return to the exception handler, but after storing the context, the exception registers were written to the interrupt registers before calling the interrupt process. That kind of changed the exception to interrupt.

    It was a multi-threaded application, although in OSEck the threads were called processes. They were threads, really, because the only local resource was the stack. All the global variables were accessible by every "process".