• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1253 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.

RE: data abort handler example available?

Allen Hamedany
Prodigy 10 points

Christian:

Although this is an (2+ yrs.) old post, I ask whether:


Currently, on arm7 (AM335x), the core produced from abort does NOT contain valid stack trace.

LR (R14) in the abort/SIGABRT handler, does NOT contain the address of the function where the fault occurred.

In your example above, does the LR returned to the C handler --by the Assembly handler-- contain this info?

If not how can the address of the faulty function be obtained?

PS: please specify any specific arm-arago-linux-gnueabi-gcc options needed too.

If you're familiar w/libunwind for arm7, would it produce a useful stack trace?


I appreciate your help.

Allen

  • 0
    TI__Guru 69070 points

    Allen,

    I split your thread from RE: data abort handler example available? and moved it to Sitara's forum, since you reference the AM335x running linux.

    I don't understand your reference to ARM7 unless you mean the ARMv7-A/R architecture and not the ARM7 CPU (like ARM7TDMI).  The AM335x has a Cortex A8 CPU so want to make sure this is the right part.

    The data abort is probably quite different on a device like the AM335x so I wouldn't confuse the issue by asking on the Hercules forum.  The Hercules part is a Cortex R series and this doesn't have virtual memory so the data abort means something more like a critical system error rather than perhaps something else in a bigger system.  So best to ask in the context of Sitara.

  • 0
    Mastermind 8040 points

    On a Cortex-A8 you only get useful "synchronous" external aborts for

    1. instruction fetch
    2. loads from non-cacheable, device, or strongly-ordered memory
    3. stores to strongly-ordered memory
    4. loads to PC or CPSR
    5. loads that use SWP/SWPB (but not the store-part thereof unless strongly-ordered)

    In all other cases, you get an "asynchronous abort" which offers absolutely zero useful information, it basically just says "something went wrong. no idea what. good luck with that!"

    I have no idea what memory type linux uses if you map some piece of /dev/mem into a userspace process (which I assume you're doing), nor what kind of access in your code causes the abort, but unless it's one of the cases above then linux has no way of knowing where in your code the abort was triggered, nor which kind of memory access, nor the memory address involved.

    In case of a synchronous abort, I would expect that you get a valid stack trace, but I haven't tried this.

  • 0 in reply to Anthony F. Seely
    Mastermind 8040 points

    Anthony F. Seely said:
    The Hercules part is a Cortex R series and this doesn't have virtual memory so the data abort means something more like a critical system error rather than perhaps something else in a bigger system. 

    I'm assuming he's getting an external fault from a peripheral, so I think that would work the same on the Cortex-R ? Exceptions from the virtual memory system would result in a SIGSEGV (and a useful stack trace, since those exceptions are always synchronous), not a SIGBUS.

    EDIT: I misread his original post, I'm now not sure what he means since I think SIGABRT is only triggered by software (e.g. abort()), no "data abort" or anything else processor-specific about that at all.