Forum Replies Created
- 
		AuthorPosts
- 
		
			
				
February 8, 2018 at 01:36 in reply to: Setting location of coverage reports through command line #19997support KeymasterHi, Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2048.msi It will reuse the normal coverage report logic when launched from command line. support KeymasterHi, 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 KeymasterHi, It looks like you are using an older VisualGDB build that does not support Android CMake projects. Please update to VisualGDB 5.3R8. support KeymasterHi, 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 KeymasterHi, 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. February 7, 2018 at 18:31 in reply to: Template does not support all configurations (beside Releas and Debug) #19981support KeymasterHi, 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 KeymasterHi, 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 KeymasterHi, 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 KeymasterHi, 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 KeymasterHi, 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 KeymasterHi, 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/ February 4, 2018 at 19:28 in reply to: Missing Pre/Post build steps settings – exception raised when VS2017 start #19942support KeymasterHi, 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 KeymasterHi, 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 KeymasterHi, 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 KeymasterHi, No problem, we have updated our BSP to the latest SDK. You can install the new package via Tools->VisualGDB->Manage VisualGDB Packages. 
- 
		AuthorPosts