[support]

Hi,

Thanks for checking this. It is starting to look like the ESP8266 initialization data might have gotten corrupt. Please try setting the Debug Settings -> Additional FLASH resources to program -> Initialization Data file to <SysGCC>\esp8266\esp8266-bsp\RTOS-SDK\bin\esp_init_data_default.bin. This should force VisualGDB to program the initialization data as well.

If this doesn’t help, please try connecting to the COM port using a different baud rate and then resetting the board. The garbage after the “chksum 0xab” text might be a meaningful error message printed using a different baud rate, so connecting under that baud rate should show garbage instead of “checksum” messages followed by a meaningful error text.

[support]

Hi,

It looks like you are using an older VisualGDB build that does not support Android CMake projects. Please update to VisualGDB 5.3R8.

[support]

Hi,

It looks like a mismatch between the gdb stub baud rate in your project settings and the actual baud rate used by the device. Please try several typical baud rates (e.g. 115200, 74880, etc); if none of them works, please  change your firmware to output the character ‘U’ (0x55 or 01010101, so it will look like a uniform clock signal) in a loop and use a logic analyzer to understand the actual baud rate (simply measure the period of the output signal). You can also try explicitly setting the UART period on your board before initializing the GDB stub.

[support]

Hi,

If you are using a VisualGDB-generated Makefile or an MSBuild-based project, simply add the sources of your library to Solution Explorer and adjust the missing include paths (VisualGDB will normally help you discover them and suggest adding them automatically).

Another option would be to import the entire project using our experimental mbed importer, although it may require changes to the open-source importer plugin, as the mbed internal structure keeps on changing between versions.

[support]

Hi,

Thanks, this is a known limitation. Project templates are currently limited to the standard configurations only. They take settings from the current configuration, remove debug- or release-specific flags like -O0 and then use those settings to create Debug and Release configurations in the new project (adding debug and release-specific settings back). We will update this thread once we support templates with custom configurations.

[support]

Hi,

No problem, we can help you resolve this. However unfortunately we could not find any licenses associated with your account. Could you please let us know the email address associated with your license so we could link it to your account?

[support]

Hi,

Sorry, VisualGDB would not automatically detect your IAR toolchain yet. Similar to the Keil tutorial, we recommend simply creating a project using the GCC toolchain first and then editing the Makefile to run the IAR compiler instead.

No problem, we have published a tutorial about importing IAR projects here: https://visualgdb.com/tutorials/arm/import/iar/

 

[support]

Hi,

Sorry, not yet. We have added support for automatic import of IAR projects (converting them to GCC projects), but we don’t have a tutorial for the IAR compiler yet.

[support]

Hi,

This might indeed interfere with debugging, but a 100% correct answer would depend on on the internal implementation details of the STM32 debug unit. We would advise double-checking this with ST (e.g. on the ST forums) as they should have a better insight into the STM32 internals than we do.

[support]

Hi,

The latest versions of the Android tools are highly coupled with the Android Studio, so the recommended workflow is to install Android Studio, create a project and then import it into VisualGDB. This will enable the new Advanced CMake Project Subsystem, while letting you use Android Studio to debug Java code, so you will get the best from both worlds.

Please follow this tutorial for detailed instructions: https://visualgdb.com/tutorials/android/cmake/

[support]

Hi,

OK, sorry, we don’t have a detailed tutorial on that part yet, however we have a similar one showing how to extend the MSBuild targets to run Qt tools: https://visualgdb.com/tutorials/linux/qt/msbuild/

To run a custom step before the build you would need to declare a target similar to the InvokeQtTools one shown in the tutorial (you can use the Exec target).

If you are not comfortable editing the MSBuild rules manually, we would advise keeping the Makefile-based solution until we update our bootloader tutorial showing the exact steps for MSBuild.

[support]

Hi,

No problem, once we release the updates BSPs, they will work with VisualGDB out-of-the-box. The open-source BSP generators are provided for those willing to try the latest experimental versions at their own risk; if you don’t want to do that, waiting for an official update from us is the best option.

[support]

Hi,

Thanks for reporting this, looks like our bug. We have fixed it and updated the installer. You can download the updated version here (same URL): https://sysprogs.com/analyzer2go/download/

[support]

 

Hi,

No problem, we have updated our BSP to the latest SDK. You can install the new package via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2040.msi

GCCFlags.xml is only used in the graphical editor the Makefile CFLAGS/CXXFLAGS, but not with MSBuild projects. The actual GCC build flags are stored in the C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\PropertyPages\gcc.xml file.

When you build your project, VisualGDB will use the following logic to determine how to call the compiler:

1. The GNUCompilerType variable from your project settings will be used to set GCCBinaryName and GXXBinaryName (see code in gcc.targets)
2. The GCCBinaryName and GXXBinaryName variables will be passed to the GCCCompile task (note that it has 2 invocations) along with the path to the gcc.xml file. The task will either invoke gcc directly (for Windows builds) or write the rules to the Makefile (for Linux builds).

In order to use the Intel compiler instead of gcc, please edit the remotebuild.xml file to support another compiler type (e.g. ICC), enable it via VS Project Properties and then edit the gcc.targets file to set GCCBinaryName and GXXBinaryName accordingly.

If the command-line options are not 100% compatible with GCC, please create a copy of the gcc.xml file, edit the flag definitions and update the references to it in the .targets and .props files, so Visual Studio will load the modified file if the GNUCompilerType is set to ‘Clang’.

[Author]

Posts