Forum Replies Created
-
Posts
-
Hi,
Sorry, VisualGDB projects are designed to be built separately from each other (and without Visual Studio itself), so they don’t inherit the normal Visual Studio variables like SolutionDir.
Hi,
Looks like you are missing a reference to the libsmartconfig.a file. Please try adding it to your project (or adding “smartconfig” to the Library Names field in the Linker Settings).
Hi,
This could be caused by incompatibility between the gdb from your crosstoolchain and the target gdbserver. Please try running gdb on the target machine manually (gdb <executable>). If this works, you would need to switch the project to be compiled and debugged on the Raspberry Pi directly or get a cross-build of gdb that is compatible with your target image.
Hi,
Sorry, still did not receive anything. Are you using the support form here [http://sysprogs.com/support/]?
Could you please post the ticket number from the confirmation page shown after you create a support ticket so that we could look it up?
Hi,
This is not supported yet, so the easiest workaround would be to use a Linux VM (or the Windows 10 Linux Subsystem) and run the tests there.
Hi,
We are aware of this and have added an option to suppress the deadlock message unless the deadlock call stack includes VisualGDB-related frames. As a temporary workaround please try disabling the deadlock detection unless you encounter actual deadlocks.
Hi,
This looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.3.1675.msi
Hi,
This is not supported yet. We are currently looking into automatically importing GPDSC files generated by STM32CubeMX, but before this feature is available, the only way to regenerate the project would be to re-import it or copy the files to the project directory manually.
Hi,
This is actually a matter of price/value. There are indeed products like CrossWorks and Keil that ship detailed and accurate register definitions for all devices, while providing much more basic IntelliSense and debugger experience. VisualGDB instead focuses on usability features that apply to all device families (like advanced IntelliSense or real-time watch), while relying on the device manufacturers’ definitions for hardware registers. This works very well for most of the families (most vendors provide either machine-readable definitions in the ARM SVD format or machine-generated header files that we parse).
Unfortunately TI devices are somewhat of an exception – their header files seem to be hand-edited and they don’t ship machine-readable definitions under a license that allows reusing. Also as their market share is relatively low (below 3% among our users), any feature that will add value to all device families will always get higher priority for us than resolving minor glitches in TI definitions (major bugs like the one you mentioned before are a priority).
If you are a licensed user of Keil or CrossWorks, you might be able to convert their register definitions to a format that VisualGDB supports for your own use (please double-check check their license terms to be sure). If you decide to go this way, we can provide step-by-step instructions on locating/replacing VisualGDB register definition files.
Hi,
Not sure what did you mean. Do you mean updating the list of source files in the Makefile once you add new files to Visual Studio Solution Explorer?
Hi,
So far we don’t have any tickets associated with your email address (and no unanswered tickets with crash dumps). Please try re-submitting it.
Hi,
Yes, you can add “VERBOSE=1” to make (not CMake) command template and rebuild the project. This should get CMake to print the command lines it is using.
Hi,
Yes, you can add “VERBOSE=1” to make (not CMake) command template and rebuild the project. This should get CMake to print the command lines it is using.
Hi,
Thanks, we have added this to the backlog and will consider supporting it in the next version of VisualGDB (after v5.3).
Hi,
It looks like the arm_neon.h file contains some checks that deem the current configuration (determined from checking built-in preprocessor macros via #ifdef’s) invalid. The best way to investigate it would be to look into the file that produces the error and see which exact #ifdef tests it performs.
