[support]

Thanks for confirming your support status. Please find the answer to your inquiry below.

The ‘touch’ command is part of the coreutils package and is typically used to reset the last modification time of a certain file without actually changing its contents. Normally, if you are moving away from an older toolchain, we would advise converting the Make-based projects to MSBuild, as it abstracts out many low-level commands and is better integrated into VS (e.g. it will automatically rebuild the files affected by a change in compiler flags, eliminating the need to manually manipulate timestamps).

Feel free to let us know why you need to use the touch command in your Makefiles and we will try to suggest a better way to do it with VisualGDB and MSBuild.

If you absolutely need to use the ‘touch’ command, it should be OK to simply copy it from the original toolchain and check it into your source control system. It should not have any dependencies on the other toolchain components, so you don’t need to copy the entire toolchain. Also the “cmd /c copy /b filename.ext +,,” should work as long as you prefix it with “cmd /c” and run it in the correct directory.

[support]

No problem, we have pinpointed and fixed the issue in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.5.1.3328.msi

 

[support]

The Toolchain.xml file should be in the location where you have extracted the toolchain during step 1 of this tutorial. If you believe the file is not there, please try downloading/extracting it again and if it’s still missing, please send us a screenshot of the directory with the unpacked toolchain archive.

The OpenOCD installed into %LOCALAPPDATA% is automatically managed by VisualGDB. You can use the Tools->VisualGDB->Manage VisualGDB Packages to automatically update it (VisualGDB normally checks for updates every week). That said, updating OpenOCD would indeed not solve the original problem, as we have not had a chance to reproduce it. If you could step through the OpenOCD source code as it tries to start a debug session with the explicit serial number specified via command line and let us know why it is not handling the serial number argument as expected, we should be able to integrate the fix for it in our OpenOCD fork.

 

[support]

Hi,

It looks like most of the delay happens before gdb sends a reply to the first command. This could be caused by the antivirus interfering with its load, or by extremely slow disk performance. Please try starting the gdb executable manually and observe whether it also takes 16 seconds before it produces any output. If yes, please try disabling any 3rd-party software that could be interfering with this, or try experimenting to see if any other tools (e.g. gcc) get affected.

[support]

Thanks for letting us know. Looks like some solution-related events come in the order not expected by VisualGDB. Please let us know if you open the project via file File menu in Visual Studio, or by clicking on the .sln file in Explorer. Please also let us know whether there are other projects in the same solution and what is the type of the project (Embedded, Linux, Arduino, etc.).

[support]

Hi,

We are prioritizing GUI redesign of different parts of VisualGDB based on the redesign complexity, usability impact of the existing WinForms rendering for a specific part of the GUI and the number of affected users. As for now, we are prioritizing other functionality over conversion of this page.

[support]

Hi,

Just wanted to let you know that we have added full support for specifying which symbols get loaded automatically for Linux projects in the following build: VisualGDB-5.5.1.3322.msi

You can configure it via the Debug Symbols page of VisualGDB Project Properties:

Attachments:

You must be logged in to view attached files.

[support]

Sorry, most likely you have changed some settings or installed a new version of a toolchain/BSP that was not compatible with the existing projects.

Although we do our best to keep VisualGDB releases backward-compatible, it is not possible for us to guarantee the same behavior for every external toolchain, SDK or library that could be possibly used with VisualGDB, sorry.

[support]

Sorry, it looks like your support period has expired. Please consider renewing it here in order to continue receiving technical support.

[support]

Sorry, it looks like your support period has expired. Please consider renewing it here and we will help you get everything to work.

[support]

No problem, we have added it to the backlog and will consider making a tutorial on this in the future.

[support]

Thanks for pointing this out, please try the following build instead: VisualGDB-5.5.1.3317.msi

[support]

Hi,

No problem. Indeed, when using Segger J-Link, VisualGDB would try to parse the esptool command line, reconstruct the FLASH memory layout from it and then load it using the OpenOCD’s commands. This mechanism is relatively fragile, so it might indeed not work in some cases.

In order to track this down, please try the following build: VisualGDB-5.5.1.3314.msi

Then open View->Other Windows->VisualGDB Diagnostics Console and try programming the memory using J-Link.

Once the memory is programmed, please locate the following lines in the diagnostic log:

1. Parsing esptool command should show the command line of the esptool used by the Arduino build system.
2. com.sysprogs.esp32.esptool.binaries.count and subsequent lines should show the FLASH structure reconstructed from the command line. Please check it for any obvious inconsistencies compared to the command line.
3. ExecuteRawCommand(mon program_esp32, <…>, CLI) lines will show the actual FLASH programming commands issued by VisualGDB to OpenOCD. They should match the FLASH memory layout in the esptool command line.

If you can point out a specific part of the esptool command line that gets parsed incorrectly, it should be very easy for us to fix it. However, if it’s not that obvious, we would need you to collect more information:

1. Erase the FLASH memory using esptool.py.
2. Program the memory using the “Arduino tools”.
3. Read back the FLASH memory using esptool.py.
4. Erase the entire memory again
5. Program it using J-Link.
6. Read it back via esptool.py
7. Compare the results (e.g. using fc.exe /b).
8. Finally, post the entire diagnostic log from VisualGDB and the results of the comparison to this thread, or send it via our support form so that we could double-check everything on our side.

P.S. It would also be great if you could either update your forum profile to match the email used in the license key, or send it via our support form so that we could internally link it to your forum profile.

[support]

Hi,

No problem. Although fixing the Espressif’s GDB executable is outside of what we can offer as a part of VisualGDB, we have updated our Arduino project subsystem to allow editing common build parametersvia the regular VS Properties so that you could try the workaround described in the Github issue. Please try this build: VisualGDB-5.5.1.3313.msi

Then open VS Project Properties for the Arduino project, go to C/C++ -> Optimization and set Inline Functions to No. This should affect both the main sketch and the libraries, working around the problem.

 

[support]

Hi,

You can open the Threads view using the Debug->Windows->Threads command in Visual Studio

The VisualGDBExtensibility.dll library is shipped with VisualGDB (normally C:\Program Files (x86)\Sysprogs\VisualGDB\VisualGDBExtensibility.dll). Simply add it as a reference to the project referencing it and you should be able to build it.

[Author]

Posts