Forum Replies Created
-
Posts
-
Hi,
The include/library directory settings do not support any variables. They do support relative paths, however.
If you want to reference a VisualGDB library project, simply add it to the build dependencies of your main project and VisualGDB will figure out the path to the binary automatically.
We don’t support multiple targets per project as it would make some things overcompilcated (e.g. project references or mapping of source files to targets) and it’s not supported by normal Visual Studio projects. You can instead use one of the following workarounds:
1. Create several VisualGDB projects in different directories
2. Manually edit the makefiles to add more targets (you will then have to manually track which sources belong to which targets)
3. Create several VisualGDB projects in the same directory and override the Makefile name for them (e.g. Makefile2 instead of Makefile).Hi,
Sorry, we are still investigating the NullReferenceException issue. We should be able to provide an update by the end of this week.
Hi,
Does that happen with a stock version of make.exe that comes with MinGW, or are you using some custom make executable?
VisualGDB reuses the Visual Studio IntelliSense engine (it configures it by providing GCC-specific definitions and include paths). Sometimes, the Visual Studio IntelliSense engine produces strange results. We are currently working on a new engine that will handle the GCC-specific code natively. As a temporary workaround before we have released it you can try commenting out arbitrary include directives to see which of them breaks IntelliSense.
If properly configured, the VPN sever will give you an IP address inside the intranet, the software on the client side will route requests to 192.168.0.2 via the VPN transport and the VPN server will in turn forward them to your FTP server. Typically, the manual for the VPN client/server software should contain plenty of configuration examples that can provide further clues.
Currently this is not possible, however if you go to the GDB Session window, select the text input and press the ‘up’ button, it will show the last entered command. Hence, you will just need to press ‘
‘ each time you want to execute it. Hi,
We have not specifically tested it over WiFi, however if you can get it to work to the point where you can ping your Raspberry Pi from your PC, VisualGDB should be able to target it without any problems. Let us know if you encounter any difficulties.
Hi,
The easiest thing to start with would be adding the msys binary directory to PATH when building your makefile (this can be changed on the Build Settings page in VisualGDB Project Properties). That may still require some additional tweaking, e.g. if your Makefile expects the output of ‘pwd’ to have a /cygdrive syntax.
Hi,
You cannot disable the auto-updating of LDFLAGS in stm32.mak, but you can override them directly in Makefile after the “include $(ADDITIONAL_MAKE_FILES)” line.
Hi,
When setting up a new connection you can uncheck the “setup public key” checkbox.
If that does not help, try reflashing your SD card with a clean image. It looks like a strange Raspberry Pi configuration bug.Hi,
This might be an indication that your Raspberry Pi board is doing some heavy math on the public keys. Does the password-based authentication also take lots of time? Does the output of ‘dmesg’ contain anything suspicious about regenerating keys?
Hi,
Sorry, looks like there is a bit of confusion here. Essentially there are 2 totally independent debugging methods:
1. Using the VMWare stub. In this case VMware serves as a back-end for GDB and the Linux kernel does not even know it’s being debugged. This mode is preferred, as the debugging logic is 100% separated from the kernel and it does not involve a slow simulated COM port.
2. Using KGDB via a virtual COM port. In this case VMWare does not know anything about debugging, but the kernel itself runs a debug stub (KGDB) that communicates to GDB via a COM port.We would recommend setting up the first mode, hence please try checking if you can connect to port 8864 or 8865 on the machine where you run your VM (i.e. where vmware-vmx.exe is executing). Your vmware.log file in your VM directory should contain something like this:
2014-06-28T11:25:56.622-07:00| vmx| W110: Debug stub: VMware Workstation is listening for debug connection on port 8864. 2014-06-28T11:25:56.622-07:00| vmx| W110: Debug stub: target remote localhost:8864Please let us know if that works.
Please note that the COM port settings (e.g. speed) are not relevant in this case, as the debugging mechanisms of the Linux kernel are not being used.Hi,
Your VMX file looks like it contains the “stub” setting, so VMWare should be listening on port 8864 or 8865. Are you able to connect to it manually via gdb (target remote localhost:8864)?
Your GDB log also does not contain the ‘target’ command, so it looks like something breaks before that. Are there any error messages you’re getting?
