Forum Replies Created
-
AuthorPosts
-
September 13, 2017 at 19:08 in reply to: Cannot start GDB: Target Machine Actively Refused It #12369
support
KeymasterHi,
Please check the GDB stub output (e.g. Segger GDB stub) via Debug->Windows->GDB Stub. It should contain detailed information about the error.
support
KeymasterHi,
By regular, do you mean the Linux edition? If yes, please create a normal cross-compilation project as shown here and modify its debug settings so that it will debug your application instead of its build output (that should be ignored). Note that you would need to manually copy the built ELF file from the Linux machine to the Windows machine so that the Windows gdb can load it.
support
KeymasterHi,
Thanks for checking this. It actually looks like despite enabling Clang IntelliSense, your project might not be using it (Clang error messages should be prefixed with [Clang IntelliSense]). Could you please post the screenshot of the entire VS window and the contents of View->Clang IntelliSense Diagnostics Console so that we could check that it got loaded properly?
September 13, 2017 at 06:36 in reply to: New User – Blank project (LEDBlink.cpp) won't compile: dma.cpp compiler errors #12362support
KeymasterHi,
Thanks for the screenshot. This is a known bug in the MSP432 driver library. Please locate the debug.h file and change the definition of ASSERT() to always ignore the argument:
#ifdef DEBUG #define ASSERT(expr) #else #define ASSERT(expr) #endif
or simply
#define ASSERT(expr)
support
KeymasterHi,
This could happen if your gdb and gdbserver were not 100% compatible. Please ensure that your gdbserver comes from the toolchain provided by your device vendor. If not, we would recommend either debugging directly on the device, or building a gdb binary using the same sources (including Debian patches) and the same settings as your target gdb has.
support
KeymasterHi,
No problem. The easiest way to do this would be to use Debug->Quick Debug command (requires Custom edition) and select:
- Target: Linux system
- Use a cross-compiler on the Windows machine
Then VisualGDB will let you choose a toolchain containing the gdb. Simply click “locate a cross-toolchain by finding its gdb.exe” and point it to your gdb executable.
If you use regular VisualGDB projects to build your project, we can help you configure them as well. Do you use the regular “start a new instance” setting?
support
KeymasterHi,
A cross-gdb is a Windows build of gdb targeting your Linux machine. You can normally obtain it by downloading the sources for the same version of gdb as your Linux VM uses (applying Debian patches if relevant) and building it on Windows from a MinGW shell (you would need to specify target and the target options to 100% match the configuration of your Linux gdb).
As a result you will get a gdb.exe that can run directly on Windows and communicate to the remote target via the gdbserver protocol.
You can also try using one of the gdb binaries from this archive, however they may end up being incompatible with your target due to incompatible flags.
September 11, 2017 at 18:41 in reply to: New User – Blank project (LEDBlink.cpp) won't compile: dma.cpp compiler errors #12351support
KeymasterHi,
It’s hard to say what could be causing it without knowing the context (it could be a typo in the device library, incompatible setting, old gcc or a missing #define somewhere). Please let us know which device family you are using and attach a screenshot of the source file with the line causing the error and we will help you resolve this.
support
KeymasterHi,
VisualGDB itself does not have any limits on command line lengths (it actually uses response files to avoid any implicit limits set by Windows).
The behavior you are experiencing might be caused by the WinForms text box control used across VisualGDB settings. Please try using the VS project properties instead (or edit the .props file manually).
support
KeymasterHi,
Thanks for the screenshots. At the first glance, the 2 projects look equivalent. Can you confirm that opening one of them with VS2017 works and the other one opened with VS2017 fails?
The message box you attached looks like it’s produced by Visual Studio before and VisualGDB logic gets triggered, so most likely it is caused by either corrupt MSBuild platform definition, or some installation-related problems. Uninstalling and installing back VisualGDB (and VS if this doesn’t help) might resolve this.
support
KeymasterHi,
Sorry, not currently. VSCode is a completely different product from the regular VS and supporting it would essentially mean creating a completely independent plugin re-implementing most of the functionality using a different stack.
support
KeymasterHi,
No problem. Regarding the environment, we usually recommend choosing “fix value” if you are unsure. This works around the case where some PATH variables are applied for regular console sessions, but not for ‘command’ sessions used by VisualGDB to launch the debugger, leading to hard-to-trace “library not found” errors.
support
KeymasterHi,
Most likely your toolchain is not compatible with the target system image.
Please ensure you are using EXACTLY the same SD card image as listed for your toolchain on the toolchains page: http://gnutoolchains.com/raspberry/support
KeymasterHi,
Please try installing the latest v5.3 Preview 8. Then click at the ‘show details’ hyperlink in the exception window and post the details here. This should help us understand what could be causing it.
Another quicker solution would be to simply re-create the project via VisualGDB Project Wizard and compare the settings with the original project. Most likely some of the settings in the .vcxproj file got accidentally replaced by an empty string.
September 9, 2017 at 01:33 in reply to: New Embedded Project Window: No option to import an existing IAR project #12329support
KeymasterHi,
This feature was added to VisualGDB 5.3 and is not available in v5.2. Please ensure you install the latest preview build.
-
AuthorPosts