- This topic has 7 replies, 3 voices, and was last updated 10 years, 10 months ago by
.
-
Posts
-
When I hit F10, the commands executed in the background happen so quickly, and the output window gets cleared, so I cannot see what VisualGDB executed in the background to start openocd and flash the image. I want to be able to perform the same command from the command line. How can I figure it out?
Hi,
These commands are not logged anywhere. What exactly are you trying to do? We may be able to tell you another way to accomplish this with VisualGDB.
Hi ket,
I am trying to have a secondary compilation/testing/debugging flow that does not rely on Visual Studio. That way I could automate some testing on a machine that does not have VS. I could figure out how to compile by looking at VS output window. Now I want to be able to:
– flash the image from command line
– start openocd manually and attach to it with gdb (or visual GDB)
ThanksHi,
Unfortunately VisualGDB only functions as a Visual Studio add-in and cannot be used separately from it. If you want to make your own build/debug setup that is not dependent on VisualGDB, please consider OpenOCD manuals/forums, STM32 community and GCC community for further information.
Perhaps you misunderstood me. It is of great benefit to me to be able to edit/debug from visual studio. I do not want to circumvent VisualGDB and do it all command line. In fact I have a flow that allows me to use openocd/gdb already, and I do use VS as my editor. What I want to do now is to ‘connect’ my make flow to VisualGDB to be able to debug. I would like to use VisualGDB part of your tool, without having to use VisualGNUmake of it, if this makes sense.
Hi,
Sorry for the confusion. VisualGDB supports 2 way of doing this:
1. You can use the Quick Debug feature (from the Debug menu) to start GDB with the arguments/settings you manually specify and let VisualGDB connect it to Visual Studio.
2. You can create a custom project using the custom project wizard and manually specify build command, clean command and GDB launch command.Excellent. Thanks a lot. I got it to the point where I can load the elf file, break, single step, and look at variables. However, when I try to set the breakpoint, I get the following type of message:
-break-insert -f /cygdrive/c/svn/NZ04/Firmware/thin_display/stm32fxxx_it.c:190
&”No source file named /cygdrive/c/svn/NZ04/Firmware/thin_display/stm32fxxx_it.c.n”My flow compiles through cygwin, and while the paths seem to work just fine coming from elf into VS, the other way around doesn’t seem to work. I can manually fix the path and enter the break-insert command on the GDB session command line. That works (well, VS GUI is not aware of that breakpoint, but otherwise it is OK).
Is there a fix/workaround that would take care of this issue so I can use F9…?
The problem most likely happens because your toolchain maps the file paths in a way unknown to VisualGDB.
Please use the ‘breakpoint diagnostics’ feature (see this tutorial for more details, it is about Linux, but it should be similar to your case). If the diagnostics feature does not help, please run the info sources command and post its output here so that we could help you with setting up file mapping.
- You must be logged in to reply to this topic.