Compiler/TMS320F28069M: 32-bit IQ values being truncated by storage in 16-bit registers

Oliver,

I'll work with you to try and resolve this issue.

1. I presume you are using C code where one 32-bit IQ12 variable is being assigned to another 32-bit IQ12 variable? Is there any special casting or anything? Is it a simple assignment or something more?
2. Have you confirmed that the assignment is indeed causing the target variable to not have the desired value? Does this occur only in one place in your codebase or everywhere (assuming there are multiple instances of this kind of assignment)?
3. While debugging, have you looked at the disassembly associated with the code and seen anything unusual?

Thanks,
Sira

Hi Sira,

Thanks for offering to help.

I just tried a suggestion from one of my colleagues: writing one of those 'corrupted' IQ variables back into RAM and viewing it in the expression window. When doing this, I found that the correct value is written into memory. This suggests that the compiler is generating correct code, but the debugger is getting confused somehow and mistakenly interpreting some 32-bit local variables as 16-bit variables.

Here are answers to your questions:

1. We are compiling using C++. The issue shows up both with simple assignment of one local to another, as well as assignment of a return value to a local. Here is one of the functions in which the issue appears (the names have been obfuscated, and some function arguments removed). 

_iq12 f(void);
_iq12 g(void);

_iq12 my_func() {
    _iq12 x = 0;
    _iq12 y = f();
    _iq12 z = g();

    if (a_func_returning_bool()) {
        x = y;
    } else if (other_func_returning_bool()) {
        x = z;
    return x;
}

2. As mentioned above it seems that the variable actually has the correct value, but the debugger shows the wrong result. I looked at some other uses of IQ variables in this project and the results seemed OK.

3. I haven't looked at it too closely as I'm not familiar with C2000 assembly and the above results suggest the generated machine code is correct. I did see that it appears to be generating MOVL instructions to move the _iq12 variables, which looks correct.

The debug probe I am using is a Blackhawk XDS100-v2.

Thanks,

Oliver

Oliver,

Did that resolve your issue? If yes, can you please go ahead and click the "Verified Answer" button?

Thanks,
Sira

Hi Sira,

So far I have only seen this happen to variables assigned to XAR registers, but I'm not certain that it will not happen with other registers.

I took another look at some code that displays the symptoms described in my original post. In this case the "Registers" view showed XARnH as all zeros, which (based on program behavior and looking at RAM from which this variable is being read / written to) is incorrect. 

You can see this in the picture below, where XAR3 is being used for a 32-bit IQ12 variable.

Although my original question was resolved, I'd like to keep this issue open for a bit to see if the debugger issue can be solved.

Thanks!

Hi Oliver,

I have requested the E2E forum moderator in our group to re-assign this to an appropriate expert who can help you with this.

Thanks,
Sira

Hi Oliver,
A similar issue was reported in the past (CCDSK-3134) but was never resolved due to a lack of a reproducible test case. Can you provide one? We would need the executable file and relevant source files.

Thanks
ki

Oliver,

Can you please provide an update on this? If your issue is resolved, please click on Answer Verified so that we can close the issue.

Thanks,
Sira