• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 646 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSPM0G3507: XDS110 debug with M0

Allen Lu
Intellectual 2440 points
Part Number: MSPM0G3507

Hi team: 

 My customer now debugging with MSPM0G3507 device with XDS110 Emulator， and found two issues.

1. we set the global variables test_close_flag as uint16_t

2. and when we start the emulator， we change the value of test_close_flag via the expression table,

3. we try if / switch case as below, but we found the execute function can not work. And the expression show test_close_flag  is a unsigned short type.

4. when i set the test_close_flag as bool, the expression show test_close_flag  is a unsigned char type.

5.when i set the test_close_flag as uint32_t, the execute function work！！， And the expression show test_close_flag  is a unsigned int type.

can you help to comments why cause this issue? the CCS version is 12.3.0.00005

And the last question is about the break point. 

Here is the demo:

{

if (test_close_flag )

 DL_time6_startcounter...;

else if (test_close_flag ==0 )

 DL_time6_stopcounter...;

}

when we want to add a break point as the line of marked green, but the break point will occur as the line of marked red. hope to know why, tks again.

  • +1
    Guru 42085 points

    If optimization is in effect, lines can lose their relationship to the assembly instructions. (Or they can disappear entirely!) This can lead to breakpoint setting oddities as you have described. Try debugging with optimization off which will generally keep the correspondence between C source and assembly instructions relatively intact.

  • +1
    TI__Mastermind 25570 points

    Hi Allen,

    I recommend turning off optimization, to Keith's point sometimes the code gets altered so you can't breakpoint on specific C lines. The compiler will also optimize out variables especially if it doesn't not see the variable being updated in code (the volatile keyword will prevent the variable from getting optimized out).

    Once optimization is removed try debugging again and checking your test_close_flag, I would create a default case and place a breakpoint there if you are not hitting the '0' or '1' case.

    Regards,

    Luke