[support]

Hi,

The command should be placed in the “Before launching GDB” list. Then the command will be launched each time you debug and will set the variable for the duration of the debugging session.

Here are the relevant parts of the .vgdbsettings file:

<?xml version="1.0"?>
<VisualGDBProjectSettings2 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <ConfigurationName>Debug</ConfigurationName>
  <Project xsi:type="com.visualgdb.project.linux">
    <CustomSourceDirectories>
      <Directories>
        <SourceDirMappingEntry>
          <RemoteDir>$(DirName)</RemoteDir>
          <LocalDir>e:\temp</LocalDir>
        </SourceDirMappingEntry>
      </Directories>
      <PathStyle>RemoteUnix</PathStyle>
      <LocalDirForAbsolutePaths />
      <LocalDirForRelativePaths />
    </CustomSourceDirectories>
  <CustomDebug>
    <PreDebugActions>
      <CustomActionBase xsi:type="SetVariableFromCommandAction">
        <SkipWhenRunningCommandList>false</SkipWhenRunningCommandList>
        <RemoteHost>
          <HostName>BuildMachine</HostName>
          <Transport>BuiltinShortcut</Transport>
          <UserName />
        </RemoteHost>
        <Command>echo</Command>
        <Arguments>/tmp</Arguments>
        <WorkingDirectory>$(BuildDir)</WorkingDirectory>
        <Environment>
          <Records />
        </Environment>
        <VariableName>DirName</VariableName>
        <RegularExpression>(.*)</RegularExpression>
      </CustomActionBase>
    </PreDebugActions>
    <PostDebugActions />
    <DebugStopActions />
    <BreakMode>Default</BreakMode>
  </CustomDebug>
</VisualGDBProjectSettings2>

If this does not help, please send us your .vgdbsettings file so that we could check what is wrong with it.

[support]

Hi,

Please let us know what error message you are getting and we will try our best to help you.

[support]

Hi,

VisualGDB uses the Windows cryptographic service to store the keys. The container name is com.sysprogs.smartty.dsa. You can manage the key from a C# application using the DSACryptoServiceProvider class.

[support]

Hi,

This is a known issue. MinGW-based and Cygwin-based executables use different mechanisms of sending a Ctrl-C event. VisualGDB actually allows switching it via VisualGDB Project Properties, but the exact location of the setting depends on your project type. Are you using a regular embedded project? Could you attach a screenshot of your Debug Settings page?

[support]

Hi,

Sure, please open VisualGDB Project Properties, go to the Custom Debug Steps page, find Pre-Debug action list, click “Edit” and then add an action like this:

Then you can simply reference $(TestVar) from your path mappings in VisualGDB Project Properties.

[support]

Hi,

VisualGDB simply runs the Command-line J-Link GDBServer on your Windows machine and attaches to it. We are not aware of any additional licensing restrictions required to do that, but if you have any doubts, please double-check this with Segger support to be 100% sure.

[support]

Hi,

OK, this looks like a wiring problem. Regarding UART, please try opening the port in SmarTTY (using 74880 baud rate) and resetting the board. Do you see any output? If not, please try experimenting with the baud rate, perhaps the device is not detecting the crystal frequency properly.

Regarding JTAG, the ESP8266 chip is very unstable and sensitive to things like timings, so the easiest way to see if anything is working at all is to create a project based on the NOFLASH device and see if it can work. If not, please share your OpenOCD log so that we could check it for common errors. If the NOFLASH example works, but the regular one does not, please try experimenting with the “Device reset mode” in the debug settings. If this does not help, please share the GDB and OpenOCD log of the unsuccessful JTAG session so that we could give further advice.

[support]

Hi,

It’s a known issue that will be addressed in the next version with an improved version of the Memory window that relies on the faster live memory interface. We expect to have a preview build with this feature at the end of the next week. As a temporary workaround, please use the ‘x’ command in the GDB Session window manually.

[support]

Hi,

You can solve this in 2 steps:

1. Create a custom pre-debug action that will query the current GUID value and store it in a VisualGDB variable
2. Use the variable (e.g. $(MyGUID)) in the path mapping in VisualGDB Project Properties

Let us know if you need further details.

[support]

Hi,

Yes, you can simply provide your own implementations for the _isatty() and _write() functions and the newlib will call them. We recommend looking into FastSemihosting.cpp and copying the code surrounded by “#if FAST_SEMIHOSTING_STDIO_DRIVER” into your own source file. Note that you need to declare those functions as extern “C” as otherwise the newlib won’t recognize them properly.

[support]

Hi,

Thanks for the kind words and we are sorry that the debugging is not working yet.

Installing other plugins should not affect this, as it looks like some sort of a compilation flag/tool problem.

Please try creating a project with a VisualGDB toolchain and using the default VisualGDB settings. This should get a working starting point. Then you can simply compare the build logs and the produced binaries side-by-side to simplify figuring out what is causing this. Feel free to share the details of your progress so that we could give further advice.

[support]

Hi,

This is a known bug of GDB. Please try enabling the “Use X command to read memory” option in the VisualGDB Project Properties (GDB Settings page).

[support]

Hi,

Kinetis KSDK 2.0 uses a different approach for structuring files than the previous versions, please try creating a project manually by following the legacy device tutorial: http://visualgdb.com/tutorials/arm/legacy/

​​You would normally need to import at least the following files:

• The startup file (.S)
• The linker script (.ld)
• ​The drivers files (e.g. fsl_gpio.c)

If this does note help, please let us know the details on the errors you encounter so that we could help you further.

[support]

Hi,

Thanks, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.904.msi

[support]

Hi,

Are you using one of our toolchains, or your own one? Sometimes the default debug format produced by a certain version of gcc is unreadable by certain versions of gdb. We test for that in our toolchains, but if you are using your own one, this might be the case.

After changing the debug format (it should be -gdwarf-<version> as described here) do you see the list of source files when running gdb on your .o files manually?

[Author]

Posts