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/CODECOMPOSER: wrong expression value for 32bit variables allocated into registers (TMS320F28)

Part Number: CODECOMPOSER

Tool/software: Code Composer Studio

Hello all,

 I'm using CCS  8.1.0.00011 with LAUCHXL-F28379D.

During debud, in the expressions window the values of 32bis (ie. unsigned long) variables that the compliler allocates into CPU registers are visualized with the 16 most significant bits always 0, regardless of the effective value in the registers.

  • Could you please share a simple test case that demonstrates this issue? That will be very helpful to reproduce and investigate the issue. Thanks.

  • void ExpressionIssue(void)
    {
    uint32_t Temp = 0;

    do
    {
    Temp++;
    if (Temp > 0x0000FFFF)
    {
    asm(" NOP");
    }
    } while (Temp < 0x000A0000);
    }

    void main(void) {

    ExpressionIssue();

    }

    Just set a breakpoint on the asm instruction and run: the CPU will stop (the first time) when Temp is 0x00010000, but if you inspect Temp value in Expressions window you'll see that value "is" 0 (better, forcing hex format "is" 0x00000000). The compiler (in my case) allocates Temp in XAR5 and in the Registers window it show the correct value.
    Running on again, on successive breaks, XAR5 rightly increments to 0x00010001, then 0x00010002... but in Expression Temp is show as 0x00000001, then 0x00000002...

    It's missing the 16 MSB... (just on visualization, the effective value is correct and the cycle ends after the expected iterations).

    It seems to me that this only happens on variables fitted in a cpu register: if you declare Temp outside the function (in the global scope) it is allocated in ram and the value in Expression window is good.
  • Thank you for that test code. Using that I was able to reproduce the issue. I have filed a bug report to track this issue. The tracking ID is DBGTRC-4309. Feel free to check the status of the bug using the SDOWP link in my signature.