• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 708 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.

TDA3MV: TDA3x Floating-Point-Exception

ROGERG
Mastermind 36320 points


Dear Experts,

my customer is facing below issue related to a Floating-Point-Exception:

TDA3x is used in combination with an external uC. This external uC triggers a reset when running into below described issue.
Further analysis of the crash dump revealed that the reset on the MCU was triggered by an FPE (floating point exception).

This FPE was automatically triggered by the FPU of the MCU during read access of a float value that corresponds to a NaN (Not) according to the IEEE754 Single Precision specification.

The specific objected value is part of an object list structure that was sent from the TDA3x DSP to the MCU via the inter-processor communication (IPC) and has the value 0x7FFFFFF in hex format,
i.e. Except for the sign bit, all exponent and mantissa bits are set.

Since this access is the very first one on MCU side and the CRC checksum calculated for communication integrity was correct, it can be ruled out that this value was written by the MCU, instead it has to be "packed" on the DSP side this way already.

Question is whether it is possible to generate such a float result by a float calculation on the DSP side (e.g. float division by a very small value close to 0)?
In the case shown, we would have expected an INF as a result rather than NaN (the difference being that all mantissa bits would be 0 instead of 1).

Could You please help to clarify this?

Many thanks and best regards,
Gregor

  • 0
    TI__Mastermind 36320 points

    Dear Experts,

    I also checked the C66x CPU and Instruction User Guide. In Section 3.3.1 there is also a table containing the 0x7FFF_FFFF value handling it as QNaN in decimal.

    Could You please let me know which Float calculation could result in such a value?

    And is there a way to issue a Signaling NaN instead of a Quiet NaN, so exception could already be captured on DSP side instead later on MCU side?

    Many thanks and best regards,

    Gregor