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

Floating point exception handling

Gowdham Natarajan
Intellectual 610 points

Other Parts Discussed in Thread: TMS570LS20216

Hi,

I am using TMS570LS20216 USB development board. Now i am implementing floating point exception handling. I have done all the preliminaries for enabling the float support for cortex R4 controller. As per, ARM manual Floating point operation generates "Undefined Exception". But, when i run the code, no undefined exception has been generated.

Please let me know, is there anyone has any idea how to check this floating point exception in this board?


Thanks and Regards

Gowdham Natarajan

  • 0
    TI__Mastermind 23000 points

    Hello,

    In general, the undefined exception should be handled as noted in section 2.8.6, p. 71 of the ARM Cortex R4F TRM version r1p3.  

    Please note, this is only one of several exceptions which could be generated when using the VFP.  Can you please clarify what operation you are executing which should generated an UNDEFINED exception?

     

    Regards,

    Karl

     

  • 0 in reply to KGreb
    Intellectual 610 points

    Hi Karl,

    Please let me know how to generate undefined exception Interrupt for VFP operation. Is there any sample code to understand how to generate the Undefined interrupt.

     

    Thanks and Regards

    Gowdham Natarajan

  • 0 in reply to KGreb
    Intellectual 610 points

    For me undefined exception interrupt is not happening. Please tell me, is there any register to enable the VFP in TMS570LS USB hardware.

     

    Thanks and Regards

    Gowdham Natarajan

  • 0 in reply to Gowdham Natarajan
    TI__Mastermind 49120 points

    Gowdham,

    The ARM manual states that if you execute a floating point instruction with the FPU still disabled, this will cause an undefined instruction exception. ARM has a definition for what constitutes an undefined instruction - not all invalid instructions are identified as undefined instructions. Please refer to the ARM Architecture Reference Manual (DDI 0406) for more details.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 610 points

    Dear Sunil,

    I read the document and implemented accordingly. But, still Undefined interrupt is not happening while executing the following VFP code. Please let me know is there any wrong in my code.

    In my startup.c file i initialized the VFP and enabling coprocessor 10 and 11 in CPACR register. Next,

    /** declaring the variables ***/

    volatile float f_nINF    = 10;
    volatile float f_INF     =  0;
    float r;

    In the main, i am doing this floating point operation,

    r = f_nINF  / f_INF;

    The result of this operation should result in "Divide By Zero Undefined Interrupt". But it is not happening. Also, in FPEXC.EX is not set to 1 register.

    If my understanding is not correct please let me know.

     

    Thanks and Regards

    Gowdham Natarajan

  • 0 in reply to Sunil Oak
    Intellectual 610 points

    Dear All,

    I stuck in this. Seriously, i don't have any idea how to generate the undefined interrupt while performing Floating point operation through CCS for Cortex R4F controller (TMS570LS USB development board). Please help me in this.

     

    Thanks and Regards

    Gowdham Natarajan

  • 0 in reply to Gowdham Natarajan
    TI__Mastermind 23000 points

    Hello,

    Sorry for my delayed response, I have been out of office for a few days.

    FP divide by zero per the ARM R4 TRM should not generate an UNDEFINED exception.  

    For many of the FPU error conditions, ARM provides maskable CPU outputs which TI then combines and connects to the VIM interrupt controller.  The FP divide by zero will result in an output driven on the FPDZC CPU output if enabled, which then will result in an interrupt request on VIM line #47 (FPU interrupt).

    To generate the undefined exception in the FPU, ARM gives a few hint in the R4 TRM:

    • section 12.1.1 - "Any data processing instruction that operates on a vector generates an UNDEFINED exception." 
    • section 12.1.2 - "An instruction which attempts to access any of the registers D16-D31 generates an UNDEFINED exception"
    • section 12.3 - "When a privileged mode is required, an instruction that attempts to access a register in a nonprivileged mode takes the UNDEFINED exception"
    • section 12.3.3 - "Clearing EN disables VFP functionality, causing all VFP instructions apart from privileged system register accesses to generate an UNDEFINED exception"

    My suggestion would be to try whichever of these cases noted by ARM is easiest to generate the exception to prove your handler.

     

    Regards,

    Karl

  • 0 in reply to KGreb
    Intellectual 610 points

    Hi Karl,

    Thanks for your valuable information. As you said, i tried all the scenarios, everything works fine. I tried to get the address of faulty instruction which causes the floating point interrupt, but i couldn't. Actually, my floating point code to produce over flow interrupt is below,

                           E59FC05C LDR             R12, $C$CON33
    0x00081B4C:   ED9C0A00 FLDS            S0, [R12, #0]
    0x00081B50:   E59FC054 LDR             R12, $C$CON33
    0x00081B54:   EDDC0A00 FLDS            S1, [R12, #0]
    0x00081B58:   E59FC04C LDR             R12, $C$CON33
    0x00081B5C:   EE200A80 FMULS           S0, S1, S0
    0x00081B60:   ED8C0A00 FSTS            S0, [R12, #0]
    0x00081B64:   E1A00000 MOV             R0, R0
    0x00081B68:   E1A00000 MOV             R0, R0
    0x00081B6C:   E12FFF1E BX              R14

    After some time over flow interrupt occurs and enter into my handler function, but the interrupt is not happening immediately. that is, interrupt is not generating after executing the FMULS instruction, instead interrupt generates, after BX instruction. Because of this, i can't find out the exact instruction which causes floating point interrupt.

    Two questions,

    1. Why interrupt not happened after executing FMULS instruction?

    After my study,

              As mentioned in DDI 0406 file, "This means an implementation can detect an exceptional condition after an instruction has passed the point for exception handling in the ARM processor pipeline.Handling this condition is known as asynchronous exception handling, because the exceptional condition can be detected some time after it is generated." If Cortex R4F using asynchronous exception then, FPEXC.EX bit is set to 1. But, it is not happening. Also, Allows to access FPINST and FPINST2 register. But this is also not possible to access.

    The symptoms what i observed everything mentioned in Synchronous exception. So, I am totally confused which type of exception is carried out in Cortex R4F processor.

    My primary objective is to find the address of the instruction which causes the floating point interrupt.

    2. Is there any other way to find the faulty instruction?

    Please let me know.

     

    Thanks and Regards

    Gowdham Natarajan

  • 0 in reply to Gowdham Natarajan
    TI__Mastermind 23000 points

    Hello,

    Event signals from the ARM CPU (including the floating point interrupts) are asynchronous.  All internal aborts are synchronous.  ARM does not consider the event signals as exceptions - they are optional "information only" indicators and as such the guidance on exception in the ARM ARM does not apply.  You need to be careful to determine what is a floating point interrupt/event vs. a floating point exception.

    The interrupt request from the CPU is dispatched a minimum of one cycle after the event which is detected internally.  There will be some short delay due to the need to synch the interrupt request across clock domains at the VIM.  During this time, it is possible for the CPU execution to proceed a few instructions.  The FP interrupts must be enabled by software via the CP 15 c15 second auxiliary control register.  There is no register in the FPU which will trap the address of the instruction which generated the interrupt.  This is a limitation of the ARM CPU implementation.

     

    Regards,

    Karl

     

  • 0 in reply to KGreb
    Intellectual 610 points

    Hi Karl,

    Thanks for your valuable information.

    It is so helpful for me to finish my work at the earliest.

     

    Thanks and Regards

    Gowdham Natarajan

  • 0 in reply to KGreb
    Intellectual 610 points

    Hi Karl,

    Thanks for your valuable information.

    Thanks once again for giving useful information for me to finish my work at the earliest.

     

    Thanks and Regards

    Gowdham Natarajan