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\$ – Bruce Abbott Feb 18 '20 at 16:29
  • \$\begingroup\$ Is an Endian issue a possibility?? \$\endgroup\$ – Scott Seidman Feb 18 '20 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 '20 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 '20 at 17:07

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 '20 at 21:03
  • \$\begingroup\$ Ah, good point @Transistor. Nuts, house rules say I've got to wait 2 days. \$\endgroup\$ – st2000 Feb 18 '20 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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