CCS/UCD3138A: How to assign value to the array in structure

Weijing Du

Part Number: UCD3138A
Other Parts Discussed in Thread: TMDSEMU110-U

Tool/software: Code Composer Studio

Hi,

I tried to define a structure which contained variables, arrays and also structures. But I have problem of assigning values to the arrays and structures in this structure. In contrast, I can successfully assign values to the array which is not included in the structure. My CCS version is 6.2.0, and the Fusion Digital Power Studio is 3.0.20.

This is the structure I defined.

The biquad_param structure is as follows, it also contains arrays.

I also define all the variables as EXTERN variables. The bq_buf_LD_test[3] array is for comparison.

Then, I tried to assign values as follows:

The code can be compiled successfully, and the value of bq_buf_LD_test[3] is correct.

But the values of pll1.bq_buf_LD[3], pll1.bq_param_VE.A[2], and pll1.bq_param_VE.A2_shift_n are wrong,

It is such a simple code and I don't know why the assignments are not correct.

Thank you in advance.

over 8 years ago

0 Weijing Du over 8 years ago

Intellectual 460 points

After I moved all the " int64 " variables and arrays to the bottom part of the structure definition, it worked correct. Just copy the structure below. Still want to know why this happens?

typedef struct
{

PLL_STATE state; // Output: PLL state

int16 v_ac_L; // Input: AC_L_SENSE
int16 v_ac_N; // Input: AC_N_SENSE
int16 v_ac; // Input: AC voltage

int16 v_ac_rms; // Output: Estimated AC voltage amplitude divided by sqrt(2)

int32 v_ac_inv; // Output: Reciprocal of estimated AC voltage amplitue

int16 sin_theta; // Output: Sin of estimated phase
int16 cos_theta; // Output: Cos of estimated phase
int16 v_pk_p;

int16 v_pk_n;
Uint32 state_cntr;

struct BIQUAD_PARAM bq_param_VE;

int16 lock_cntr;
int16 lock_detector;

struct BIQUAD_PARAM bq_param_LD;

int64 v_ac_amp; // Output: Estimated AC voltage amplitude
int64 omega; // Output: Estimated angular speed
int64 theta; // Output: Estimated phase
int64 integrator;
int64 bq_buf_VE[3];
int64 bq_buf_LD[3];

}PLL;

0 Ian Bower over 8 years ago in reply to Weijing Du

TI__Genius 17090 points

Weijing, I think that the problem is most likely with the memory debugger, rather than with the compiler. Essentially the memory debugger has to parse the whole .pp file and the .map file and figure out where the variables are. It's a separate program, not associated with the CCS parser. So if things get complicated, I've seen things like this happen before.

0 Weijing Du over 8 years ago in reply to Ian Bower

Intellectual 460 points

Thank you!

0 Weijing Du over 8 years ago in reply to Ian Bower

Intellectual 460 points

BTW, except the memory debugger, is there any other way to debug the UCD3138A?

0 Ian Bower over 8 years ago in reply to Weijing Du

TI__Genius 17090 points

There is JTAG, with the XDS100v2. It's not necessarily as useful as it seems, because you can't look at RAM without halting the program. This is especially problematic with PFC. Also, of course, you have to not be using any of the JTAG pins for something else.

training.ti.com/using-jtag-ucd3138-installing-code-composer-studio-ccs-jtag-support

0 Weijing Du over 8 years ago in reply to Ian Bower

Intellectual 460 points

I saw that the XDS100V2 14-pin JTAG is replaced by XDS110 (TMDSEMU110-U) debug probe.
www.ti.com/.../TMDSEMU100V2U-14T

So, can I use XDS110 to debug UCD3138A?

0 Ian Bower over 8 years ago in reply to Weijing Du

TI__Genius 17090 points

I am not aware that we have tested that. Let me try to find out if we've tested it on the UCD.

0 Weijing Du over 8 years ago in reply to Ian Bower

Intellectual 460 points

OK. Thank you, and looking forward to your reply.

0 Weijing Du over 8 years ago in reply to Ian Bower

Intellectual 460 points

Also want to know, when you said "the problem is most likely with the memory debugger", did you mean this problem only exist when debug with memory debugger? If change to the JTAG, this issue may disappear? And this won't be a problem if I download the code to the flash instead of ROM?

0 Ian Bower over 8 years ago in reply to Weijing Du

TI__Genius 17090 points

Yes, probably the problem is only with the memory debugger. The code should work fine, and so should the JTAG.

I just got an email from the memory debugger expert, and he says he already has this issue flagged. He thanks you for giving him a working and non working case that he can compare.

0 Amiel Hussain over 8 years ago in reply to Weijing Du

TI__Expert 4070 points

Hello,

The memory debugger sometimes has issues with / * comments are used. We are looking to resolve these kind of issues. I think the issue may not be related to the order but to the two lines with the the commented theta variables that have "2*" in their comments. Try compiling again with just deleting those two commented lines.

Also would it be possible for you to attach a project with this problem?

Thanks,

Amiel

0 Ian Bower over 8 years ago in reply to Amiel Hussain

TI__Genius 17090 points

I've also gotten the answer on the XDS110. We've started testing, and we need to make some changes to the setup and probably to our code as well. At this time we don't support the XDS110. The XDS100V2 is still available at Digikey and Mouser, and possibly other distributors as well.

0 Weijing Du over 8 years ago in reply to Ian Bower

Intellectual 460 points

Thank you for all the information provided. I will try to use XDS100v2 for debugging.

Best Regards

Weijing

0 Amiel Hussain over 8 years ago in reply to Amiel Hussain

TI__Expert 4070 points

Also if you can share just the .map and .pp file generated that would be sufficient.

0 Weijing Du over 8 years ago in reply to Amiel Hussain

Intellectual 460 points

Thank you for your suggestion. I tried to remove all the /* and 2*, but still can not work. After I changed the order by moving all the int64 variables to the bottom of the structure definition, it worked correct. The project is attached belowTest_PLL_try.zip

0 Amiel Hussain over 8 years ago in reply to Weijing Du

TI__Expert 4070 points

Hello,

The issue here was that Int64 wasn't fully supported by the memory debugger. This variable type has a self alignment rule and needs to start at the beginning of a word boundary in the memory. The memory debugger was not taking this into account for this type. The reason it worked after you moved it was because it coincidentally aligned to the word boundary. A new build will be released soon covering this error and posted to the net. Thank you for providing your project to help debug this issue.

Amiel