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.

AM5716: MATHLIB_RTS_C66X issue

Part Number: AM5716
Other Parts Discussed in Thread: MATHLIB, , OMAP-L138

The main.c file in my CCS project is as follows:

#include <math.h>

void main(void)
{
    // This function call will not return.
    float result = fmodf((float)90.0, (float)45.0);

    // This divide is here simply to cause divsp to be linked from mathlib_rts.ae66.
    // If you comment out this line, mathlib_rts.ae66 will not be used, and the fmodf() call will return.
    float test = result / (float)1.0;
}

I have found that the fmodf function from the RTS library (C:\ti\ccsv7\tools\compiler\ti-cgt-c6000_8.2.1\lib\rts6600_elf.lib) will never return when certain arguments are provided to the function. I have only seen this happen when the return value of the function would be zero (i.e., the remainder of the division is zero). I have not seen this happen when the __c6xabi_divf function from the RTS library is linked into the executable -- I have only seen it happen when the divsp function from the MATHLIB_RTS library overrides the __c6xabi_divf function. Perhaps it has something to do with the precision of the MATHLIB division function versus that of the RTS library division function.

I'm hoping that TI can reproduce this using my CCS project and confirm whether or not there is a workaround for the bug. Thank you in advance for your assistance.

Best regards,
Dave

  • The RTOS team have been notified. They will respond here.
  • Hi,

    To make sure I understand the problem, with certain input values, if there is call to divsp after fmodf, then fmodf will not return. If there is no division call or a call to __c6xabi_divf after fmodf, then fmodf does return. Is that correct? thanks.

    Yimin

  • Hi Yimin,

    For the problem to occur, it is not required that there be a call to divsp after fmodf -- the only requirement is that the divsp function from the MATHLIB_RTS library overrides the __c6xabi_divf function from the RTS library.

    The reason I have the divide in the test program is because I found that the divsp function from the MATHLIB_RTS library will not override the __c6xabi_divf function without that divide. No matter how you do it, as long as the divsp function from the MATHLIB_RTS library is overriding the __c6xabi_divf function from the RTS library, the function call fmodf((float)90.0, (float)45.0) will not return.

    In other words, for the problem to occur, you need to see the following in the .text output section in the linker map file:

    mathlib_rts.ae66 : divsp.oe66 (.text)

    I hope that clears things up, but I'm happy to answer any more questions that you have.

    Thanks,
    Dave

  • For reference, I have been able to reproduce this bug using these combinations of processor, compiler, and MATHLIB:

    Processor Compiler MATHLIB
    AM5716 8.2.1 C66X-MATHLIB 3.1.2.1
    C6674 8.2.1 C66X-MATHLIB 3.1.2.1
    C6674 7.4.6 C66X-MATHLIB 3.1.1.0
    C6713 7.4.6 C67X-MATHLIB 2.1.0.0
    OMAP-L138 7.4.6 C674X-MATHLIB 3.1.0.0
  • Thank you for the detailed description of the issue and also for providing the test project to reproduce the issue. We apologize for the delay in getting back to you on this issue due to lack of resources.

    We are currently looking at this issue and working with the compiler team to root cause the issue and provide a fix. We will post a response in the next 1-2 days.

    Regards,
    Rahul
  • Just to post an update on this. We have been able to reproduce the issue with CGT 7.4.16 and CGT 8.1.0 and have reported it to the development team. We have not yet been able to root cause the issue to provide a fix due to departure of a key developer for this library from TI.

    I will work with the team to provide you a more accurate timeline for resolution of this issue.

    Regards,
    Rahu
  • Hello Rahul, I'm glad that you have been able to reproduce it on your end. Thank you for the updates so far, and please continue to keep me posted.

    Best regards,
    Dave
  • Hello again Rahul, I was wondering if you have any updated information on the timeline for resolution of this issue?

    Thanks,
    Dave

  • Dave,

    I am following up with the development team on this issue. Due to loss of a key developer for this library, they don`t have a new release coming up in the first half of this year. At the moment their release is planned to coincide to align with 3Q2018 release.

    Please let us know if this schedule doesn`t work for you and we can try to see if we can priority on this issue to provide you with a patch rather than address this with a full release.

    Regards,
    Rahul
  • Rahul, I have been able to work around the issue for now by calling fmod() instead of fmodf(). Fortunately, this call is not in a particularly time-critical part of our code, so this workaround is acceptable. I would still like to go back to using fmodf() eventually, but I can wait for a full release to do so. Is there an issue number that I can use for tracking the fix?

    Thanks,
    Dave