• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 651 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.

TMS570LS0714: How to handle data abort / custom data abort ...

v01d
Expert 2055 points
Part Number: TMS570LS0714


I have abort generated from , seems, trying to access it seems, an unused/uninitialized flash  through memmapped direct address, for reading. Ignoring that specific reason, how do I handle properly the data aborts ..?

So the provided _dabort, in case of no RAM error and no flash error, jumps to custom_abort which is left blank by TI & I have to implement. 

..which is left empty by default.  I'm not sure what to do there, and , if I can recover / return from this into a usable system.  So in my specific test case,  it returns, right back into the same instruction which caused the abort, and tries again, and thus is stuck in the infinite loop. E.g.:

Abort due to that memory dereference. 

I don't know if I should have some proper handler here, in a general way.

  • 0
    TI__Guru**** 198766 points

    Hi,

    The handler can not do anything if it doesn't know the root cause of the data abort. 

    Adding a while(1) loop and breakpoint will alert you to the abort issue, then You need to check the CP15 registers and MCU general registers to figure out which instruction generates the abort.

  • 0 in reply to QJ Wang
    Expert 2055 points

    QJ Wang said:
    The handler can not do anything if it doesn't know the root cause of the data abort. 

    Understand, and in this case that would be attempt to _read_ from invalid address.

    QJ Wang said:
    ut which instruction generates the abort.

    I know what it is here, i showed above, but C , however is the asm equivalent of trying load register from invalid memory. 

    I think my main question is, can & should I be gracefully recovering from this? As custom abort handler doesn't appear to be fatal to the whole system. If in this case, I have a say separate thread doing something illegal as here, it seems the rest of software system still running ok, and not affected.

  • +1 in reply to v01d
    TI__Guru**** 198766 points

    If you know which instruction causes the data abort, you can jump to the next instruction in the custom abort ISR. But the issue is not solved. It's better to dig the root cause out first.