I have just started checking out Wio LTE. But I find basic sketches from the examples do not work. When I enable debug mode it indicates errors are being reported by the modem in responses to Specific AT Commands.
Problem is the error messages are gibberish. Just an error number and incomprehensible text describing the error, which does not lead to diagnosis of the real problem.
Please can Seeed publish a document describing in detail the error codes issued by the modem so that problems can more easily be diagnosed (and leading to a solution).
Now that you’ve successfully built your code and performed a little clean up, run it by pressing F5 or selecting Debug > Start Debugging. This starts your app in a debug environment so you can observe its behavior in detail. The Visual Studio IDE changes while your app is running: the Output window is replaced by two new ones (in the default window configuration), the Autos/Locals/Watch tabbed window and the Call Stack/Breakpoints/Exception Settings/Output tabbed window. These windows have multiple tabs that allow you to inspect and evaluate your app’s variables, threads, call stacks, and various other behaviors as it runs.
Screenshot of the Visual Studio Autos and Call Stack windows.
Stop your app by pressing Shift+F5 or by clicking the Stop button. Or, you can just close the app’s main window (or command-line dialog).
If your code ran perfectly and exactly as expected, congratulations! However, if it stops responding, or crashed, or gave you some strange results, you’ll need to find the source of those problems and fix the bugs.
Set simple breakpoints
Breakpoints are the most basic and essential feature of reliable debugging. A breakpoint indicates where Visual Studio should suspend your running code so you can take a look at the values of variables, or the behavior of memory, or whether or not a branch of code is getting run. You don’t need to rebuild a project after setting and removing breakpoints.
Set a breakpoint by clicking in the far margin of the line where you want the break to occur, or press F9 to set a breakpoint on the current line of code. When you run your code, it will pause (or break) before the instructions for this line of code are executed.
Screenshot of a Visual Studio breakpoint.
Common uses for breakpoints include:
To narrow down the source of a crash or unresponsive program, scatter breakpoints throughout and around the code of the method call you think is causing the failure. As you run code in the debugger, remove and then reset the breakpoints closer together until you find the offending line of code. See the next section to learn how to run code in the debugger.
When you introduce new code, set a breakpoint at the beginning of it, and run the code to make sure it is behaving as expected.
If you’ve implemented a complicated behavior, set breakpoints for the algorithmic code so you can inspect the values of the variables and data when the program breaks.
If you’re writing C or C++ code, use breakpoints to stop the code so you can inspect address values (look for NULL) and reference counts when debugging for memory-related failures.
For more information about using breakpoints, read Using breakpoints.
Inspect your code at run-time
When your running code hits a breakpoint and pauses, the line of code marked in yellow (the current statement) has not executed yet. At this point, you may want to execute the current statement and then inspect the changed values. You can use several step commands to execute code in the debugger. If the marked code is a method call, you can step into it by pressing F11. You can also step over the line of code by pressing F10. For additional commands and details on how to step through code, read Navigate code with the debugger.
Screenshot of the Visual Studio code window. A red dot in the left gutter indicates a breakpoint at the line of code marked in yellow.
In the preceding illustration, you can advance the debugger one statement by pressing either F10 or F11 (since there is no method call here, both commands have the same result).
While the debugger is paused, you can inspect your variables and call stacks to determine what is going on. Are the values in the ranges you expect to see? Are calls being made in the right order?
Screenshot of the Visual Studio code window. At the line of code marked in yellow, a variable is selected and a dropdown shows its current value and references.
Hover over a variable to see its current value and references. If you see a value you didn’t expect, you probably have a bug in the preceding or calling code. For more in-depth debugging information, learn more about using the debugger.
Additionally, Visual Studio displays the Diagnostic Tools window, where you can observe your app’s CPU and memory usage over time. Later in your app development, you can use these tools to look for unanticipated heavy CPU usage or memory allocation. Use it in conjunction with the Watch window and breakpoints to determine what’s causing unexpected heavy usage or unreleased resources. For more information, see Profiling feature tour.
Regards,
Rachel Gomez
What is this response ? It’s not on topic. Are you just posting randomly ?
Go back into the hole you came from and stop bothering me.