• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 957 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.

Prefetch Abort and IFAR Update

Pashan None
Genius 5660 points
Other Parts Discussed in Thread: TMS570LS0432

Hello Support,

For TMS570LS0432 device, when Prefetch Abort occurs, is it always Cortex-R4 IFAR Coprocessor Register will be updated with INSTRUCTION ADDRESS which caused the PREFETCH ABORT?

Please let me know what is the expected behaviour of

c6, Instruction Fault Address Register

during Prefetch Abort within the CODE.

Any information related to this register update mechanism will help me debug my code easily.

Thank you.
Regards
Pashan

  • 0
    TI__Expert 4580 points

    We have received your post and we will be back to you soon.

    Regards.

  • 0
    TI__Mastermind 23000 points

    Hello Pashan,

    I would expect the feature to behave as documented by ARM in the R4 TRM.  As stated in ARM DDI0363G, P. 4-51, "Purpose - Holds the address of the instruction that caused a prefetch abort".  Are you seeing some other behavior?

    I am not sure what you mean by "update behavior."  Can you please clarify what you are looking for?

    Regards,

    Karl

  • 0 in reply to KGreb
    Genius 5660 points

    Hello Karl,

    In my code there is a instruction within FLASH Space

       BX   R0

    where R0 = 0x140000   which is an invalid memory space.

    So, Prefetch Abort occurs as expected. But inside Prefetch Abort when I read IFAR, the value returned as 0x140000.

    I was thinking it will be the address of OPCODE "BX R0" within Flash Space and hence I can debug easily.

    Essentially how to get last known good instruction address instead of future instruction address when Prefetch Abort occurs?

    That's why I asked the question.

    Looks like PREFETCH ABORT doesn't help to locate the BUG in the code easily until and unless there is some instruction trace is available within PREFETCH ABORT.

    Also, another question :

    DATA ABORT updates DFAR for Synchronous Abort only.
    DATA ABORT never updates IFAR for any data abort [Synchronous or Asynchronous].
    Are the above two statements correct? In the ARM TRM r1p3 within IFAR section it never said that DATA ABORT doesn't update it. Hence the question.

    Your valuable comments will be helpful for my understanding better.

    Thank you.
    Regards
    Pashan

  • 0 in reply to Pashan None
    TI__Mastermind 23000 points

    Hi Pashan,

    In your example, the ARM is behaving correctly per specification.  There is no fault in the branch instruction.  The code correctly branched to the location you requested, so the instruction is architecturally complete.  The fault occurred when it tried to execute the first instruction fetch from the branch target location.  The IFAR is correctly storing the address where the current instruction fetch has faulted.

    As to finding the previous instruction executed before a fault, you have a few options - examining the stack, examining the branch link register, examining the return program counter (for branch speculation), etc.  Not all options are useful in all cases, such as the program flow discontinuity you note.  Another option is to use the ARM ETM to provide an instruction trace of the path the software has taken through the code.

    Regarding your second question, I see no reason to doubt the ARM TRM.  The IFAR is for instruction faults (prefetch abort).  A data abort is a data fault.  If the data abort is on a synchronous fault, then I would expect that the DFAR is updated with the address of the faulty access.  If the data abort is on an asynchronous fault then the address is not known by the CPU so it cannot update the DFAR.

    If you are having a lot of questions of this nature, I would recommend that you read the ARM v7A/R architecture reference manual.  This document provides a lot of the theory and background rationale behind the design decisions in the CPU which we are now discussing.  It is a long read and quite dry, but worth it.

    Regards,

    Karl

  • 0 in reply to KGreb
    Genius 5660 points

    Hello Karl,

    You mentioned the following :

    " examining the return program counter (for branch speculation)"

    in your last mail.  Can you please elaborate somewhat more on this one point? Especially what register should I see for debug purpose. I am assuming you are not talking about PC or LR Register.

    Thank you.
    Regards
    Pashan

  • 0 in reply to Pashan None
    TI__Mastermind 23000 points

    Hi Pashan,

    I meant to refer to the return stack (see section 5.3 in DDI0363G) but misnamed it in my post.  Unfortunately I think these buffers are not visible from a debugger view, but can be helpful if using a simulator where they are visible.

    Regards,

    Karl