The uVision3 IDE watch window shows the value of pString incorrectly (when stopped on a breakpoint in the "bug" function), unless pString is actually referenced in the function (by, for example, uncommenting the line "pString[0] = 0"). This is true even if the code optimizations are set to the lowest level possible.
#include <string.h> int bug(int *nState,char *pString) { *nState = 0; // pString[0] = 0; return(0); } void main(void) { int foo = 0; char *bar; char s[] = "KEIL uVision3 for ARM\r"; bar = s; bug(&foo,bar); while(1); }
What I tried to say was that this problem was found when creating the function stubs for a new module. The 'guts' of the functions had not been filled in yet, but as they were being filled in I ran the debugger to make sure that the proper info was correctly making it to appropriate functions. The parameter in question has since been used by the function that led to this discovery. I do know that it caused me some confusion, concern, and it wasted some of my time to perform an investigation to determine why the debugger was telling me that the info I was trying to get to a function just wasn't getting there correctly. The bottom line is that it appears that the debugger was just giving me incorrect information. It may be that this symptom is indicative of other problems, and I'm just trying to let the folks at KEIL know that an error surfaced with their tools, so that they have an opportunity to look into it, should they desire to do so. I'm sure that other developers would like to be spared from as many tool issues as possible. No one likes to waste their time.
I've seen this as well. It looks to me as though the variables in the watch window are linked to the register where the value is/will be stored. I've seen that when the variable is actually used that the compiler will copy the value to another register. This register is the one that the watch window references when displaying the value. In the case of your example, the *nState pointer's value it probably passed in as register 0, and the *pString pointer is probably passed in as register 1. Since *nState is used, a copy is put in another register (register 3 or 4 maybe). After this local copy is made, the value of *nState can be seen in the watch window. Since *pString is not used, a local copy is not made and the watch window has not register to use to display the value. You can however still look as the register used to passed in the variable to determine if the correct value is passed.