• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 595 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.

How to get the contents of XARn register?

Ted Lee57324
Prodigy 180 points

Hi there,

We are currently developing the controller using F28335.

And I'm implementing the Watchdog ISR code.

In my WDT ISR code, I'd like to capture the address where the watchdog was occurred.

I'll show the example code for your better understanding.

Here is the test code that will trigger the watchdog timeout.

Now, program flow will jump to the WDT ISR from the address 0x33AAB4

And, here is my WDT ISR code.

Now, I'd like to store the address "0x33AAB4"

I found the fact that return address should be saved into XAR7 during interrupt handling process.

(Table 3-3(p.3-15) & Example3-1(p.3-16) from SPRU430E "TMS320C28x CPU and Instruction Set Reference Guide")

Is that always true? If yes, how can I copy the contents of XAR7 into my global variable?

Unfortunately, I don't know the first thing about the C28x asm code.

So, could you tell me the exact code?

Thanks.

 

  • 0
    Genius 4925 points

    Hi,

    here the code to save XAR7 content. Given you defined the global variable test in you C environment 

    asm(" MOVW DP,#_test"); //load the accurate datapage
    asm    (" MOVL XAR6, #_test");     //reference the adresspointer of variable test
    asm    (" MOVL *XAR6, XAR7"); //store the content of XAR7 into the variable pointed by XAR6

     

     

    best regards

    Andreas

    However I am not sure if XAR7 is always used to save the return address, I guess it can be stack or simply RPC too...

  • 0 in reply to andreas von kaenel
    TI__Guru* 91990 points

    A couple of thoughts.

    It can be dangerous to change the CPU registers using inline asm() statements.  I strongly discourage this.

    For an interrupt the return PC will be pushed onto the stack.  Andreas is correct that it isn't always in XAR7 - this may just be luck in this case. The stack contents on an interrupt are described in the CPU guide www.ti.com/lit/spru430

    Also if this is just for visual inspection, you can step through the watchdog interrupt and when it returns the PC will go back to where the interrupt was taken.

    Cheers,

    Lori

     

  • 0 in reply to Lori Heustess
    Prodigy 180 points

    Thanks Lori (and also thanks to Andreas)

    As I mentioned in my question, your SPRU430 shows it.

     

    Which means that "7th save operation" will do the saving process of return address.

    And on next page in your SPRU430,

    As I know, above context saving process is included in your start-up code and I can't modify it.

    So, from above two pictures, I concluded that the address where the WD timeout is occurred should be stored in XAR7.

    (Unless my WDT ISR code does not use XAR7 register.)

     If my understanding is totally wrong, then how can I get that address?

    I'd like to store it without emulator. (Actually, I'll check that information through the CAN or SCI communication)

  • 0 in reply to Ted Lee57324
    Genius 5885 points

    Hi Ted,

    I am sorry to notify you but your understanding it totally wrong.

    The context and return address are stored on stack. Table 3-3 only says that return address is stored on stack on seventh(7) cycle since interrupt has been acknowledged by CPU. Example 3-1 shows how to store additional CPU registers (on stack), that were not automatically by the CPU. Beware that the example is only valid for non-FPU targets.

    Where exactly on the stack depend on your interrupt entry code. If you do not have any extra code then return address is on top of the stack. But if you have some interrupt entry code locating return address placement on stack becomes somewhat more difficult. If your interrupt functions are written in assembly it is easier, because C-compiler automatically generates this code, and the generated code differs for FPU and non-FPU targets and is different wheather you have any function calls or not within your interrupt routine. And you are correct on the fact that you can not modify compiler generated interrupt entry code.

    Lory's warning about not modifying CPU registers with inline assembly deserve a little comment. While I completely agree with her it is smart to check your code against C/C++ compiler register conventions (SPRU514 -still from 2007, chapter 7.2) in order to assure that your inline assembly does not break any of the conventions.

    How can you access the data on stack is a different issue, which if I recall correctly has already been covered somewhere on these forums (but maybe it was on previous forums which I don't think were archived)

    Regards, Mitja