• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 88 subscribers
  • Views 517 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.

TMS320F28P650DK: float division with subsequent conversion to integer gives wrong result

Oleh Sharuda
Prodigy 10 points

Part Number: TMS320F28P650DK

Dear TI Support,

We’ve found some incorrect behaviour of C generated code for f28p65x MCU. This problem reproduces on TI LaunchPad kit with F28P65x C2000 real time MCU.

The problem: the following legal C code is executed incorrectly:

float x = -10.0;
int64_t result = x / 0.1f;

On output result variable contains 0, while it should be -100 (convertion from float to integer is legal C operation until value can be fit onto integer type range)

A very simple project (may be run on launchpad for f28p65x) is attached to the ticket. When run on the launchpad (without debugger/jtag connected) it starts to blink red and green LEDs in counterphase. However if suspected code is stepped in debugger, then correct result is obtained and it starts to blink with green light only.

Some details:

1. Key compiler flags (other flags may be found in attached project properties):

--cla_support=cla2

--float_support=fpu32

-Ooff

--fp_mode=relaxed

--fp_reassoc=on

--define=DEBUG

--define=CPU1

--define=RAM

--define=generic_ram_lnk

--abi=eabi

2. Related code is executed from the RAM (it is a requirement for bootloader purposes). Convertion code (__c28xabi_ftoll) is also executed from RAM. You may see it either in attached project (built project includes assembler listing) or attached screenshots from debugger.

3. When code is executed from FLASH, problem can’t be reproduced, only when executed from RAM. When executing from RAM, reproduction rate is 100%. We tried on two kinds of f28p65x MCU: f28p650dk6pzp and f28p650dk9nmr (launchpad) - problem happens on both chips.

4. Compiler version: TI v22.6.1LTS (Linux)

CSS Studio version: 20.0.2.5_1.6.2 (Linux)

 

We suspect it is a compiler issue where pipeline restrictions for DIVF32 instruction are not respected. 

For example: if intermidiate float variable is used after division and before conversion, problem can’t be reproduced: in this case compiler insert 4 NOP instructions (as it shown in “TMS320C28x Extended Instruction Sets Technical Reference Manual”)

However without having intermediate variable these NOP instructions are not inserted (LCR followed immediately by DIVF32 instruction).

Also, note that very first __c28xabi_ftoll instruction reads result of the division from R0H register, which seems to be not ready by this moment.

Please, consider our observations and give us some suggestion or advice how to handle or fix this problem properly correctly.

Test project: DIVF32_Test_Project.zip

Disassembled code:

main_asm.png__c28xabi_ftoll_asm.png

Example for DIVF32 from "TMS320C28x Extended Instruction Sets Technical Reference Manual" documentation:

Extended_Instruction_Sets_Technical_Reference_Manual_DIVF32_Example.png

  • 0
    TI__Mastermind 24870 points

    Hi Oleh,

    I have looped in the compiler experts to take a look at your question.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Guru**** 253380 points

    Thank you for notifying us of this problem, and providing a test case.  I am able to reproduce the same behavior.  I filed the entry EXT_EP-13179 to have this investigated.  You are welcome to follow it with that link.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 10 points

    As I see the issue is marked as “TI Thinks Resolved”, while there is no answer how to handle the problem. TI internal ticket says that there was an internal attempt to reproduce the problem on other CPUs (not TMS320F28P650DK). I don’t think it may be an argument the problem is void.

    Anyway, the problem exist, and there is no solution suggested yet. I see just two possible options here:

    1. If it is a compiler issue: In this case I would expect this problem to not be declined, but fixed in compiler with some update/patch released.
    2. It is a silicon issue: in this case errata document should be updated. Also, some workaround should be offered. For example some new switch may be added to compiler which will address the problem. (It looks like there are some switches were already added to fix other issues: --protect_volatile, --silicon_errata_fpu1_workaround).

    So, in any case, disregarding it is a compiler issue or silicon issue, there should be some changes introduced into compiler. It is not reasonable to decline this problem just because it didn’t reproduce on some other chips. It reproduces on TMS320F28P650DK.

  • 0 in reply to Oleh Sharuda
    TI__Guru**** 253380 points

    To understand why I marked my reply TI Thinks Resolved, please see the first FAQ in the CCS Forum Usage Guidelines.  

    Because the compiler team is unable to reproduce the problem, I changed responsibility for this thread to the C28x device experts.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 40 points

    Maybe if the compiler team tries to replicate the issue on the HW platform for which it was reported, they will have more luck reproducing it?

    "Cannot reproduce issue on hardware boards for tenor or soprano devices." - that doesn't sound like a TMS320F28P650DK.

  • 0 in reply to Michal Elias1
    TI__Mastermind 19790 points

    Hi Michal,

    I’m able to replicate this on my P65x LaunchPad when running the code in RAM. The LCR to __c28xabi_ftoll causes the violation and not observed doesn’t occur when floating point conversion isn’t necessary.

    WITH CONVERSION:

     

    WITHOUT CONVERSION:

    Best,
    Matt

  • 0 in reply to Matt Kukucka
    TI__Expert 5615 points

    Michal,

    We have determined root cause and have updated details in below ticket:
            https://sir.ext.ti.com/jira/browse/EXT_EP-13233
    Please ignore the older ticket and just use above for tracking this issue.

    The issue will be fixed in the next patch release.

    Regards,
    Greg