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

TMS570LC4357: Data Abort (DABT) when debugging

Peter Schmidt
Prodigy 10 points
Part Number: TMS570LC4357


Hello,

I've have the following question:

we try to debug the Cortex R5 with a Lauterbach Debugger for Cortex-A/R (ARMv7 32-bit).

When stopping at a breakpoint and resuming afterwards, we always get a Data Abort (DABT) exception that we don't understand. Without any breaktpoint the SW works fine. So there is no illegal access to memory location from within the SW under test.

Does anybody has an approach to solve this problem or having seen the same a similar relation between debugging and DABT exception?

Kind regards,

Peter

  • 0
    TI__Guru**** 198766 points

    Hi Peter,

    Please take a look at my app note here:

    http://software-dl.ti.com/hercules/hercules_docs/latest/hercules/FAQ/FAQ.html#troubleshooting-abort-exceptions

    What is the value of C15 DFSR Register?

    Are you able to capture the R14_abt? You can find the address (R14_abt - 0x8) which generates the data abort if the data abort is precise abort. 

  • 0 in reply to QJ Wang
    Prodigy 10 points

    Hello QJ,

    thanks for your answer! Meanwhile, I found out why the data abort exception occurs: somehow, by setting the breakpoint, the register R14 containing the return location is overwritten during a function call. By this, when reaching the return instruction, the code jumps to any other code wherein wrong parameters lead to writing to illegal memory location.

    So the question is now, why does the debugger in my eyes "overwrite" the R14 and thus corrupts the correct execution of code.

  • +1 in reply to QJ Wang
    Prodigy 10 points

    Hello QJ,

    thanks again for your answer! We actually found out, that we have a stack issue in our code and that the problem was on our side. When the debugger handles a breakpoint, it does that by using a dedicated exception stack segment which is (erroneously) used by our stack as we provoke an stack overflow when debugging.

    So this issue is resolved. May the comments nontheless help somebody else in future not making the same mistakes.

    Kind regards, Peter