[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.

[support]

Hi,

You can use the objcopy tool to add arbitrary sections to an ELF file at given addresses. A sample use of objcopy to replace a section in the file is shown in our Keil tutorial: http://visualgdb.com/tutorials/arm/keil/

Simply take the ELF file you want to debug and use objcopy to attach the contents of other files (.bin files produced from .elf files) at the addresses where you want them to be. Ensure you set the sections flags correctly (see the flags on the main code section) so that GDB can program your file.

Let us know if that works for you.

[support]

Are you getting the same error as mentioned in the original message? If yes, it can be caused by the Windows DNS cache and stopping the “dnscache” service might help.

[support]

Hi,

Can you ping your remote machine? If no, please check your IP address/subnet mask/gateway settings.

If yes, the firewall on the remote machine might be blocking the connections to the gdbserver. Please try disabling the firewall on the Linux side.

[support]

Hi,

We have added the $(TargetFileNameWithoutExtension) variable to the upcoming release of VisualGDB 5.0. The next beta will include support it.

[support]

Are you using the same user account for the remote debugging and for logging on to the console? If not, you may need to configure xauth.

When you select “show on remote computer”, VisualGDB simply sets the DISPLAY variable to “:0” redirecting the X11 output to the default server. Can you reproduce the same problem by running “export DISPLAY=:0 && <command>” manually via SSH?

[support]

Hi,

It looks like some sort of an incompatibility problem between your device and your toolchain. Please double-check the following:

• Ensure that your toolchain is compatible with the image version on your Raspberry Pi
• Ensure that you have re-synchronized the sysroot of your toolchain with the device

If nothing helps, please try compiling your program directly on Raspberry Pi and let us know if that works.

[Author]

Posts