VisualGDB issues and feature requests

[swineone]

Hello,

After evaluating VisualGDB for a few weeks, we’ve stumbled into a few issues, and also have a few feature requests to make. Apologies in advance for the long post.

I’m going to mention some of my environment particularities upfront, in case they matter. I’m using Visual Studio 2013 under Windows 7, VisualGDB 4.3, the GNU Tools ARM Embedded toolchain (version 4.9 2014q4), and STM32 MCUs (STM32F0xx, STM32F1xx and STM32F4xx).

1. ISSUE: There are two developers on our company working on any given project, so the project is opened on different computers while being developed. Also, although I’m aware that VisualGDB provides a toolchain, I’d rather use the GNU Tools ARM Embedded toolchain (https://launchpad.net/gcc-arm-embedded). A post in the forum (http://sysprogs.com/w/forums/topic/evaluating-visualgdb-some-issues-thoughts-and-questions/) was extremely helpful in this regard, but there is one issue remaining. When moving from one computer to the other and doing a rebuild of the code, errors creep up, which I’ve traced to the fact that the TOOLCHAIN_ROOT variable in the project’s makefile (the one ending in .mak) is not automatically updated. As an aside, my understanding was that, when building from within Visual Studio, TOOLCHAIN_ROOT was provided as an environment variable (it says as much in the project’s makefile), but this just doesn’t appear to be the case. Anyway, I’ve found an easy workaround for this, which is to edit one parameter within the VisualGDB Project Properties dialog (in my case, I’m editing the linker script parameter, but I believe others are valid as well), and then editing it back to the original value. This forces a rebuild of the makefile which fixes the issue. This is probably why, in the thread mentioned above, one of the steps that’s suggested is to change the CPU type and back — I assume it just has the same effect. Still, this is the one manual step that needs to be done when a project is reopened on a different computer, and we’d really appreciate if it went away so everything was fully automatic. Will you consider implementing an automatic fix for this?

2. ISSUE: Another issue we found when reopening projects on different computers is with include directories. If the directories were added from the folder browse dialog, the full path would be used (C:\…\…\include). The VisualGDB build variables such as  $(ProjectDir) seemed like the right way to solve the problem, so in the example above I’d replace the include directory with $(ProjectDir)/include. Unfortunately, at least when using this for include directories (VisualGDB Project Properties -> Makefile Settings -> Configuration Makefile Settings -> Include Directories), the $(ProjectDir) variable appears to expand to an empty string. I’ve since solved the problem, since I realized the compilation takes place on the project directory itself, and hence I’d just pass “include” (again as in the example above) as the include directory, and the gcc command-line would include a “-Iinclude” switch. While that does solve the problem, it bothers me that the build variable is expanding to an empty string. Am I doing anything wrong?

3. ISSUE: When right-clicking the project in Solution Explorer, then choosing Add -> Import folder recursively, the OK button is greyed out even after selecting the folder to import. The workaround that I’ve found is to click on the radio box “The folder is located on a remote Linux computer”, then clicking back on “The folder is located on this computer”, the OK button becomes available.

4. ISSUE: My previous IDE was CooCox, where I could consistently click Debug to get the flash programmed and stop at a breakpoint at the beginning of main(). With VisualGDB, after clicking on Debug -> Start Debugging, quite a few times I’m met with the “GDB Command Timeout” screen, which says “The following GDB command is taking too long to complete: target remote :4242”. I’m not keeping track of how often this happens, but certainly it’s more often than 1 in 20 debugging sessions, and likely more than 1 in 10. Maybe there’s an option I should be ticking somewhere that I missed? I also recall, when developing the FreeRTOS embedded threads plugin on the STM32F4DISCOVERY board, that the board would freeze after starting debugging, but after pressing the reset button on the board, the debugging session would correctly start. Again this was never necessary with CooCox.

5. ISSUE: If I’m debugging a project and click the icon that restarts debugging, I get the dialog “The project xxx is out of date” every time, even if I didn’t change anything on the source files or project settings. This forces a recompile which slows down my workflow a little. Could you look into it?

6. ISSUE: Is there a special procedure to uninstall the SysGCC ARM toolchain? I was unable to find an entry in the “Uninstall programs” pane of the Windows Control Panel. Since I’m already using the GCC ARM Embedded toolchain, I’d like to save some disk space (SysGCC takes up north of 1.5 GB, presumably due to supporting Cortex-A, Cortex-R, etc.)

7. FEATURE REQUEST: The STM32 HAL is finally available for all members of the STM32 family (including STM32F1). The VisualGDB templates for STM32F0 and STM32F1 still use the old standard peripheral library. Are there plans to migrate the templates to the HAL? Because I’m migrating my own projects to it, if you don’t plan to support it any time soon, I’ll look into making my own templates for these two families.

8. FEATURE REQUEST: When compiling the project, is the build performed in parallel (similar to the -j switch passed to make when compiling in a Unix system)? If not, I ask you to consider implementing this feature.

9. FEATURE REQUEST: I mentioned this in a previous thread that I created in 2014, and back then you mentioned it wasn’t directly supported, so I leave this as a feature request. Some IDEs support a live data feature, where you can see the current value of a variable (and even watch as it changes) without having to stop the debugger — you just hover the mouse over the variable in the source, with the code running, and the value is shown and periodically updated. I’d love to see this implemented in VisualGDB, assuming it’s feasible (maybe Visual Studio does not support something like this, no idea).

10. FEATURE REQUEST: Again, I mentioned this in a previous thread, but I’d really like to see support for serial wire viewer using ST-Link/V2 — in my experience, semihosting is way too slow to be used in practice. Back then you said the problem is that it uses an undocumented protocol, and also something about being unreliable (although I’ll take unreliable over slow to the point of being unusable any day of the week). I’m so interested in this I’m offering to help implement it. So I ask: what can I do to help?

Thanks in advance

• This topic was modified 9 years, 1 month ago by swineone.

[swineone]

We just found another issue, and we’d love if you could take a look at it.

If a project is created normally (before converting to a standalone project), the Hardware Registers view within Debug -> Windows is available. However, after converting to a standalone project, the Hardware Registers view disappears. I’ve traced this to an incorrectly generated XML file. The <MCUDefinitionFile> tag should be nested within the <EmbeddedProfile> tag, but instead it’s nested within the <InPlaceMCU> tag which itself is nested within the <EmbeddedProfile> tag. It should be a simple fix.

[swineone]

Bumping the thread because these issues are really important to us. Even a partial reply to the easier questions would be good enough for now.

[support]

Hi,

Sorry for the delayed reply. Please find the answers to your questions below:

1. If you are using VisualGDB 4.3r4, the TOOLCHAIN_ROOT should be set on-the-fly based on the current project toolchain. Please double-check that it’s defined with the ?= syntax in mcu.mak and that the environment variable is passed correctly (add ‘set’ to build commands in Makefile to get a dump of the environment).
2. Visual Studio project variable system is different from VisualGDB variable system, so the IntelliSense includes cannot reference VisualGDB variables. Simply specify the relative paths to your include directories (e.g. ..\include) and they will be handled correctly.
3. This is a known issue that has been fixed in the upcoming 5.0 release.
4. This is caused by a bug in the texane-STLink tool that VisualGDB uses. Simply unplug your ST-Link and plug it back to get it fixed or switch to OpenOCD that does not have this problem.
5. This is a limitation of VS. VisualGDB projects are Makefile projects, so Visual Studio has no way of determining whether any of the files have changed. We do have long-term plans of transparently supporting MSBuild, that will eliminate this problem, but currently the only workaround is to answer ‘no’ if you are 100% sure that the project has not been modified. VisualGDB will then debug the previously built binary.
6. There is no special procedure. The installer simply unpacks an archive and registers the toolchain with VisualGDB. Simply delete the toolchain folder and VisualGDB will recognize that it’s gone.
7. We do have plans to support HAL for other device families and also allow selecting between HAL and classic frameworks, however this is planned after the release of the new IntelliSense engine.
8. You can easily achieve that by adding ‘-jXXX’ to VisualGDB Project Properties -> Build Settings -> Additional Arguments.
9. This might be quite tricky to support properly (GDB/VS won’t support it natively, so we would have to add some special GUI for that) and it will only work with GDB stubs that provide a command interface that is separate from GDB. You should be able to achieve a similar result if you use OpenOCD, telnet to port 4444 while it is running, and run commands like “mdw <addr> <count>” to query memory contents directly from it (bypassing VS and GDB). Let us know if that works for you.
10. We did experiment with ST-Link/V2 and SWW (built an open-source trace tool from https://github.com/obe1line/stlink-trace) and found out that at seemingly random points in time the ST-Link device enters some internal state where it simply starts producing garbage instead of the trace output. Furthermore, different firmware versions showed different behavior, so we gave up. If you are willing to experiment with it and could get the tool to work reliably, we could help you port its functionality to OpenOCD so that VisualGDB would support it directly. You can find the source with our modifications to get it working on STM32F4Discovery here: http://visualgdb.com/tmp/trace.zip (Disclaimer: we are not related to the author of the tool and find parts of its code as puzzling as you will).

11. (Regarding the <MCUDefinitionFile>). Thanks for letting us know, we will include a fix in the upcoming 5.0 release.

[devrope]

@swineone: how did you convert the F1 to HAL? I need to do the same thing, but can’t get it right.

I downloaded the latest HAL via STM CubeMX, copied it to where the old one is, and trying to change the code. Do you have more details than that?

Thanks in advance.

[kowalski5233]

Good day people

Resurrect after so nearly a year.  Sorry about that, but point #1 deals exactly with an issue we’re experiencing, albeit with v5.1, and don’t want to repost if it is already in discussion.

So, same, as described, a co-developer created the project, but when I try to do anything make.exe related, it complains that
“‘$’ is not recognized as an internal or external command, operable program or batch file.”

The Toolchain is set as “ARM in C:\SysGCC\arm-eabi”, nfr5x.mak contains “TOOLCHAIN_ROOT ?= C:/SysGCC/arm-eabi”, so all seems in order.  We’ve even tried the workaround suggested by swineone, but no luck.  We’ve tried added ‘set’ to the makefile, under all: and clean: and nothing there either.
What does work is if I explicitly direct the make.exe location to C:\SysGCC\arm-eabi\bin\make.exe instead of $(TOOLCHAIN_ROOT)\bin\make.exe, but for obvious reasons we’d prefer it if it was not a static address, as install locations can vary.

Any feedback regarding this on the latest version, or is there something silly we’re missing?

Regards

[support]

Hi,

Can you reproduce it with the latest v5.1r3? Does it show TOOLCHAIN_ROOT under VisualGDB Project Properties -> Show VisualGDB Build Variables?

If yes, please update the build command on the Makefile Settings page to use $(TOOLCHAIN_ROOT) as well.

[kowalski5233]

Hi support

Thanks so much for the quick feedback, even after the post resurrection.  That seemed to have done the trick!  I downloaded the ‘trial’ from the download site and took a chance and installed it, but it retained the license, and all seems well.  It now says v5.1 build 660.

I just thought I should mention that we’ve ran into another snag.  We want to stick to a specific version of the BSP and not run the risk of conflicting versions, so the BSP is also added to the repository.  The problem is that the compiler (intellisense seemed to have had that down) kept looking for the BSP in the C:\Users\myuser\AppData\Local\VisualGDB\EmbeddedBSPs.  With a lot of toying and trying to figure out what is defined where, etc, etc, I finally changed the BSP_ROOT definition in nrf5x.mak from a ?= to a =, which solved the problem.  It just feels like there’s no obvious place in the environment where it can be overridden/set, unless you go and scratch in the .mak files, which has the following line in it “#DO NOT EDIT MANUALLY. THE FILE WILL BE OVERWRITTEN.”.

Have a good weekend!

[support]

Hi,

Normally the BSP_ROOT should be automatically set once you relocate the toolchain via VisualGDB Project Properties. It’s only supported in the Custom and Ultimate editions though, so if you are using a one below them, you would need to adjust the IntelliSense settings manually if you want to use non-standard BSP locations.

[kowalski5233]

Ah, ok, yes, we have the Embedded version, so manual override then 🙂

Thanks for the feedback

[support]

Hi,

Yes, the manual override should do. You can also upgrade to Custom at any time. Simply contact our sales to get a quote.

[Author]

Posts