• State Suggested Answer
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 347 subscribers
  • Views 75 views
  • Users 0 members are here
Options
Related

Synchronous FPU Exception in Cortex R5

Aswin Sankar

Hi expert,

I am working with a Cortex-R5F (specifically the TI AM263P4 SoC) and I am trying to determine the exact instruction address (PC) that causes a floating-point divide-by-zero.

Current Setup:
  1. I have enabled the DZC propagation bit in the Secondary Auxiliary Control Register (c15, Bit 9).
  2. I have configured the VIM (Interrupt Controller) to catch the FPU exception signal.
  3. The interrupt triggers correctly when a division by zero occurs.
The Problem:
Because the FPU pipeline is decoupled and the exception is imprecise/asynchronous, the CPU "slips" and executes many instructions past the faulting one before the ISR is entered. Consequently, the Link Register (LR) in my ISR does not point to the actual instruction that caused the error, making it impossible to debug the root cause in complex codebases.
My Questions:
  1. Is there any architectural configuration for the R5F to force a synchronous trap (Data Abort or Undef) specifically for FPU exceptions?
  2. If the FPU is strictly non-trapping, is there a recommended hardware feature that can capture the faulting instruction address?
  3. Is there any way I can make the CPU wait till FPU is done, so that the once ISR fires, the PC will be at the instruction that caused the issue?

Your feedback would be extremely helpful.

Thanks & Regards,

Aswin

Parents
  • 0 Arm Employee Badge
    Aswin Sankar said:
    Is there any architectural configuration for the R5F to force a synchronous trap (Data Abort or Undef) specifically for FPU exceptions?

    There is an optional feature defined in the Armv7-A/R architecture, but it's not supported on the Cortex-R5F:
    https://developer.arm.com/documentation/ddi0460/d/FPU-Programmers-Model/Compliance-with-the-IEEE-754-standard/Exceptions?lang=en

    Aswin Sankar said:
    If the FPU is strictly non-trapping, is there a recommended hardware feature that can capture the faulting instruction address?

    It's not a problem I've thought about before, others might be able to chime in with suggestions.  What I've seen before is periodically checking the cumulative exceptions bits in FPSCR.  That's polling rather than interrupt based, but it constrains the region the divide could have been to the time between samples.

    Are you trying to locate the error to debug or are you trying to recover in some way?

    Aswin Sankar said:
    Is there any way I can make the CPU wait till FPU is done, so that the once ISR fires, the PC will be at the instruction that caused the issue?

    No - the CPU doesn't "know" where the signal is going or what the destination is going to do about it, therefore it has no way to know how long to wait.  Also from a performance point of view, I suspect it would be better to sanitise the inputs to divisions or frequently poll FPSCR.

Reply
  • 0 Arm Employee Badge
    Aswin Sankar said:
    Is there any architectural configuration for the R5F to force a synchronous trap (Data Abort or Undef) specifically for FPU exceptions?

    There is an optional feature defined in the Armv7-A/R architecture, but it's not supported on the Cortex-R5F:
    https://developer.arm.com/documentation/ddi0460/d/FPU-Programmers-Model/Compliance-with-the-IEEE-754-standard/Exceptions?lang=en

    Aswin Sankar said:
    If the FPU is strictly non-trapping, is there a recommended hardware feature that can capture the faulting instruction address?

    It's not a problem I've thought about before, others might be able to chime in with suggestions.  What I've seen before is periodically checking the cumulative exceptions bits in FPSCR.  That's polling rather than interrupt based, but it constrains the region the divide could have been to the time between samples.

    Are you trying to locate the error to debug or are you trying to recover in some way?

    Aswin Sankar said:
    Is there any way I can make the CPU wait till FPU is done, so that the once ISR fires, the PC will be at the instruction that caused the issue?

    No - the CPU doesn't "know" where the signal is going or what the destination is going to do about it, therefore it has no way to know how long to wait.  Also from a performance point of view, I suspect it would be better to sanitise the inputs to divisions or frequently poll FPSCR.

Children
No data