• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 335 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.

AM2634: PABT Exception. Instruction In Non-Existent Memory.

Kier
Mastermind 8845 points
Part Number: AM2634

Hello,

After running my multi-core program, Core 1 has a Prefetch Abort Exception (PABT) as shown by offset 0xC in the exception table:

The reason is because there is an attempt to execute an instruction located in non-existent memory, address 0xEA0008A, shown in the IFAR:

I guess it could be a corrupt function pointer and fortunately it is always the same problem address.

In the case of an MPU error or Undefined Instruction exception, the IFAR would contain the address of the offending instruction (I think) which I could look up in the map file to see in which input section the problem was located. But in this case, it is the instruction address itself that is non-existent. 

How can I determine the point in my program which immediately precedes the fetch from the non-existent address please? Any tips would be appreciated. The debugging guide (SPRAD28) gives no advice on this specific situation.

  • 0
    TI__Guru**** 196306 points

    Hi Kie,

    I am working on your question, and will come back to you later today. Thanks

  • 0 in reply to QJ Wang
    TI__Guru**** 196306 points

    I would suspect a stack overflow issue, where the return address from a IRS or other function call got overwritten with this value. Can you also post a screenshot of the other CPU registers for the abort mode (SPSR_abt)?

  • 0 in reply to QJ Wang
    Mastermind 8845 points

    Thank you for the reply.

    I stumbled* upon the cause earlier today. The exception table was being initialized with garbage handler pointers.

    *This is the nub of the problem. I just happen to find the cause by checking some usual suspects. The question still remains how I might find the cause mechanistically. From your reply, I infer that there isn't a better method than trial and error. That's OK I suppose as long as I'm not missing a trick.

  • 0 in reply to Kier
    TI__Guru**** 196306 points

    Hi Kier,

    The reason for Prefetch Abort can be analyzed, as you did, by reading the Instruction Fault Status Register (IFSR), the Instruction Fault Address Register (IFAR), and the Auxiliary Instruction Fault Status Register (AIFSR). IFAR contains the address where the CPU was trying to fetch an instruction from. 

    The 0xEA0008A is not a valid address for the code instruction, and possible reason is stack overflow. The SPSR shows in which mode does the CPU operates when the abort was triggered: IRQ, FIQ, System, etc, so we can try larger stack size in linker cmd file for this mode. I don't know any better way.

     

  • 0 in reply to QJ Wang
    Mastermind 8845 points
    QJ Wang said:
    possible reason is stack overflow.

    Possible, yes, but not in this case. As I mentioned the cause was an incorrectly initialized exception table.

    I think this can be closed now since it is clear that only trial and error can determine the root cause.