Forum Replies Created
-
Posts
-
Hi,
The executable file normally has no extension (e.g. …/LinuxProject1/VisualGDB/Debug/LinuxProject1). If you are not sure, please try running the “find <project directory>” command via SSH and post the output here and we will help you locate the right file.
Hi,
Generally in order for a USART to work, you need to ensure the following:
- The peripheral clock for this USART is enabled
- The corresponding pins are configured to work as USART
- You configure the peripheral correctly (e.g. set the baud rate) and write the correct data registers
We have a detailed tutorial showing how to use STM32 UART here: https://visualgdb.com/tutorials/arm/stm32/uart/hal/
Generally we would advise first sorting this out on a regular non-MBED project and then stepping through the mbed source code to ensure that it does the same initialization/configuration steps as your non-mbed project (hardware register window can help double-check that the necessary parts got initialized).
Hi,
Please use the Help->About VisualGDB window to enter the new key (or re-enter the same key if it was upgraded).
Hi,
Sorry, this exception is thrown by the VS itself; VisualGDB simply displays it and cancels the wizard. As this is something very rare that should normally not happen, we won’t be adding any special handling for this case. That said, if anyone else encounters this problem, please feel free to update this thread. If it turns out to be not as rare as we assume, we can easily add a check for it.
Hi,
Please try updating your VisualGDB to v5.3R3 (latest maintenance release) and also update your OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.
If you still don’t see the options, please try attaching a screenshot of your Debug Settings page so that we could see which version you are using and suggest a way to update it.
Hi,
OK, we have added an option “Don’t activate GDB Session window” under Tools->Options->VisualGDB->General->GUI in this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.13.1881.msi
The Live Variables tool window should normally appear close to the ‘Output’ window. Either way, if you keep the window open, but put it in the background (i.e. behind any other window), it should stay in the background and not re-appear.
Hi,
Thanks for the link. Looks like you are using the ‘VisualGDB’ platform for non-MSBuild projects. Unfortunately this is not supported (as VisualGDB internally uses the platform name to distinguish between MSBuild and non-MSBuild configurations). We have added a warning for this in the upcoming v5.3R4 build.
To fix this, please rename the ‘VisualGDB’ platform in your project files to ‘x86’ or ‘Win32’ (depending on the VS version you are using).
We have also noticed that you are using CMake. VisualGDB 5.3 comes with a very powerful Advanced CMake Project Subsystem that basically creates a 2-way mapping between CMakeLists.txt files and the Solution Explorer (see this tutorial). We would advise switching to this subsystem (VisualGDB supports importing Embedded CMake projects) as it provides much better user experience with CMake.
Hi,
This could happen if your firmware was interfering with the SWD pins or power states, hence preventing the debugger from attaching. Please try setting the “connect under reset” flag in VisualGDB Project Properties -> Debug Settings.
Hi,
Looks like you are trying to create a project in a directory that does not have write permissions. Please try creating it in a different location or run Visual Studio as administrator.
Hi,
The GDB session window gets activated during the launch of the program to show FLASH loading progress and other information. We can add an option to not explicitly activate it if you believe this would be more usable.
Regarding other windows, this could be caused by a corrupt .suo file. Please try closing the solution and deleting the .vs folder.
Hi,
The RobotLib.vgbsettings file looks wrong (it looked like an empty .vcxproj file); we also did not see your actual .vcxproj file. Please try archiving all project files (except for the actual .c/.cpp/.h files) and either attach them here or send them via our support form so that we could have a look.
Hi,
Sorry for the confusion, Include Search Path is the correct option.
We have rechecked the behavior for the manually added directories and managed to reproduce and fix the issue. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.13.1878.msi
Hi,
Unfortunately this is not supported out-of-the-box as different devices often include different SDK files (e.g. STM32F4 SDK vs STM32F7 SDK). You could, however, achieve the same effect manually in one of 2 ways:
- Convert the project to a stand-alone one, then remove MCU-specific macros and include directories from the first page of VisualGDB Project Properties and move them to the per-configuration “MSBuild Settings” page. Then create another configuration and edit the settings there.
- Create 2 VS projects targeting different devices and a shared project with your actual code. Reference the shared project from both binary projects.
- Create 2 versions of stm32.props file for both devices and modify the .vcxproj file to explicitly include one of them based on the configuration name (VisualGDB would overwrite the original file if you try changing MCU configuration though).
Let us know if you need any further details.
Hi,
Thanks, we have confirmed your support status.
The problem happens because your code includes headers that declare u8g_InitComFn() and the other functions, but your project doesn’t include source files (.c or .cpp) that define those functions. Please search the sources of your library for definitions (not declarations) of the missing functions and add them to your project.
We also have a detailed tutorial showing how to troubleshoot this type of problems here: https://visualgdb.com/tutorials/tips/externc/
