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.

CCS/MSP430FR5994: Switch Case Compiler Problem

Part Number: MSP430FR5994

Tool/software: Code Composer Studio

Hello everyone

I have a problem with a Switch Case instruction in combination with the compiler.

This is a code-snippet of the part where the problem occures.

if (uart_getReadFlag())

{

uart_clearReadFlag();

uart_getReceivedData(uartRxData, &nrOfRxBytes);

uartCommand = *uartRxData;

switch (uartCommand)

{

case SET_PULSE_LENGTH:

commandPayload = uartRxData[2] + (uartRxData[1] << 8) ;

heat_setNewPulseLength(commandPayload);

break;

case SET_PERIODE_LENGTH:

commandPayload = uartRxData[2] + (uartRxData[1] << 8) ;

heat_setNewPeriode(commandPayload);

break;

case SET_LOW_VOLTAGE:

heat_setLowVoltage();

break;

case SET_HIGH_VOLTAGE:

heat_setHighVoltage();

break;

default:

break;

}

}

------------------------------------------------------------------------

The function uart_getReadFlag() returns 0 or 1.

If the function returns 1 everything is ok and the correct case is executed. If the function returns 0 the curser (when single stepping in c-file) jumpes to the Switch Statement again. But it doesn't execute any case. After the Switch Statement it leaves the function correctely.

In the disassembly you can see, that the return from function Operation is located after the Switch - Statement. So I think there is a problem by interpreting the Switch Statement correctly. The functionality is correct but when single stepping in the c-file this strange jump to the Switch-Statement, even if the return-value in the if-instruction is zero, doesen't make sence.

So maybe you can help me somehow.

I am using the following Tools:

CCS V7

Compiler Version: TI v16.9.7.LTS

MSP: MSP430FR5994

Thanks for any help!

Dominic

  • I presume it is correct to say that, if run through the code without any single steps, it always behaves correctly.  The only time things seem wrong is when single stepping.  

    You are probably building the code with some level of optimization.  Optimization can cause the debug experience to degrade.  The odd single stepping you describe is one example.  It does not seem to be causing any trouble running or debugging the code.  That being the case, I recommend you ignore it.

    For more background on this issue, please see the article Debug versus Optimization Tradeoff.

    Thanks and regards,

    -George

  • You might need to make uartCommand volatile so the compiler knows it might change at any time.
  • Thanks for your advices! Setting the uartCommand volatile unfortunately doesn't help solving the problem. But thanks anyway!
  • George you are correct. It is more like a "presentation" problem. In the disassembly if the uart_getReadFlag() function returns zero, the program jumps to the return from function instruction. This one is located directally under the Switch Statement. I think that's why in the c-file when single stepping this problem occures. Optimisazion is turned off but still the same problem. That's why I was wondering why it is presented wrong.

    Because the functionality is correct maybe I have to live with this. But it gives a bad feeling when such problems occure and I have no explanation for it.

    But thank you for your answer anyway.

    Dominic.