• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 2561 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: ARM Undefined Instruction Abort Handler

Mike Ashman
Intellectual 430 points
Part Number: TMS570LC4357

Hello, Is there an example undefined instruction abort handler available? I am causing an undefined instruction exception (purposefully for testing reasons) and I have an assembly code handler which is invoked upon the exception as expected. I would like to figure out the address where the undefined instruction occurred. Currently I look at the LR  (R14_UND) and that instruction address is not correct. If I look at the R14_USER register that contains the instruction address I would have expected. In the handler My CPSR mode = 11011 (undefined) as expected.

How would I determine the instruction where my fault occurred in this undefined instruction exception handler?

  • 0
    TI__Guru**** 186206 points

    Hello Mike,

    The address that causes the undefined instruction exception can be calculated from the R14 or R14_UND:

    1. If the instruction is 32-bit: the address is R14-0x4

    2. If the instruction is 16-bit: the address is R14-0x2

    My example: I trigger this error using calling a floating instruction after VFP is disabled. The instruction caused the UNDF is vmov(...) at 0x00004294 (disassembly window)

    The R14 and R14_UND is 0x4294+0x4=0x4298 (register window)

  • 0 in reply to QJ Wang
    Intellectual 430 points

    Thanks for the reply. I am not seeing the correct address in R14 or R14_UND. I'm causing the undefined instruction exception by trying to execute a random RAM address:

      uint32_t transferAddress = (uint32_t) 0x0800FFFF;     //undefined instruction abort
      ((void (*)( void )) transferAddress)();

    See below that this is at address x11C4D4. However in my R14 and R14_UND there is 0x08011BB4.

    In my R14_USR there is 0x0011C4D8 which is the correct instruction causing the fault. If in my interrupt handler I switch to System mode I can then read the R14 (R14_USR) register to get the address but it doesn't seem to be stored in R14_UND as I would expect or as how it happened in your example.

  • 0 in reply to Mike Ashman
    Intellectual 430 points
    I find that if I cause an undefined instruction by executing this line in my C code
    __asm(" UDF #0");
    I end up in my undefined instruction handler and the LR and LR_UND DO hold the correct address, and that I do not need to switch to system mode.
    I'm not sure why that isn't the case when I cause an undefined instruction exception with
    uint32_t transferAddress = (uint32_t) 0x0800FFFF; //undefined instruction abort
    ((void (*)( void )) transferAddress)();
  • 0
    TI__Guru 59540 points

    Hello Mike,

    The abort related information is in the CP15 fault status registers. This includes the  Data Fault Status Register (DFSR),  Instruction Fault Status Register (IFSR), the associated Auxiliary fault Status Registers for data faults and instuction faults (ADFSR and AIFSR), Data fault Address Register (DFAR), and, finally, the Instruction Fault Address Register (IFAR). Of course, since you are implementing an instruction fault, you would be most interested in the IFSR, AIFSR, and IFAR registers. Details about all of these and the bit encodings within them are included in the ARM Cortex-R5F TRM starting with section 4.3.20.Here is a link to the TRM on the ARM website: 

    For the downloadable PDF version:

    For the online version: 

    In conjunction with the information in these registers, the offending instruction address should be able to be captured in the R14_abt register. 

    The TRM also includes a section on handling of undefined instructions if the handler is required to return after the instruction that caused the exception. This description is in section 3.8.6 of the TRM.