This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Watch window problems

I did a couple of searches and found some references to the problems I am having. But I don't think this is fully addressed, so I'll ask here.

I am using the contest eval board from Luminary Micro that includes an eval copy of the Keil tools for the Cortex-M3. I have seen variables in the local watch window display the wrong value as I step through a program. There are a couple of threads here from last summer about this, so I guess this is a known (and fixed) problem. I am surprised they circulated an old version of the tools for this contest. I just got my board in early December.

The other problem is that in one case, I was not able to view a variable in a watch window. It was a local variable and did not show in the Locals window. I also could not add it to the other Watch windows. This variable was being used, so it should not have been optimized away. I was compiling at optimization level 0, so that should not be the problem. Is this a known problem? Is it fixed in a current version of the tools?

Parents
  • Rick, can you post a very small sample of compilable code that still shows this behavior?

    Did you follow the machine code generated by the compiler to see if the variable assignment was optimized? Even at level 0 the Keil compiler does that if it can determine that an expression can be reduced (and that's GOOD). Local variables quite often don't have a life in RAM, but only in cpu registers.

    You may also be experiencing a overlay reuse of the actual variable storage due to lifetime expiration. For example, the variable lifetime may expire at the middle of a C expression, so it will not have any meaningful value at the next C source line, because that address is actually allocated to another variable at that time. The local watch window does not make this clear, and you see a 'wrong' value.

    Try to reference the variable in an unoptimizable way after the point that you want to watch, e.g., placing it at an expression in a bogus if(){} or while(){}clause after the intended watch point.

Reply
  • Rick, can you post a very small sample of compilable code that still shows this behavior?

    Did you follow the machine code generated by the compiler to see if the variable assignment was optimized? Even at level 0 the Keil compiler does that if it can determine that an expression can be reduced (and that's GOOD). Local variables quite often don't have a life in RAM, but only in cpu registers.

    You may also be experiencing a overlay reuse of the actual variable storage due to lifetime expiration. For example, the variable lifetime may expire at the middle of a C expression, so it will not have any meaningful value at the next C source line, because that address is actually allocated to another variable at that time. The local watch window does not make this clear, and you see a 'wrong' value.

    Try to reference the variable in an unoptimizable way after the point that you want to watch, e.g., placing it at an expression in a bogus if(){} or while(){}clause after the intended watch point.

Children
No data