While debugging with Atollic's TrueSTUDIO IDE / SDK, variables are reported to contain unbelievable values. But, if the code is left to run, the code behaves as if the variable values are correct.


Up until now, I have been using TrueSTUDIO to debug my own code which is called from main(). Up until now the variables in my code have contained the expected values. Recently, I started to integrate my code with existing USB CDC code. It is in this new code the values, when inspected using TrueSTUDIO, contain unbelievable values. (To be clear, during the same debugging session, TrueSTUDIO reports variables in my code with expected values. However, TrueSTUDIO reports variables in the USB CDC code with unbelievable values.)

If this is not confusing enough. I switched from using TrueSTUDIO to STMStudio (which is a run-time variables monitoring and visualization tool for STM32 microcontrollers). Now when I inspect the variable in question, their values are as expected.

How can TrueSTUDIO fail & STMStudio work?

Is there a TrueSTUDIO setting I have missed?


  • \$\begingroup\$ Show us an example, including the memory address and its contents for the affected variable when 'unbelievable' and 'correct'. \$\endgroup\$ Feb 18, 2020 at 16:29
  • \$\begingroup\$ Is an Endian issue a possibility?? \$\endgroup\$ Feb 18, 2020 at 16:30
  • \$\begingroup\$ @BruceAbbott, sorry if I was not clear. My variables appear to always be correct. It is the variables associated with the USB code which appear unbelievable (array pointers with values in the 10's of thousands and arrays which are all zeros but should contain USB message data). Also, variables that appear correct always appear correct. And the USB variables that appear unbelievable always appear unbelievable . I will try to get some screen shots of the memory locations in question. \$\endgroup\$
    – st2000
    Feb 18, 2020 at 17:04
  • \$\begingroup\$ @ScottSeidman, I don't think so. For example, the arrays that hold the USB communications data are reported full of zeros by TrueSTUDIO. But when inspected using STMStudio, they contain the expected pattern of data. Also, while some variables contain unbelievable data, other variables inspected during the same debug session contain the expected data. The only difference I suspect so far, my variables are formed from code which is called from main(). While the USB variables (which contain the unbelievable data) may be called from interrupts. \$\endgroup\$
    – st2000
    Feb 18, 2020 at 17:07

1 Answer 1


It turns out that a watch dog timer was active even after TrueSTUDIO stopped on a break point. (I noticed several LED indicators on our target board continued to flash even after code execution stopped.) I assume the watch dog initializes USB CDC values and thus caused the expected data to be replaced by "unbelievable" data. Once the call to start the watch dog timer was commented out, the USB CDC variables contained the expected data.

I suspect that STMStudio reported the correct USB CDC values as code was executing and the watch dog was therefor not activated.

Thanks for everyone's input!

  • \$\begingroup\$ Don't forget to accept your own answer to indicate that the question is answered. \$\endgroup\$
    – Transistor
    Feb 18, 2020 at 21:03
  • \$\begingroup\$ Ah, good point @Transistor. Nuts, house rules say I've got to wait 2 days. \$\endgroup\$
    – st2000
    Feb 18, 2020 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.