Forum Replies Created
-
Posts
-
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).
Hi,
Sorry for the delay. We have added support for using the SSH console when not debugging to the following build: VisualGDB-5.5.5.3573.msi
The commands for opening the console appear in both the View menu (for the startup project) and the context menu for a specific project in Solution Explorer.
Hi,
Please use the “Warn About Detached Files” option. You can find the full path to the option here: https://visualgdb.com/settings/
Also, feel free to try this build: VisualGDB-5.5.5.3573.msi. It will suggest automatically adding a path mapping rule for automatically downloaded remote files.
This looks like the some issue between the VisualGDB’s project node and the Visual Studio Solution Manager. Please try closing the Solution, deleting the .vs subdirectory and opening it again.
If it doesn’t help, please check if the problem happens with a newly created project as well.
Yes, please consider creating a project manually as shown here: https://visualgdb.com/tutorials/arm/legacy/
Good to know it works. BTW, you can set mappings for arbitrary path prefixes, e.g. the following mapping should cover all the necessary files:
/var/volatile/tmp/VisualGDB/c/TrollSource => c:\TrollSource
Hi,
This error happens because the tests use a separate pipe (created with mkfifo) to report structured tests outputs to VisualGDB, and telnet doesn’t allow easily multiplexing multiple streams.
Does your target have mkfifo + netcat installed? If yes, please try checking if you can launch netcat in the background over telnet and let it forward a mkfifo-ed pipe to TCP. If yes, we can extend the custom target interface to allow running unit tests (your implementation would need to “open” a remote pipe and return a .Net Stream object corresponding to it, that will be independent from the regular telnet output).
Hi,
No problem. Although this is not documented yet, VisualGDB exports a public interface for reading the coverage report files. You can try it out as shown below:
- Create a new C# project and reference the VisualGDBCore.dll assembly.
- Create an instance of the CoverageReportReader class. Pass the path to the report file as the first argument, and null as the second one.
- Use the AllFunctions property to get information for all functions.
- Call the GetFunctionsInPotentiallyMatchingFiles() method with the name of a source file to get detailed line-by-line coverage information.
You can use Visual Studio’s IntelliSense and Go-to-Definition command to see the properties and methods of the CoverageReportReader class.
