Forum Replies Created
-
Posts
-
Could you share the full GDB log as described here?
Hi,
You can convert your project to a stand-alone project to copy all shared files to the project directory. Alternatively you can remove the startup file from the device-specific files and add a local copy instead. VisualGDB project system is quite resilient and will not be broken by changes like that. The original startup file will be re-inserted into the project only if you change the MCU type (or MCU properties) via VisualGDB Project Properties forcing it to regenerate the settings files.
The gcc_Debug.h file contains macros that are defined by GCC itself (e.g. GCC version) and the macros specified via command line. The STM32F10X_MD_FL macro defines the current MCU family and comes from the stm32.mak file the stm32.mak file is generated from data in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\BSP.XML and contains the basic settings expected by the STM32 code. When you change the current MCU type, VisualGDB will recompute the flags necessary to build the code for it and will regenerate stm32.mak. If you want to add your own preprocessor macros (e.g. controlling the clock settings), use the VisualGDB Project Properties dialog (Makefile Settings page) that will save them to the debug.mak file instead.
The source control integration should work transparently as long as your check in the .vgdbsettings files from your project directory. You can reference your external libraries using relative paths on the Makefile Settings page and check in them as well.
Setting up a different compiler like IAR would be a bit more complicated. VisualGDB uses the GNU Make tool to build the projects. The GNU Make reads the rules from Makefile and files included from it and uses them to determine which files are outdated and what commands are used to rebuild them. In order to use IAR you will need to replace the Make rules that invoke GCC with Make rules that invoke IAR. This will involve changing the GCC-specific command-line arguments to IAR-specific command-line arguments and updating regular expressions that VisualGDB uses to parse error messages.
The interrupt handlers are supported via the GCC “weak reference” mechanism. The shared startup_stm32xxx.c file contains definitions like this:
void NMI_Handler() __attribute__ ((weak, alias ("Default_Handler")));Then it builds the interrupt vector table that is placed to the specified location in FLASH:
void * g_pfnVectors[0x6b] __attribute__ ((section (".isr_vector"))) = { &_estack, &Reset_Handler, &NMI_Handler,If your project defines another implementation of NMI_Handler, the linker will replace the default “weak alias” with it and the interrupt vector table will point to it instead. Hence there is no need to modify the shared startup_stm32fxxx.c file – simply ensure that each project provides its own replacement of all necessary handlers.
If you want to have several different projects using different modifications of the startup file, simply modify it this way:
#ifdef USING_BOARD_1 //Code specific to board 1 #elif defined(USING_BOARD_2) //Code specific to board 2 #else #error Board not defined #endif
Then define USING_BOARD_1 or USING_BOARD_2 on the Makefile Settings page of your project settings. As different projects will have different macros defined, the same shared startup file will work differently for each of the projects.
Hi,
We’ve made the modification you suggested and it will be included in the next preview build of VisualGDB with our new IntelliSense engine. Would you like to get a test build to try it out before we release that?
Regarding the threads window, there is no public API to add further columns, or even get the currently selected threads. However, as it is WPF-based, you can use .Net reflection to hack things dynamically (e.g. add columns on-the-fly) without breaking VS functionality. This will however most likely break in subsequent VS versions and would require modifications to accommodate the changes in the internal structure of the threads window.
Hi,
The warning is shown when VisualGDB tries to set a breakpoint using the full path (e.g. “c:/dir/file.cpp”, but GDB refuses that). What toolchain are you using? Could you share the full GDB log as described here?
Could you please post the contents of the “output” pane after trying to build your project? It should contain more information about the specific errors.
You can use the following URLs to manually download the BSP/EDP lists:
http://visualgdb.com/hwsupport/BSP/
http://visualgdb.com/hwsupport/EDP/?version=4.3
Then download the file pointed by the PackageURL element and install it by running VisualGDB.exe <package file name>
Hi,
This message could only appear if you have already entered an activation key. If you have not entered one, your registry may be corrupt. Please try installing VisualGDB on a different computer.
For a normal (non-standalone project) you can override the linker script by editing the <mcu>.mak file manually (-T argument in LDFLAGS). Note that it will be overridden next time your change your CPU type. To avoid that convert the project to a stand-alone one.
Hi,
Please forward your activation key to our support email so that we could see why it is not working.
Hi,
The error happens because the file has been moved in one of the recent versions of the kernel. As a workaround, simply copy it to the location where VisualKernel expects it.
We will release a fix resolving this once we are done with the new IntelliSense engine capable of handling all GNU-specific extensions.
Hi,
The toolchain does work by default. In this case it looks like there is a mismatch between different library versions on your Raspberry Pi and resynchronizing the toolchain’s sysroot with your device downloaded those incompatible libraries to the toolchain. Please re-check if it can be reproduced with the default toolchain. If yes, please provide a simple repro project so that we could fix it. If no, please revert to the default Raspberry Pi image to ensure that your libraries are in sync.
Hi,
This looks like a known problem. Please follow the solution described here: http://qt-project.org/forums/viewthread/49098
You can download the debug package manually and install it via command line. Which debug method do you need?
OK, if you get strange build errors, do not hesitate to post them here so that we could suggest a solution.
Sure, have a look at this tutorial: http://visualgdb.com/tutorials/raspberry/qt-cross/
