Visual Studio provides a great debugger. I’m sure most AVR coders use it frequently–but I think that most coders haven’t taken the time to learn some of the debugger’s more esoteric, but powerful and generally easy-to-use features. This article takes a look at two such features. Before I continue with the techniques, just a reminder–be careful using the debugger if you are updating production data. The following techniques have the potential to change database data (depending on what the program you are debugging is doing).

Consider the following simple code fragment:

Let’s pretend that this code is a lot more complex than it really is–and that the loop is doing something important. Let’s also assume we have a tough bug that keeps randomly occurring as the loop iterates.

We’ll start by adding a breakpoint in the loop on the ‘k’ variable assignment. Put the cursor anywhere in that line and either press F9 or use Debug->Toggle Breakpoint to add a breakpoint. Then run the app. The instruction pointer will stop at that breakpoint. I’m pretty sure most AVR coders have done this many times. You can press F10 or F11 to step through the code. But now let’s make things more interesting.

With the program running and paused at the breakpoint, carefully hover the mouse over one of the occurrences of the ‘k’ variable. As you do this, a little window that shows a ‘k’, its current value, and a map pin appears. Click the map pin. This is a shortcut for using the debugging context menu’s “Pin To Source” option.

When you click the map pin, a little watch window pins itself to your source that shows the current value of the variable. In the image above, both the ‘j’ and ‘k’ variables have been pinned this way. Now you can step through the program and the two little windows will be refreshed as either ‘j’ or ‘k’ values change. Do note that these windows aren’t output only–you can change the value of any variable displayed at runtime. Remember, do this carefully if your program is running against production data.

Let’s assume that by the time the loop has gotten to its tenth iteration, you realize the bug has occurred and been stepped over. What you’d like to is, literally, put the program in reverse and back things up. Put the cursor on the line that you want executed next, right click, and select “Set Next Statement.” When the program resumes this is the next line of code that will be executed. You do need to be careful with this feature because variables still retain their current values–so, in this case, if ‘j’ and ‘k’ aren’t reset in the code, you’ll need to change their values with the little watch window to make the loop work.

These are both powerful techniques that can make your debugging experience more productive. Do spend a little time learning more about the debugger; there several interesting little features available that are easy to overlook. To read more Visual Studio debugging tips, take a look at this article. There is also a good Scott Guthrie blog entry here about debugging with Visual Studio.