• State Answer Suggested
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 1804 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.

Compiler/TMS320F28069F: TI 16.9.1.LTS - Simple if statement does not work under particular optimizations.

stomp
Genius 4705 points

Part Number: TMS320F28069F
Other Parts Discussed in Thread: MSP430F5529

Tool/software: TI C/C++ Compiler

Hi,

Just found an issue with my application, upon inspection seems the compiler is doing something very strange.

Device is TMS320F28069F, Compiler is 16.9.1.LTS on CCSV 7.1.0.00016. -O = 2

Please note I have -O = 2.  This is required for InstaSPIN.

So the code always evaluates this particular if statement as true:

For reference the enum values are:

EST_State_Idle = 0x01;

Est_State_MotorIdentified = 0x0C;

The variable sInstaSPIN.sStates.estState is located at 0x00008CB3 (which is 0x008C40 + 0x73)

I can set -O =0 and the application logic works correctly.

Any help would be great, thanks.

Stomp!

  • 0
    TI__Guru* 84285 points
    The compiler has converted both arms of the if statement into conditional instructions. Note the "EQ" and "NEQ" on the two MOVB instructions. The CPU will execute both instructions, but depending on the value of the status register, it will discard the effects of one or the other. When going step-by-step in the debugger, it will look like both instructions are being executed. Does this match what you are seeing? Besides the odd behavior in the debugger, is there any other problem with the results of the program?
  • 0 in reply to Archaeologist
    Genius 4705 points

    Hi,

    So it seems this issue is also on other devices.  Just now I'm having problems with MSP430F5529.  Again using the 16.91.LTS compiler.

    For the TMS320 problem I was using XDS100V2 + Custom PCB + CCS7.1.0.00016  with -O=2

    For the MSP430 I am using MSPFET + Custom PCB + CCS7.1.0.00016  with -O=0.

    This time I made you a video:  https://youtu.be/Q5icRvfPqAE

    Hope it comes through ok so as you can see the big issues.

    Thanks

    Stomp!

  • 0 in reply to stomp
    TI__Guru**** 253380 points

    stomp said:
    So it seems this issue is also on other devices.  Just now I'm having problems with MSP430F5529.

    The MSP430 CPU does not have any conditional instructions.  So you must be seeing something different.

    stomp said:
    This time I made you a video:  https://youtu.be/Q5icRvfPqAE

    Thank you for making a video.  Unfortunately, I cannot view it.  There seems to be something wrong with permissions.  I attach a screen shot below.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4705 points
    Hi George,

    Sorry about that, Youtube rejected my link.

    Here is the new link: https://youtu.be/J52MFIioTE4

    I am wondering if this is now more a CCSV7 problem as opposed to a compiler issue?

    Thanks.
  • 0 in reply to stomp
    TI__Guru**** 253380 points

    Well, I doubt it is a problem with the compiler.  That code is quite straightforward.  Anything is possible.  But the compiler undergoes lots of testing on similar code.  And it has handled this kind of code the same way for years with no problems.  

    It could be the case that, through these few statements, the value for u8Test2 is not on the stack but in a register.  But the debugger (CCS) keeps showing you the stack location, and not the register.  If you run through the code until near the end of the function, does everything look reasonable?

    Thanks  and regards,

    -George

  • 0 in reply to George Mock
    Guru 43465 points
    Or temporarily make it volatile.
  • 0 in reply to George Mock
    Genius 4705 points
    Hi George,

    I've experienced the issue again on another TMS320 project. I am 100% sure its not the compiler now, as we've just re-qualified a project using 16.9.1 and there are no anomalies.

    I am now certain its something randomly wrong with CCS's debug function.

    I'll close this issue and when I can get another good shot at it i'll open a new issue with the CCS people.

    Thanks anyhow!.

    Stomp!.