So I was quite dazzled as I tried a new function in my code. While stepping through it always pointed to the same return statement, but the actual value returned was that from a different return statement.
The code is working fine, I tested it with the CCSv4.2 and the old v2-dll - there the stepping is showing to the correct line all the time. So I guess there is a bug in either the MSP430.DLLv3 or CCSv5.1.0.09000 - right now I can't tell which of those it is.
I've tried to create a minimal example to recreate the problem:
#include <msp430f5418a.h>
typedef signed int sFix0_15;
sFix0_15 add(sFix0_15 a, sFix0_15 b);
void main(void) {
WDTCTL =
WDTPW | WDTHOLD;
volatile sFix0_15 test1 =
add(0x2000, 0x2000);
volatile sFix0_15 test2 =
add(0xC000, 0xC000);
volatile sFix0_15 test3 =
add(0x4000, 0x4000);
volatile sFix0_15 test4 =
add(0x8000, 0x8000);
}
sFix0_15 add(sFix0_15 a, sFix0_15 b)
{
sFix0_15 result = a + b;
volatile int SR = _get_SR_register();
if ((SR & V))
{
if (SR & N)
{
return 0x7FFF;
}
else
{
return 0x8000;
}
}
return result;
}
Don't be to concerned about the typedef, I'm working with fixed point numbers, and the function is basically an add function with saturation behavior. Now the results are computed fine (also with CCSv5.1). The first two statements give no saturation, results being 0x4000 and 0x8000, the last two give positive and negative saturation so the results are 0x7FFF and 0x8000. If I step through that code with CCSv5.1 the marker jumps always to "return 0x7FFF;". I have switched the optimization level to the empty field, so I hopefully have not a problem due to optimization here.
Trying the same code with CCSv4.2, everything was fine, the marker went to the right return statements.
