[support]

Hi,

AHBPrescTable should normally be defined in system_<device family>.c that is generated by the STM32CubeMX. Please double-check that your project includes it and that it includes the definition of AHBPrescTable.

If it does not, please compare its contents with the system.c shipped with VisualGDB (that comes from the STM32 sample projects) and ensure that your STM32CubeMX configuration includes initialization of the clock module.

[support]

Those features are available starting from the Custom edition of VisualGDB. If you have purchased a lower edition and want to use them, you can always upgrade. Simply contact our sales and they will give you an upgrade quote and a purchase link.

[support]

Hi,

VisualGDB uses the default reset sequence from the Espressif’s esptool.py, but you can override this in the Debug Settings. Simply change the default bootloader sequence (!DTR;RTS;SLEEP;DTR;!RTS;SLEEP;!DTR;SLEEP) to the one that will work with your wiring.

If you cannot get JTAG to work reliably, we recommend using the ESP8266-EVB board from Olimex. It appears to be generally more reliable than the original ESP-xx modules.

 

[support]

Hi,

Sorry for the delayed reply. Looks like there was a bug in our template exporting mechanism. We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.936.msi

If it still does not work, please let us know.

[support]

Hi,

We are sorry about this bug. To diagnose it quickly we have added extra error logging to this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.5.916.msi

Could you please try it and let us know if the problem still persists and what error message is shown if it does?

[support]

Hi,

We now have a preview build of VisualGDB with the new advanced memory window feature. The new memory window contains workarounds for J-Link stub crashes, can read memory using the live engine while the program is running, allows highlighting global variables, functions and stack frames and is integrated with the Live Variables and Visual Watch features. You can try the preview build here: VisualGDB-5.2.5.916.msi

[support]

Hi,

It is strange that the gdb does not react to Ctrl-C/Ctrl-Break properly. If there is any reason why the workaround you discovered does not work, you can try clicking “Setup advanced GDBServer settings” on the Debug Settings page and then selecting “Break All sends Ctrl-C to gdbserver”. If you discover further problems, feel free to contact us again.

[support]

Hi,

Looks like the ST-Link might be leaving the target in a state where it does not respond to SWD requests properly. Please try unplugging/replugging the JTAG programmer and check if the problem also happens when programming a basic “Hello, World” program. Perhaps something in your firmware interferes with the debug unit.

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

[Author]

Posts