[support]

Hi,

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.

[support]

Hi,

Thanks for your feedback. Unfortunately we were not able to reproduce your problem on our side.
Does this happen on one specific project or even on our ‘LED blink’ demo generated by the wizard? Are you using the latest GCC 4.8.2 or an older version?

[support]

Hi,

You can use either NFS shares or SMB shares (via samba) to setup folder sharing between two Linux computers. VisualGDB currently does not support configuring those automatically, however there are numerous tutorials on doing that, simply search online for the one relevant for your Linux distro.

Once you have setup the share simply go to VisualGDB Project Properties, Debug page, update the deployment path and enable the “don’t auto-deploy” checkbox. VisualGDB will then assume that the deployment is done by some other tool and will simply launch debugging using the path you have specified.

[support]

Hi,

Unfortunately we have not tested our tool with Phonon. If it does not work for you, you can either try starting it manually from the console and then attaching to it (select ‘attach’ in VisualGDB Project Properties) or look into the Phonon source to understand what API it is using to interact with the hardware and why it is not working over SSH. You can try selecting ‘Show X11 windows on the remote computer’ in VisualGDB Project Properties to see if it solves the problem.

[support]

Hi,

If you could provide a GDB log and/or screenshots illustrating your problem, we could be able to help you further.

[support]

Are you using some third-party ‘test’ binary. The one included in our Beaglebone toolchain returns 0 when used with slash at the end. You can test it using the following code:

mkdir xxx
test -d xxx || echo ERROR1
test -d xxx/ || echo ERROR2
test -d yyy || echo ERROR3

[support]

Hi,

Which Qt version for Windows have you downloaded?

[support]

Hi,

When we tested it on our side the problem never happened because the Debug directory was created by qmake, so the ‘mkdir’ command was never executed.
Have you changed any files that could result in a change of this behavior? Does doing a full rebuild solve the problem?

[support]

Hi,

This is the limitation of the manual shared folder mode. You can overcome it by switching to the “shared windows folder mode”.
Simply select “Use a shared Windows folder” in the Project Properties, click “Provide information required to mount the local folder” and select your shared Windows folder and the Linux mount point.
This will provide enough information for VisualGDB to know which directories are part of the shared folder and which are not and thus need to be downloaded.

E.g. if you mapped e:projects to /mnt/projects, VisualGDB will open files in /mnt/projects/my_project as well as in /mnt/projects/some_other_project directly, as it will know that all files under /mnt/projects are a part of the Windows share.

[support]

Hi,

This can be an indication of missing tools or a problem in your QT configuration. If you click ‘ignore’ is the project created? Do you encounter any problems while building or debugging it?

[support]

Just FYI: we have patched our STM32 linker scripts to include this fix. You can re-download the STM32 package from the Wizard to get the new fixed scripts.

[support]

Hi,

We have looked into it and added a workaround to VisualGDB 4.1r7. Please note that you can also resolve this issue by updating your GDB to 7.6.

[support]

We have fixed it in VisualGDB 4.1r7. Thanks for reporting this issue.

[support]

We have sent you the source code for the STLTypeVisualizers. If you encounter any issues with it, please let us know.
Regarding octal display, GDB sometimes uses it internally, but we usually convert the values to either decimal or hexadecimal form. If you encounter octal output in some cases, please provide us with repro steps so that we could investigate and fix it.

[support]

The compilation and IntelliSense use two independent source parsing mechanisms, so it could happen that IntelliSense shows false positive errors when its mechanism runs out of sync with the build mechanism.
Regarding svc_uif.h file, is C:UsersUporabnikAppDataLocalVisualGDBRemoteSourceCache192.168.3.207005include referenced in Include Search Path (Visual Studio Project Properties -> NMake -> Include Search Path)?

If __STDC__ is not present in the .h file, this can be happening because GCC does not report it when being tested with your configuration settings. This can be specific to your GCC version or some settings. The easiest workaround would be to create a new file (e.g. called gccfix.h), add it to ‘forced includes’ in Visual Studio Project Properties -> NMake and add the following code to it:

#ifdef _MSC_VER
#define __STDC__
#endif

This should provide IntelliSense with the missing definitions. _MSC_VER is a macro that is defined by Microsoft Compiler (and Microsoft IntelliSense engine) and won’t be present during build with GCC.

[Author]

Posts