[support]

Hi,

This happens because the latest Android SDK removes support for Ant-based builds and only supports Gradle/CMake for C++ code.

As a workaround please try using this SDK: https://dl.google.com/android/repository/tools_r25.2.5-windows.zip

We will look into extending our new CMake project subsystem to Android projects after the final VisualGDB 5.3 release; until then please use the older SDK as a workaround.

[support]

Hi,

Thanks for the dump files, it looks like a memory corruption bug. In order to diagnose it, please try the debug build of the engine: http://sysprogs.com/files/tmp/CppEngineCore64.7z

Once it triggers an error (or an assertion), please create another dump file and send it to us.

P.S. Please use a file hosting service like DropBox (you can encrypt the .7z file and specify the password in the support ticket) instead of attaching large files to the tickets. Large attachments slow down the helpdesk system we are using and hence we limit the attachment size to 4 MB.

[support]

Hi,

If your code relies on any STM32-specific code (like HAL), it won’t automatically run on Windows either and will need to be ported using some sort of an abstraction layer (you can manually add Linux configurations to an Embedded project via VS Configuration Manager and then copy the .vgdbsettings file from another Linux project). The amount of porting effort will be the same for both Linux or Windows (the only advantage of running tests on Windows would be no need for a Linux VM, but this is solved with the Windows 10 Linux Subsystem).

[support]

Hi,

Please use the -Wl,-Map=… syntax instead. Note that if you are using MSBuild, you can enable map file generation via VS Project Properties -> Linker Settings -> Advanced (not VisualGDB Project Properties).

[support]

Hi,

This is to be expected if your code is using any other optimization level than -O0 (if you are using ESP32, you need to set -O0 optimization for your source files while keeping -Og for the ESP-IDF sources due to bugs in ESP-IDF).

[support]

Hi,

Normally, you can just remove the reference to “STM32 HAL” via the Embedded Frameworks page. This should leave the startup code, vectors and the linker script (you would need to change the main source file).

[support]

Hi,

Sorry, VisualGDB projects are designed to be built separately from each other (and without Visual Studio itself), so they don’t inherit the normal Visual Studio variables like SolutionDir.

[support]

Hi,

Looks like you are missing a reference to the libsmartconfig.a file. Please try adding it to your project (or adding “smartconfig” to the Library Names field in the Linker Settings).

[support]

Hi,

This could be caused by incompatibility between the gdb from your crosstoolchain and the target gdbserver. Please try running gdb on the target machine manually (gdb <executable>). If this works, you would need to switch the project to be compiled and debugged on the Raspberry Pi directly or get a cross-build of gdb that is compatible with your target image.

[support]

Hi,

Sorry, still did not receive anything. Are you using the support form here [http://sysprogs.com/support/]?

Could you please post the ticket number from the confirmation page shown after you create a support ticket so that we could look it up?

[support]

Hi,

This is not supported yet, so the easiest workaround would be to use a Linux VM (or the Windows 10 Linux Subsystem) and run the tests there.

[support]

Hi,

We are aware of this and have added an option to suppress the deadlock message unless the deadlock call stack includes VisualGDB-related frames. As a temporary workaround please try disabling the deadlock detection unless you encounter actual deadlocks.

[support]

Hi,

This looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.3.1675.msi

[support]

Hi,

This is not supported yet. We are currently looking into automatically importing GPDSC files generated by STM32CubeMX, but before this feature is available, the only way to regenerate the project would be to re-import it or copy the files to the project directory manually.

[support]

Hi,

This is actually a matter of price/value. There are indeed products like CrossWorks and Keil that ship detailed and accurate register definitions for all devices, while providing much more basic IntelliSense and debugger experience. VisualGDB instead focuses on usability features that apply to all device families (like advanced IntelliSense or real-time watch), while relying on the device manufacturers’ definitions for hardware registers. This works very well for most of the families (most vendors provide either machine-readable definitions in the ARM SVD format or machine-generated header files that we parse).

Unfortunately TI devices are somewhat of an exception – their header files seem to be hand-edited and they don’t ship machine-readable definitions under a license that allows reusing. Also as their market share is relatively low (below 3% among our users), any feature that will add value to all device families will always get higher priority for us than resolving minor glitches in TI definitions (major bugs like the one you mentioned before are a priority).

If you are a licensed user of Keil or CrossWorks, you might be able to convert their register definitions to a format that VisualGDB supports for your own use (please double-check check their license terms to be sure). If you decide to go this way, we can provide step-by-step instructions on locating/replacing VisualGDB register definition files.

[Author]

Posts