[support]

Looks like the first problem is caused by some broken symlinks on the Linux side. You can investigate this by running “ls -l” in the target directory and checking that all symlink targets exist.

The glibc problem can be caused by incompatibility between your toolchain and the system image. Please try the instructions described here: http://sysprogs.com/w/forums/topic/raspberrypi-undefined-reference-to-clock_gettimeglibc_2-17/

[support]

Hi,

VisualGDB Linux edition can only upload sources from one directory (with arbitrary subdirectories), so you can simply change the source directory to point to the parent one if that helps. If your source files are scattered around several directories, you would need additional file transfer actions that are available in the Custom edition and higher.

Note that if you have purchased a license recently, you can upgrade from Linux to Custom for just the price difference.

[support]

Hi,

We have looked into the new TI MSP430 toolchain. Although it is based on the newer tools, it currently contains one major bug: if you use the -ffunction-sections flag that helps removing unused code from your binary, the debug symbols become unusable.

We have repackaged the toolchain (without TI proprietary tools) and uploaded it together with a one-click installer here: http://gnutoolchains.com/msp430/

Remember to remove the -ffunction-sections flag from the debug configuration flags, as otherwise you won’t be able to debug your code.

[support]

Hi,

Thank you for your feedback. We indeed did not update the MinGW64 toolchain because there is not much demand for it among our users. For the popular areas (like embedded ARM, supporting new Linux-based platform, etc) we do actually publish updated toolchains.

Furthermore, VisualGDB is not limited to a specific set of toolchains! You can use any MinGW release you wish. Simply point VisualGDB to it and it will be able to integrate with it. That’s why instead of rebuilding something that already exists we focus on adding usability features, quick setup features and state-of-the-art IntelliSense.

If you say VisualGDB is absolutely not worth it, you could try setting up Eclipse with the same toolchains. However you would quickly find that many time-saving features provided by VisualGDB are missing there. Regarding your .Net suggestion, thank you for it, we will address it in the next release.

[support]

Hi,

VisualGDB currently does not support merging changes between the Linux and the Windows checkouts. The easiest workaround would be use a Windows SVN client to check out the repository on the Windows side and do an update there as well so that SVN can handle change merging for you. During the next build VisualGDB will only retransfer the changed files to the Linux machine.

Thanks for pinpointing the typo, we have fixed it.

[support]

Hi,

Sorry for the misunderstanding. The “MemU32” command is handled by the Segger GDB stub directly, so the caching actually happens inside the Segger stub.

From a quick look (“mon help” command) it seems that it does not have a specific command for resetting the cache. Please try one of the 2 options:

1. Contact Segger support. They should be able to suggest a workaround or release a hotfix.

2. Try using OpenOCD. It is less stable and usable than the original Segger software, but it may not have the cache problem.

If nothing helps, ensure that the problem is not caused by the CPU cache. Try reading one specific word from FLASH to a local variable in your firmware and examine the value of this variable using the debugger. If the value is also wrong, you need to reset the CPU cache.

 

[support]

Hi,

This happens because VisualKernel hooks the log_store() function in order to display the output of printk(). You can disable this feature via VisualKernel Project Properties (debug settings page), however then you won’t see the printk() output in Visual Studio.

[support]

Hi,

Looks like the command syntax has changed in the newer versions. Please try the following command:

mon memU8 0x<address>

or

mon memU32 0x<address>

[support]

Hi,

This error message can be caused by lots of different problems. In order to pinpoint a specific cause and suggest a solution we need to examine the full GDB log (see this page for instructions on obtaining it).

Please submit the log either here or via our support form so that we could help you pinpoint the problem.

[support]

This is not possible directly, however you can use 2 workarounds:

• If the settings you want to change are host/user names, consider using SSH aliases: http://visualgdb.com/tutorials/linux/aliases/
• For other settings consider doing a find-and-replace in the .vgdbsettings files. Those files contain all VisualGDB settings in XML format.

[support]

Which versions of VAX and VS are you using? We have received feedback about incompatibility with VAX before, but could not reproduce it with the latest version.

You can also disable the Clang IntelliSense globally by setting HKCU\Software\Sysprogs\VisualGDB\Settings\CppLanguageServiceSupport to 0.

[support]

Hi,

Looks like the old values get cached at some point. The first step would be to see whether the caching happens on GDB level or on Segger level.

Please try issuing the following command in the GDB session window:

mon mem32 <address>, <bytes> (see this PDF for details: https://www.segger.com/cms/admin/uploads/productDocs/UM08001_JLink.pdf)

Does it show the new or old memory contents?

[support]

If you are using an NTFS partition, VisualGDB should translate Linux symbolic links into NTFS symbolic links. Can you pinpoint one specific link that gets broken and share details on it (what is the link target and what do you get on the Windows side after synchronizing)?

[support]

Looks like -m32 was specified in CFLAGS, but not in LDFLAGS, Please specify it in LDFLAGS as well.

[support]

This can be caused by lots of different causes ranging from ip/netmask settings to your gateway routing configuration. Putting both hosts in the same network is indeed the easiest solution.

[Author]

Posts