Forum Replies Created
-
Posts
-
Thanks for clarifying this. Normally, just rebuilding the project should have helped. Most likely some dependencies between different components were not handled correctly, so the executable still ended up with the old debugging symbols.
Please consider reading our symbol troubleshooting tutorial. It explains how the debug symbols work and how to check their status.
Hi,
No problem. Please try obtaining and sharing a call stack of the hanging Visual Studio process as shown here: https://visualgdb.com/support/callstack
Hi,
This is to be expected. If you just rename the file, the debugging symbols will store the old file path, preventing the breakpoints from working. Please try building/rebuilding the project after you rename the file.
No problem, we should be able to fix it. However, if the issue only triggers with a few select files, we would need further information from you.
Please try creating a new embedded project from scratch. Then the .clang-format file in its directory and replace the contents of the main file with the minimal file contents that trigger the error when either saving or reformatting the document (via Edit->Format Document). Then please attach the entire repro project and we should be able to fix this promptly. You can alternatively send the repro project via our support form.
Hi,
Unfortunately, help on resolving issues with specific projects is outside of our support scope. However, we have a very detailed tutorial explaining the ESP-IDF components: https://visualgdb.com/tutorials/esp32/esp-idf/components/. We would advise following it so that you could get familiar with the ESP-IDF component semantics.
Hi,
Sorry, the regular VC++ projects follow the Visual Studio’s separation between source and header files.
If you would like to avoid it, please try using the Advanced CMake Project Subsystem instead. It allows a fine-grain control over grouping and filtering of sources in Solution Explorer. Also CMake-based projects can be built outside Visual Studio/VisualGDB, so you won’t lose the ability to build your project on a different machine, or on a build server.
Strange, the “value doesn’t fall in the expected range” looks like a .Net exception message, so you should normally still get a .Net assembly that triggers the exception. Can you confirm that the error message still looks the same after disabling the plugin? Does the outer VS instance show any exceptions in the “Output” window?
Please also try disabling the Clang IntelliSense as shown here and check if it solves the problem. If yes, please try enabling it back and then reformat the entire document (Edit->Advanced->Format Document). Does this trigger the problem?
Hi,
No problem, please try this build: VisualGDB-5.5.5.3574.msi
We have added an option under VS Project Properties -> C/C++ -> Advanced that allows explicitly specifying the input language for the source files instead of having it auto-detected from the extension.
Hi,
This is really a generic C++ question and not something specific to VisualGDB, so the amount of help we can provide here is very limited. If you are new to C/C++, we would advise looking up and following a few beginner’s tutorials that explain source and header files. It could save you immense time compared to trying to guess the correct configuration.
You can also find a few best practice articles published by Microsoft by searching for “Visual Studio add cpp file”. As VisualGDB embedded projects inherit the Visual Studio’s project system, everything described in those articles will apply to VisualGDB projects as well.
Regarding your second question, neither Visual Studio nor VisualGDB would automatically build all files from a specific folder, as it could normally cause confusion. Explicitly adding the source files to Solution Explorer (and using virtual folders to organize them) is the way to go for C/C++ projects.
Yes, this looks like an issue in the VSE_FormatDocumentOnSave.dll extension and not in VisualGDB. Please consider disabling that extension, or contacting its authors for troubleshooting advice.
No problem, we can help you narrow it down. Please try checking if the problem only happens for a specific project, or also for a newly created project of the same type.
If it doesn’t happen to all projects, please try understanding the difference between the working and broken projects.
You can also try getting a call stack of the problem by attaching a debugger to Visual Studio as shown here: https://visualgdb.com/support/callstack. Then try reproducing the problem and check the Output window in the outer VS instance for the “exception of type XYZ was thrown” messages. Once you get the exception name, please try configuring the outer VS to break on that exception via Debug->Exceptions. This will catch the exact moment when the problem happens. If you could share the call stack from that event, along with your VisualGDB build number, we should be able to see what is going on.
This is to be expected, as the bootloader contents is always padded so that the actual program always starts at the same address (where the bootloader expects it).
Hi,
In theory, you could use the add-symbol-file command to load the debugging symbols for both main application and the bootloader simultaneously. In practice, it usually results in weird behavior (e.g. breakpoints work, but gdb starts confusing the source files).
The only reliable way we could advise is to switch between either of the symbol files back-and-forth (see step 33 of this tutorial).
Yes, you can simply add those commands to VisualGDB Project Properties -> Custom Debug Steps -> Before Launching Debugger.
You may also want to disable the regular FLASH programming command via VisualGDB Project Properties -> Debug Settings (as it would program the regular image) and either program the .hex file by running a command-line programming tool, or add a Segger-specific monitor command that would program the .hex file to the Additional GDB Commands page (see J-Link documentation for the list of the monitor commands supported by J-Link).
Hi,
It’s hard to say why a specific project would not be working on a specific board. Most likely, some setting of the project file doesn’t match some board parameters. Please double-check that you have followed ALL steps of the tutorial (including the ‘reset after programming’ flag in Debug Settings).
It if doesn’t help, please consider hardcoding a breakpoint at the beginning of the bootloader by adding the following code to main() or even to RESET_Handler:
asm("bkpt 255");Once the breakpoint triggers, you will normally only see the disassembly, as the bootloader symbols will not be loaded. You can switch to using the bootloader symbols using the symbol-file command as described in step 33 of this tutorial (please make sure you read the entire tutorial and understand how different parts go together before trying to do advanced troubleshooting).
EDIT: we have rechecked the bootloader tutorial with the latest ARM toolchain and it indeed was not working out-of-the-box, as the .data section in the .bootldr-o file was not renamed as expected. We have updated the tutorial to work with the new toolchain. You can find the exact changes we made here (only the bootloader.props file needs to be updated).
