[support]

Hi,

The Keil components are fully supported, although due to the relatively high complexity of the Keil pack definitions, this feature is only available in the Custom edition. If you are using a lower edition, please consider creating a project in the uVision IDE, discovering the list of source files and preprocessor macros and adding them manually to your VisualGDB project.

[support]

Hi,

For Keil projects VisualGDB imports the device list (and the packages) directly from the Keil packs. Hence please double-check that you can create a project for your device using the uVision IDE. If not, please install the missing Keil packs and restart Visual Studio. VisualGDB will then rescan the Keil packs and show the devices in the device list.

[support]

Hi,

This might be a remnant from the old Cygwin-based toolchain. Please try installing the latest ESP32 toolchain and create the project from scratch. If this solves the problem, please re-import your project into VisualGDB.

[support]

Hi,

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2617.msi

[support]

Hi,

Sorry, that probably comes from the fact that you are using templates. Counting references for templates is fairly complicated due to the way compiler tracks them internally, so the one-line summary may indeed not be 100% accurate (it has to be computed using a somewhat simplified logic due to performance constraints). We should be able to eventually fix this, however we won’t be able to fit it in v5.4.

[support]

Hi,

Good to know it works. Just in case anyone else runs into the same problem, here’s another workaround to this: https://blogs.msdn.microsoft.com/shawnfa/2008/03/14/disabling-the-fips-algorithm-check/

[support]

Hi,

No problem, we can help you, however it looks like your technical support has expired. Please renew it and we will be happy to walk you through resolving this.

[support]

Hi,

It looks like your technical support period has expired. Please renew your license here and we will be happy to help you resolve this.

[support]

Hi,

Sorry, it’s a known bug of Preview 10. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2610.msi

[support]

Hi,

Sorry about that, it’s a known issue with Preview 10. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.10.2609.msi

[support]

Hi,

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

Simply select a shared checkout when creating a new project and VisualGDB will automatically configure it for you.

Thanks again for the wait and let us know if you have any further questions/suggestions.

[support]

Hi,

Thanks for the video. It looks like when CMake updates the target list, the targets are reported in a different order (FaceServiceTest.exe gets in front of libFaceService.a) and hence the ‘expanded’ flag isn’t preserved properly. As a workaround, please set the “Sort targets by name” option via VS Project Properties (not VisualGDB Project Properties) -> Project Items->Sorting/Grouping.

[support]

Hi,

This would happen if VisualGDB could not display the normal project structure queried from CMake (normally it is cached and should not be lost).

Would it be possible for you to create a quick video of this? If we could see the exact timing of the problem and the exact icons shown in Solution Explorer, we should be able to tell what is going on.

[support]

Hi,

We have tried reproducing it on a clean project for the Generic ESP8266 Module, however could not get the behavior you are describing.

Please check if you can reproduce it on a project created from scratch and that you do not change the sketch folder in the .vgdbcmake file. If it doesn’t help, please share the build command line shown in the Output window after the “Launching Arduino builder” text.

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

[Author]

Posts