[support]

@parsec67, thanks for your input. We will try to clarify what is going on below.

Based on the log file, the error happens during the USB connection phase, before the target script takes any effect:

hla_layout.c:47 hl_layout_open(): failed

The .tmp script is used when you modify the JTAG/SWD frequency via settings for device scripts (such as STM32F4) that have it hardcoded. In that case, VisualGDB will create a temporary copy of the script, edit the frequency there and pass it to OpenOCD.

OpenOCD generally works well with ST-Link v1, v2 and v2.1. We have internal tests checking it and many of our customers are successfully using it. Based on the input we have collected in the past years, in ~0.1% of the cases, it would simply fail to recognize the USB device. This has been previously caused by:

• 3rd-party USB-over-network software
• VMWare USB virtualization not releasing the device properly (normally it works with VMWare)
• A USB host controller by a non-mainstream vendor that was not compatible with libusb
• Unidentified problem with Windows USB drivers that got resolved by uninstalling the device drivers and reinstalling them from scratch

Given the the issue occurs very rarely and is located in an external component (libusb) and seems to be triggered by a different set of factors each time, unfortunately it’s hard for us to suggest any specific diagnostic steps other than trying a different computer (assuming that the issue happens from the very beginning with the default settings). We mentioned J-Link because it comes with its own USB driver and software and does not rely on libusb.

Hope this explains and sorry we couldn’t suggest anything more specific.

[support]

Hi,

This looks like some sort of driver incompatibility between OpenOCD and ST-Link. Unfortunately, as a free tool, OpenOCD sometimes doesn’t work with some USB controller/device combinations.

Generally, if you are looking for a hardware solution that works 100% reliably, please consider trying Segger J-Link. It is more expensive than ST-Link, but comes with its own equivalent of OpenOCD that is fully covered by Segger’s support and is compatible with more devices. VisualGDB fully supports it as well as OpenOCD.

Alternatively, please try the OpenOCD-based setup on a different machine (i.e. with a different USB host controller), or try reinstalling the ST-Link drivers.

[support]

Hi,

Good to know it works. If you encounter further issues, please don’t hesitate to create another thread.

[support]

Hi,

Thanks for sharing the details. Most likely the custom actions you have configured do not preserve the folder structure you have on the Windows side (e.g. ProjectDirA gets deployed to /tmp/ProjectDirA, but SharedFiles gets deployed to /tmp/ProjectDirA/SharedFiles, so ../SharedFiles is not a valid path anymore on the Linux side).

Please double-check the relative paths of the files on the Linux side (you can run the “find .” command in the root directory via SmarTTY to get a recursive list of all files in all subdirectories).

If nothing helps, please share the paths of all relevant files on the Linux machine and your .msbuild-mak file and we will help you find the inconsistency.

[support]

Hi,

Please simply use the “Custom Build Steps” page of VisualGDB Project Properties to add steps for uploading the directories you need.

If you are not sure, please let us know which directories you would like to upload and where and we will help you find the correct settings.

[support]

Hi,

Thanks for sharing this. Good to know it works.

[support]

Hi,

Thanks for the detailed bugreport. We have fixed this in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2601.msi

[support]

Hi,

No problem. Feel free to follow us on Twitter to stay informed about the latest updates.

[support]

Hi,

Good to know it works. If you encounter any further problems, don’t hesitate to start another thread.

[support]

Hi,

If building the project manually (after a full clean) still results in an error, please try creating a new project from scratch (or cloning one of the sample projects) and try building it as well. If the newly created project builds, please analyze the differences between it and your project (configuration files, Makefiles, command-line arguments), or try combining different parts of the 2 projects to see which part triggers the problem.

[support]

Hi,

Thanks for reaching out to us. Please note that as maintaining a high quality up-to-date product with technical support requires continuous effort on our side, we have to be relatively strict with our licensing fees and are not able offer long-term trial extensions. We offer a 30-day trial period to help our prospective users understand whether our products match their requirements/expectations and can be used in their environments, but unfortunately we are not able to provide any free offerings beyond that.

That said, we might be able to provide a short trial extension in some cases (e.g. where you could not evaluate specific features/scenarios). If this is the case, please feel free to contact our sales with a detailed description of your situation and we will get back to you shortly.

[support]

Hi,

This might be caused by an invalid combination of tools used to build the project (e.g. using a non-Cygwin Make executable with Makefiles generated in the Cygwin environment, or vice versa).

Please check the VisualGDB build log (via View->Output) for the exact command line used by VisualGDB to build the project. Then try running it manually.

If that exact command line results in an error, but running Make from terminal works, please review the differences between the manual environment and the command pasted from the build log (e.g. ESP-IDF location, PATH, etc). Most likely some environment variable, sdkconfig setting or command-line flag is triggering the problem.

[support]

Good to know it works. The IntelliSense cache uses incremental snapshots, so it will normally only reparse the changed files (if you are editing a header file included from multiple source files, it will invalidate all of those source files).

If you believe too many files are re-cached, please try the following:

1. Open Clang IntelliSense Diagnostics Console and clear the log
2. Edit one file and trigger the cache rebuild
3. Let us know the file you edited and share the output shown in the Diagnostics Console. It should normally mention why the cache is being rebuilt, so we can help you understand what is going on.

[support]

Hi,

Thanks for the update. We can still help you get it to work – VisualGDB supports both Keil v5 and v6, so if there is a combination of tools that works with the uVision IDE, it should be possible to configure VisualGDB accordingly.

Please feel free to submit more details (project file, assembly file, exact error messages) via our support interface and we will help you get it to work.

[support]

Hi,

Sorry, this is showing the flags for the main source file, but not for the project itself. Please click at the project name and then copy the CXXFLAGS.

Also the diagnostics console shows that the Clang server process has terminated. Was this caused by reopening the project, or does this message seem to occur randomly?

[Author]

Posts