• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 85 subscribers
  • Views 854 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.

Original question:

Expression not showing correct value

TMS320F280049C: CCS expression window wrong value

evanus yupiter
Prodigy 160 points
Part Number: TMS320F280049C
Other Parts Discussed in Thread: LAUNCHXL-F280049C

Hi all

we find unusual error while using TMS320F280049CPM and either CCS 10.2.0.00009 or CCS 10.4.0.00006.

We use TMS and TCK from our board to LAUNCHXL-F280049C (I only use MSP432E401YTPDT from the LAUNCHXL-F280049C) debugging interface to PC

Actually we find this issue while doing Instaspin FOC lab from TI, I discovered unusual ADC calculation result, then, we make much simpler code to investigate the error. Please refer to the attached video ( https://drive.google.com/file/d/1xeMcQ_gLstLLm2zCo6sryPC8qjKjjeip/view?usp=sharing ) and below explanation regarding the error

  1. The issue is CCS failed to display (by monitoring CCS expression window) the result of this simple equation Ia = ((aaa == 1.0) ? 2.0 : 0.0) * (200.0/4096.0) - 100.0; while we change variable aaa between 2.0 or 0.0 inside the loop. As you will expect, Ia value should be either -99.9023438 or -100.0, but as you can see from the video, there are many Ia result except those 2 value.
  2. Then we remove the subtraction and call it as Ib = ((aaa == 1.0) ? 2.0 : 0.0) * (200.0/4096.0); By removing the subtraction (-100), we can get correct result for Ib, Ib only have 2 possible value : 0.09765625 or 0.0 depend on aaa value.
  3. Then we remove the toggle variable aaa from Ia, and name it as Ic = 2.0 * (200.0/4096.0) - 100.0; Again by removing the toggle variable aaa, we can get correct result Ic will always be -99.9023438. So it mean there is no error with either the FPU or the syntax.
  4. Then we guess the error is with the CCS debugger display, so I let TMS320F2800049CPM to calculate the max and min of it’s calculated Ia value and also to increment the er variable, if TMS320 encounter any unexpected result, by adding below 3 lines code :

          if((Ia<-100.0)||(Ia>-99.9)) {er++;}

          if(Ia>maxia) maxia=Ia;

          if(Ia<minia) minia=Ia;

And from the expression window, we can see, the max and min value will be as expected : -99.9023438 or -100.0, and er variable always 0, mean no error encountered by the TMS320.

 

For more detail please refer to the code https://drive.google.com/file/d/1t_N1BwckJSZoHvgldtmCRkZ9sDrToKfr/view?usp=sharing for your test

 

From the above explanation we conclude the error is only at the CCS expression window, because from point no 4 and 5, TMS320 do not find any unexpected result.

So how to solve this issue, because we really depend on the expression display while we do debugging.

 

Thank you and best regards

evan

  • 0
    TI__Guru**** 472001 points

    Hello,

    Thank you for the excellent test case! It makes it so much easer for us to investigate when we have a simple, reproducible test case. It is extremely appreciated and I cannot thank you enough.

    As for the issue, I can reproduce the behavior using CCS 11.1 on an F280049C LaunchPad. I have noticed the following:

    -If I simply run the target and view the variable in the expressions view with continuous refresh enabled (like you have in your video), I can reproduce the issue.

    -If I continuously step over the source lines in the while loop, the issue is not reproduced (only the expected values for Ia appear)

    -If I set a breakpoint somewhere in the while loop (for example on line 28) and run the target and let it halt on the breakpoint and then run again and repeat, the issue is not reproduced.

    -If I disable continuous refresh and run the target without any breakpoints, la will change to an invalid value and remain so until the target is manually halted (then which a valid value will appear).

    This is strange behavior and not what I am expecting. I will do a bit more investigation but likely will file a bug for this. I will keep you posted of any updates.

    Thanks

    ki

  • +1 in reply to Ki
    TI__Guru**** 472001 points

    I noticed that if enable the debugger option to always halt the target before target access, then the issue goes away even with continuous refresh enabled and the target is left running (though halting under the hood when memory is read).

    Hence it appears to be some issue with how the expressions view unintrusively reads the value while the target is running....

  • +1 in reply to Ki
    TI__Guru**** 472001 points
    Ki said:
    I will do a bit more investigation but likely will file a bug for this. I will keep you posted of any updates.

    I filed a bug for this issue. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-10722

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 160 points

    Hi Ki

    Very appreciate for your response. You are correct if you add break point and disable continuous refresh the expression will show correct result, i forgot to inform you in the beginning, that even in continuous refresh and no break point added, if we make longer delay in the loop , the expression display will also show correct result.

    Anyway, i also confirm that your current solution (enable Halt the target before any debugger access), will resolve this issue as well, BUT unfortunately, it will impact the ISR. I test it by toggle the GPIO logic every time  MCU enter ISR, and i find that if i enable the "halt"  option and enable continuous refresh as well, the GPIO pulse will become unstable, but if the Halt option is disable, the GPIO pulse will be stable even the continuous refresh is enabled.

    I hope we can get new update so even we are in continuous debugging, we can still get correct the expression result as well Slight smile

    Thank you and best regards

    evan

  • +1 in reply to evanus yupiter
    TI__Guru**** 472001 points
    evanus yupiter said:
    i forgot to inform you in the beginning, that even in continuous refresh and no break point added, if we make longer delay in the loop , the expression display will also show correct result.

    Thank you for the additional data point. I suspect that the issue is related to when the expressions view queires the varable for the value and that increasing the delay would decrease the likelihood of the expressions view reading the variable while the variable is being calculated.

    evanus yupiter said:
    BUT unfortunately, it will impact the ISR.

    Yes this is certainly a drawback. Enabling the option to halt the target would impact real-time behavior of the application.

    evanus yupiter said:
    I hope we can get new update so even we are in continuous debugging, we can still get correct the expression result as well

    Engineering is looking into it. Hopefully they can find a valid solution soon.

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 160 points

    Thannks Ki

    I'll close this thread.

    Best regards

    evan

  • 0 in reply to evanus yupiter
    TI__Expert 5985 points

    Ok, I believe I have an explanation. The correct values for Ia are -100.0 or -99.9023438. This translates to 0xC2C8 0000 or 0xC2C7 CE00 respectively if the double's raw value is considered. The two incorrect values that are seen are -99.5 and -100.402344. Viewed as raw hex, those values are 0xC2C7 0000 or 0xC2C8 CE00 respectively. If you look at the raw hex values of the correct and incorrect cases, it becomes obvious that the incorrect values are the first word from one of the two correct values and the second word from the other correct value. This is happening because the debugger is not reading the two words atomically, and as such, if the write happens between the two reads, the value will be one of the two incorrect values.

    Ib does not exhibit this problem because it's two correct values are 0.09765625 and 0.0 which translate to 0x3DC8 0000 and 0x0000 0000 respectively. As such, one of the two words will never change and thus it is not possible for the debugger to read back an incorrect value.

    Ic does not exhibit this problem because it is constant.

    Even if Ia was written to inside of a critical section, I believe the debugger might still read one word on either side of the critical section. Unfortunately, I'm not enough of an expert in the F28 debug hardware to know if there's a way for the debugger to request 32 bits atomically.