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

Location of data abort

dominik schuierer
Intellectual 350 points


Sorry, but this drives me crazy... I´m using an TMS 570Ls20216...

I´ve implemented a simple data Abort handler, which looks like this:

#pragma

INTERRUPT (dataAbortHandler, DABT)

void dataAbortHandler(void)

{

dataFault=_coreGetDataFault_();

dataFaultAddress=_coreGetDataFaultAddress_();

dataAuxFault=_coreGetAuxiliaryInstructionFault_();

_coreClearDataFault_();

asm(" B #-8");

}

 

All i want to know is, where in the source the abort happened, but "datafaultaddress" only returns nonsense values. I suspected me thinking wrong (maybe this value represents the location of the data memory which is wrongfully accessed) and added a "_coreGeIintructionFaultAddress_" but that result made even less sense at all.

What´s wrong?

 

best regards

Dominik

 

  • 0
    TI__Mastermind 23000 points

    Hi Dominik,

    How have you configured your memory in the MPU?  If using normal or device memory, there is write buffering enabled on data accesses.  This means that the access returns an "ok" signal to the CPU as soon as the transaction hits the write buffer and the CPU advances to the next instructions.  If there is an error on the transaction after the write buffer, the CPU will take a data abort but the address of the transaction may not be available because of write buffering.  

    This situation is called an asynchronous or imprecise abort. Effectively you are trading off speed of buffered writes for the potential of asynchronous results if something goes wrong.  As noted in the ARM R4F TRM, the DFAR is only valid for precise aborts.  I can't say for sure this is the issue you are seeing, but it is worth investigation if you believe your code is correct.

    Regards,

    Karl

  • 0 in reply to KGreb
    Intellectual 350 points

    Thanks for explaining the details! I think i got a better understanding for the underlying mechanism.

    Right now my problem changed to "prefetch_abort" so i have to wait for hunting down _that_ data abort problem....