[support]

Hi,

This could happen if you press Shift-F5 while VisualGDB is still initializing the debug session. Unfortunately this is a VS limitation that cannot be easily addressed. We may add a workaround to this in the future versions, but it will involve unreliable hooks into VS internals. As a workaround, please press the “Cancel” button in the GDB Session window instead of Shift-F5 if you want to abort a debug session before it has initialized.

[support]

Hi,

Thanks for the explanation. If you want to delete a file written by OpenOCD, please add a command for deleting it to pre-debug actions instead of doing it from the remote console program.

Regarding the output freezing, when you click “freeze”, VisualGDB will buffer the new text and will append it to the console once you unfreeze the output. If you believe some text is lost, we would appreciate the repro steps and would gladly fix this.

[support]

Hi,

Normally you should be able to use the regular os_printf()-like functions and the gdb stub will wrap that output so that gdb (and VisualGDB) will recognize it properly.

However, as many other things on ESP8266 and ESP32, this may not always work.

[support]

Hi,

Sure, please let us know the error messages you get and we will advise you how to fix them.

[support]

Hi,

This looks like some sort of a race condition that occurs very rarely. As the workaround is very simple (just close the window), we don’t prioritize fixing it unless someone reports a 100% repro scenario.

It is hard to say why your program cannot delete the specific file. We would recommend displaying a message box from your program before and after deleting the file and then using Process Explorer to check for open handles to that file and Process Monitor to check why delete fails.

You can disable the scrolling in the remote console window by right-clicking and selecting “Freeze contents”.

[support]

Please send it to sysprogs at sysprogs dot com.

[support]

Hi,

VisualGDB could do that as a workaround if you project path contains spaces (otherwise Make won’t handle dependencies properly). Please move the project to a path with no spaces.

[support]

Hi,

We are sorry about the inconvenience you are experiencing with ESP32. Please note that our ESP32 toolchain is based on the esp-idf 1.0 that does not have an I2C driver. We will update the toolchain once the esp-idf 2.0 is officially released (currently it’s RC1).

Generally the ESP8266 and ESP32 chips are very new and often don’t work or work unreliably, so we can only guarantee that the basic debugging functions covered in our tutorials will work on exactly the same hardware. If you are looking for more reliable hardware that works out-of-the-box, please consider ARM-based devices from major manufacturers instead.

[support]

Hi,

This looks strange. Can you reproduce the same behavior on a basic “hello, world” project and send it to us? If yes, we should be able to fix it quickly.

[support]

Hi,

You would need to download Texane ST-Link sources from github and build them.

Then you can actually reuse the definition file that we made when we supported it officially: create a %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\texane folder and copy st-util and st-flash there. Then create a edp.xml file with the following contents:

<?xml version="1.0"?>
<EmbeddedDebugPackage xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <PackageID>com.sysprogs.arm.texane-stlink</PackageID>
  <PackageVersion>1.2</PackageVersion>
  <GNUTargetFilter>^arm-.*</GNUTargetFilter>
  <UserFriendlyName>Texane ST-Link</UserFriendlyName>
  <SupportedDebugMethods>
    <DebugMethod>
      <UserFriendlyName>Texane ST-Link</UserFriendlyName>
      <ID>texane-stlink</ID>
      <GDBServerApplication>$$SYS:DMSP_ROOT$$\st-util.exe </GDBServerApplication>
      <GDBServerArguments>
          <GNUStyle>true</GNUStyle>
          <Properties>
          <PropertyGroups>
            <PropertyGroup>
              <Properties>
                  <PropertyEntry xsi:type="Enumerated">
                  <Name>ST-Link Version</Name>
                  <UniqueID>com.sysprogs.arm.texane-stlink.version</UniqueID>
                  <Description>Specifies the ST-Link version</Description>
                  <SuggestionList>
                    <Suggestion>
                      <UserFriendlyName>ST-Link v1</UserFriendlyName>
                      <InternalValue>-1</InternalValue>
                    </Suggestion>
                    <Suggestion>
                      <UserFriendlyName>ST-Link v2</UserFriendlyName>
                      <InternalValue></InternalValue>
                    </Suggestion>
                  </SuggestionList>
                  <DefaultEntryIndex>1</DefaultEntryIndex>
                  <AllowFreeEntry>false</AllowFreeEntry>
                </PropertyEntry>
                <PropertyEntry xsi:type="Boolean">
                  <Name>Reset target before programming</Name>
                  <UniqueID>com.sysprogs.arm.texane-stlink.resetcommand</UniqueID>
                  <Description>Automatically resets the target before programming</Description>
                  <DefaultValue>false</DefaultValue>
                  <ValueForTrue>mon reset</ValueForTrue>
                </PropertyEntry>
              </Properties>
              <CollapsedByDefault>false</CollapsedByDefault>
            </PropertyGroup>
          </PropertyGroups>
        </Properties>
      </GDBServerArguments>
      <GDBServerDelay>500</GDBServerDelay>
      <GDBStartupCommands>
        <string>target remote :4242</string>
        <string>$$com.sysprogs.arm.texane-stlink.resetcommand$$</string>
        <string>load</string>
      </GDBStartupCommands>
      <UseContinueToStart>true</UseContinueToStart>
      <SendCtrlCToGDBServer>false</SendCtrlCToGDBServer>
      <RequireExplicitDisconnect>true</RequireExplicitDisconnect>
    </DebugMethod>
   </SupportedDebugMethods>
</EmbeddedDebugPackage>

This will add it to the list of VisualGDB’s debug methods so you won’t need to configure anything manually.

[support]

Hi,

The main step would be to identify whether OpenWRT ships kernel symbols for the stock kernels. If yes, please install the symbol package and then import it into VisualKernel via Tools->Linux Kernel Releases.

If not, you would need to build your kernel with debug information enabled. Our tutorial for building the Raspberry Pi kernel should provide a basic overview of that, although the exact steps can be different.

[support]

Hi,

This looks like your gdb binary crashes when trying to list the arguments for the stack frames. Please try using a newer version of gdb (not VisualGDB) or disable the “argument values” checkbox in the Call Stack window so that VisualGDB won’t query argument values from gdb.

[support]

Hi,

Sorry for the confusion. Please see the comment on github regarding OpenOCDPackage.

The behavior you are describing with gdb stub is to be expected. After your program initializes, it calls gdbstub_init() that outputs the “$T05#b9” packet and waits for gdb to connect. This is needed so that you can debug the initialization code of your program. If gdb never connects, ESP8266 will wait forever.

We recommend disabling the call to gdbstub_init() in the release builds to avoid this.

[support]

Hi,

We have experienced this on one of our boards – despite not returning any error codes, the FLASH programming functions did not overwrite anything. Again, as many things on ESP8266, it’s hard to say where the problem is as the FLASH programming code in ESP8266 is not open-source.

Please try first loading your program via the bootloader mode (or erasing the FLASH completely). This may reset the state of the FLASH and make it programmable via JTAG.

[support]

Hi,

We have discontinued the Texane debugger as it was less reliable than OpenOCD. You can still download it from github and specify as “custom gdb stub”, but we no longer ship a pre-built one with VisualGDB.

Slow loads could be the case if you are using a VM with USB virtualization, but should normally not happen on physical machines. If you are not using a VM, please try enabling the timing analysis mode in the GDB Session window and then check which command takes most of the time. Perhaps you are programming a large image with OpenOCD and a smaller one with the ST tool?

[Author]

Posts