Evaluating VisualGDB: Some questions

[cvrtky]

Hello Sysprogs.

I’m currently evaluating VisualGDB for use in my development team. We are currently using CrossWorks for ARM by Rowley. We are pt. working on a couple of project based on mbed by ARM, so flexibility working with that framework and ease of configuring a project will be essential for deciding on investing in licenses for the Custom Edition. The first 3 issues are very important to us. They will be important to our decision. The rest are also important but not show stoppers the same way as the first.

1)
It’s important for us to be able to switch between different versions of mbed without too much work. An easy way to set up the project is one of my main reasons for looking at VisualGDB.

The mbed-dev source tree is in flux and often updated. Files are rewritten and moved around between directories. Reconfiguring CrossWorks projects is becoming a burden.

We are mbed contributors, hence we like to stay current with the mbed-dev source, while we on the other hand still have an important product base on an old version using the STM32F1 SPL.

I checked the option for installing multiple BSP versions when installing you mbed source. I don’t understand how it’s possible to switch between them and how the bsp.xml, mbed.xml and mbed.props files are generated. Please advise.

Generating a Makefile using mbed-cli and importing that into VisualGDB is not what I’m looking for.

2)
We are using custom tool chains whit libraries and specs tuned for our use. The tool chains are based on gcc 4.8 and on gcc 5.4. They produce smaller code, plus we are comfortable using them. VisualGDB does NOT read the specs files from our tool chains. It’s using some global – / system specs. This is quite obvious since my nano version of libc is named libc_n.am but VisualGDB is asking for libc_nano.a. This won’t do. How do I ensure that VisualGDB will use our specs?

3)
When creating an embedded project driven by make building fails as shown below. Creating the same project using MSBuild or converting the Makefile based project to MSBuild, the project builds without errors. Please advise. We want to use make since it’s the only way, we have a chance of moving a project to another tool without reconstructing it.

Log file from a failed make run:

VisualGDB: Run “C:\Program Files (x86)\Sysprogs\VisualGDB\make.exe  CONFIG=Debug -j4” in directory “C:\VisualGDB\EmbeddedProject2\EmbeddedProject2” on local computer

C:’ is not recognized as an internal or external command, operable program or batch file.
C:’ is not recognized as an internal or external command, operable program or batch file.

C:/SysGCC/EmBitz/1.11/bin/arm-none-eabi-g++.exe -ggdb -ffunction-sections -fno-exceptions -fno-rtti -O0   -mcpu=cortex-m3 -mthumb -IC:/Users/tim/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.mbed/5.6.3r2

(cut … lots of include and define directives to follow)
(end of cut)
-c LEDBlink.cpp -o Debug/LEDBlink.o -MD -MF Debug/LEDBlink.dep

‘C:’ is not recognized as an internal or external command,

(cut)
(end of cut)

make: *** [Debug/LEDBlink.o] Error 255
make: *** Waiting for unfinished jobs…

(cut … repeated output from parallel jobs)
(end of cut)

VisualGDB : error : Build has failed. See the Output window for more details.

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command “”C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe” /build “C:\VisualGDB\EmbeddedProject2\EmbeddedProject2\EmbeddedProject2.vcxproj” “/solution:C:\VisualGDB\EmbeddedProject2\EmbeddedProject2.sln”  “/config:Debug” “/platform:Win32″” exited with code 1.

4)
I can convert a project driven by make to using MSBuild. How does one convert a project the opposite way without having to rebuild the project from scratch? This would be a VERY nifty feature when dealing with third party projects.

5)
When building a project based on an imported makefile no statistics on memory usage is printed. Please advise.

6)
VisualGDB as default places solutions in the user’s profile. How do I change that? I can key in another directory name and VisualGDB will use that until I cancel the creation of a project. Then it reverts to the default. This is a bit anoying.

7)
Adding debug methods / adapters. I haven’t looked much into this, I just want to know what my options are. I know I can add the cfg files to the OpenOCD directory. Will this make my CMSIS-DAP debug probe show up in the menus in the GUI? I want to use my Atmel-ICE for AVR8 and SAM debugging and my LPC-Link2 for debugging a NXP4357 firmware.

Looking forward to your answer
Sincerely
Tim

[cvrtky]

Hello again,
seems like I found the answer to question 6.
Navigating from the menu bar to Tools -> Options -> Project and Solutions -> Locations.
Then I’m allowed to change the Project location. Nice 🙂

Cheers
Tim

[support]

Hi,

No problem, we will provide detailed answers to your questions below:

1. You can configure VisualGDB to install multiple versions of mbed as follows:
   1. Open Tools->VisualGDB->Manage VisualGDB Packages
   2. Locate “ARM mbed”
   3. Enable the “Allow installing multiple versions of this BSP”
   4. Click “Online” in the left part of the window
   5. Enable the “Show old versions” checkbox at the bottom of the window
   6. Filter for “arm mbed”
   7. Install the previous versions you need

   When you create an mbed-based project next time, VisualGDB will allow selecting a specific version to use; when a new version is available, VisualGDB will install it side-by-side with the current one and will let you switch it via VisualGDB Project Properties.

2. VisualGDB expects gcc to be configured to load the correct specs automatically, however you can easily change this by editing the toolchain.xml file in the toolchain directory (VisualGDB creates it when importing a toolchain). Although the file format is not officially documented, looking through the toolchain.xml file in our ARM toolchain should easily explain where VisualGDB takes references to options like nano.specs and let you adjust it. Also if you have any questions about the toolchain.xml file structure, let us know and we will be happy to provide more details.
3. This looks like some path transformation issue between GNU Make and the toolchain. One quick fix could be to use the make.exe shipped with your toolchain instead of the one shipped with VisualGDB. If this doesn’t help, please try the steps below:
   1. Run the “C:/SysGCC/EmBitz/1.11/bin/arm-none-eabi-g++.exe …” command line directly from the project directory. Does this result in the same error?
   2. If not, please try adding “-d -d -d” to the Make arguments (or just running “make -d -d -d CONFIG=Debug” in the VisualGDB project folder) to dump diagnostic output from Make. This should show which command it is trying to run just before the error happens. Ensure that running the command manually reproduces the problem.
   3. Try removing various parts of the command line to see which one is responsible for the error (e.g. try removing all the “-IC:/…” arguments).
   4. If your toolchain doesn’t accept the “-IC:/” syntax, try using the “-I/c/path” and “-I/cygdrive/c/path” syntax. If you find a syntax that works, let us know and we will help you configure VisualGDB to use it.
4. We normally recommend using MSBuild for all new projects. MSBuild provides much better level of integration into Visual Studio than Make and can also be used on your build server as shown in this tutorial. Hence it is not possible to directly convert MSBuild projects to GNU Make. You can add a “Win32” platform manually and copy the .vgdbsettings, Makefile, .mak and mbed.xml files manually from a different project, but you would need to copy various build settings manually.
5. The memory usage is only shown if VisualGDB is using the Embedded Make or MSBuild subsystems. They are recommended for embedded projects, as many features like Embedded Frameworks, profiler, etc rely on VisualGDB’s ability to recognize and automatically change project settings (e.g. reference new libraries). If you would like to use the “imported 3rd-party Makefile” mode instead, we can easily enable memory usage reporting for it, but other features relying on automatic settings updating still won’t work.
6. Looks like you have already found the option for this.
7. It is possible to add 3rd-party debug methods to VisualGDB using 2 mechanisms:
   1. If you want to continue using OpenOCD, you can add a new .cfg file and then update the edp.xml and QuickSetup/interfaces.xml files to make VisualGDB recognize your device and select the script automatically.
   2. If you want to use a 3rd-party gdb stub, you can define the command-line arguments for it via a custom edp.xml file as shown in this tutorial. You can also create full-featured debug plugins with custom settings GUI and custom FLASH programming steps (e.g. see this one), although those interfaces are not officially supported. I.e. we can point you to the right direction if you get stuck, but we cannot provide detailed step-by-step instructions for every possible customization and we may change some of the interfaces in the future versions.

Let us know if you need any further information and we will be happy to help.

[cvrtky]

Hello again Sysprogs.
1)
I believe we misunderstood each other on this issue. From my point of view, you refer to mbed-os as you BSP, that is the mbed-dev core library plus all the extras including RTOS, events and feature subsystems, while I was talking solely about mbed-dev. This subsystem consist of the files mbed.h, mbed.conf and the 4 directories drivers, hal, platform and targets. The mbed-dev libray is distributed separately through a Mercurial repro, which is updated each time the Library version number is updated
You mbed BSP 5.6.3r2 contain mbed-os version 5.6.3 and mbed-dev library version 154. The current version of mbed-dev is 157. Following your instructions, I was given the option to install the old mbed BSP version 5.4.2R2, which gave me mbed-os versopn 5.4.1 and mbed-dev library version 123.
This is not what I’m asking. As mbed contributor I’m working with bug fixes and updates to the mbed-dev library. What I’m looking for is either to construct my own BSP containing basically any version of the mbed-dev sub module plus the ability to either switch the version of the subtree forth and back at my discretion, or the ability to do the above by updating mbed BSP 5.6.3r2
The mbed-dev submodule changes often / is in constant flux. Files may be added to, removed from or moved around in the source tree. Because of these frequent changes, I need a way to generate the BSP.xml file since it has a description of the location of the files in the tree and the compile options per supported boards. I presume you generate this file somehow “automagic”. Please advice whether this is possible and if you are willing to share this program.
Albeit we have a project buid with mbed-dev version 95. Until we migrated this to using HAL instead of SPL we’ll handle this using CrossWorks. We mainly are interested in version 140 and later. This probably makes it easier to accommodate our requirement.

2)
This is a bug. The nano.specs in C:/SysGCC/EmBitz/1.11/arm-none-eabi/lib is NOT being read. The only way I can make this work as expected is to edit mbed.mak in my project directory changing the name of the specs files. If I change the name of nano.specs to sat nanonano.specs then everything works as expected. I tried without any success to specify nanonano.specs in the tag in toolchain.xml under the default tag. This problem arises with every external tool chain I’m attempting to use even if I don’t install your arm-eabi toolchain.

3)
This is a bug, but there is a very simple work around.
The problem turned out not to be related with the version of make being used and neither the -IC:/… syntax. The culprit is the “-DCLOCK_SOURCE=USE_PLL_HSE_EXTC|USE_PLL_HSI” command line option. The “|” is being interpreted in the shell as a pipe command. This problem occurs independent of which make and tool chain being used. The solution straight forward: One have to specify the option as follows:
“-DCLOCK_SOURCE=’USE_PLL_HSE_EXTC|USE_PLL_HSI’” That is in the GUI enter an apostrophe before and after “USE_HSE_EXTC|USE_PLL_HSI” in the GUI. I haven’t tried VisualGDB on Linux nor OSX. I’m using Windows 10.

4)
OK. This is NOT a major problem, we can live with this limitation ?

5)
Hmm. I’m not sure I can follow you on this. I am using the GNU make utility packaged with VGDB. Isn’t this what you refer to as “The Embedded Make?” Could I get this information using a custom post make command?

6)
Jup. Problem solved.

7)
I haven’t had time to look further into this. I could probably use atbackend from Atmell Studio. We can discus this later. Issue 1 .. 3 are the important ones.

[support]

Hi,

No problem, please find the answers to your questions below:

1) You can build a custom BSP with your own mbed version by using our open-source BSP generator. However as the mbed internals are rapidly changing, it may not work out-of-the-box with every version you would like to try, so you may need to adjust it accordingly (we periodically refresh it to support the latest mbed releases, but trying it with any other version is at your own risk).

2) This could be caused by a typo in toolchain.xml. Please post the contents of your toolchain.xml and the generated mbed.xml and mbed.mak and we walk you through resolving this.

3) Looks like this indeed broken for GNU Make. Please try this build: VisualGDB-5.3.17.1950.msi

5) VisualGDB can import your projects in 2 modes: generate a managed Makefile for it (that will have VisualGDB-specific structure, so VisualGDB can edit parts of it automatically in response to changing options via GUI) and import it as a generic command-line project (VisualGDB will run the build command line specified by you, but won’t make any assumptions about the project internals). We recommend the first import mode for long-term solutions and the second import mode for experimenting and hacking, hence the memory usage output is only supported in the first one. Let us know if you need more examples.

[cvrtky]

Hello again Sysprogs
you put me to work wit your last reply 😉

1)
Thank you for providing link to your mbed BSPgenerator. Having installed the required Python modules in a virtual environment and correcting the path to your toolChain from e:\SysGCC\arm-eabi to C:\…, I manged to create BSP for mbed-os version 5.6.3 & 5.6.4 / mbed-dev library veriosn 154 & 155.
I get a lot of errors about missing register definitions and missing linker scripts. You are probably aware of this.
See log file attached.
I wanted to try adding a register file for the target: STM32L072CZ_LRWAN1. My partner in the USA are using this board. Secondly adding support for the STM32L072CZ should be fairly easy since one just have to remove the LCD Registers sets from the STM32L073CZ 😉
Looking at the the stm32l072xx.xml it resembles a ordinary .SVD file from ARM / ST.com. Please confirm this. Or is is specially tailored for your register view? I tried to remove the LCD register set and save a copy as stm32l072xx.xml.gz, but I still get complaints about missing register definitions for STM32L072CZ_LRWAN1. Should the file be named differently? Please advice. I would be nice to get rid of these errors. Where should I look for away to patch for the linker scripts? Please advice.

The RunTests function in Program.cs fail miserable because it rely on reading the location of you toolchain from the registry. One could of cause override that, but the test takes a long time, so I didn’t care.

For mbed-os-5.6.5 and 5.6.6 ( mbed-dev library version 156 & 157) I had to extend the search for RAM segment in the scatter files, because the Analog Device Mucs ADuMC3029 & ADuMC4050 were added in mbed-os-5.6.5.
in the function DetectAndApplyMemorySizes in MbedBSPGenerator.cs I added the match for the DSRAM_B segment as follows.

var ram = memories.First(m => m.Name.ToUpper() == “RAM” || m.Name == “m_data” || m.Name == “RAM_INTERN” || m.Name == “SRAM1” || m.Name == “RAM0” || m.Name.StartsWith(“Ram0_”) || m.Name == “DSRAM_B” );

2)
Please see the attached files. I copied the sections for handling nano lib and semihosting from your tool chain.

3)
This patch solved the problem. Thank you.

5)
Please elaborate on how to use this manged Makefile. I’ve had no luck attempting to do that.
I followed the tutorial on the generic import. that works fine, but as you wrote won’t provide me with memory usage stats. the size command from Atmel Studios shell utils can provide some information. the size reported this way for text – + data segment = total size of .bin file

Sincerely
Tim Børresen

[cvrtky]

Hmm upload blocked. Trying again using a 7zip archive.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Please find the answers to your questions below:

1) The mbed codebase is very volatile, so workarounds that worked with the latest version supported by us may not work with the latest one. We only recommend using the generator if you are OK resolving this type of issues (or getting paid out-of-schedule BSPs from us if you prefer).

The hardware register definitions use a different format than ARM SVD (providing higher-level detail). VisualGDB can automatically convert SVD to its internal XML format as well, however the STM32 definitions are based on parsing the STM32 header files as the provide more details. If your MCU definition file is not recognized, please ensure that the <MCU> element in BSP.XML refers to it via the <MCUDefinitionFile> element.

2) The specs-related settings look the same as for our regular toolchain, so it’s hard to say why they would behave differently. Please try checking the exact gcc command line VisualGDB uses (for Makefile projects it’s displayed by default, for MSBuild projects is shown after you increase the build log verbosity). Does the command line make sense? Does manually adding the -L<specs directory> to the command line help? Is the command line different from the one used by your previous build method (e.g. is it missing some extra arguments)? If you are not sure, please post the gcc command line from VisualGDB build, the gcc command line from your current build system and the error messages shown by VisualGDB.

5) Please try following this tutorial. It provides an example of importing a project with generating a VisualGDB Makefile.

[cvrtky]

Hello again
I’ve been busy again testing your feed back … I also have to do my normal job 😉

1)
I’m fully aware of the volatility of the the mbed library and that “My mileage will vary”. Yes I’m willing to “hax” around in your BSPgenerator. I already have had a taste of what I’m signing up for while building and installing a BSP for mbed-os-5.6.6 (current head of the repro).
You have done a fine job writing that program. The import facility also works fine 🙂 This will server as a good starting point. I hope you’ll keep the GitHub repro updated as you progress. I’m willing to share my work in return. That is I hope we can work together on this. It is quite a job to stay current with that library and roll BSP’s for older versions as required.

OK your .xml files are more detailed compared to usual .SVD files. Could you please tell me how to convert .SVD’s to your .XML format using VisualGDB ?

2)
I dropped using the tools chains from the EmBitz IDE by Gerard Zagema and fetched the equivalent installation packages from Launchpad. It’s working as expected now. The correct specs are being read and the correct libraries are being linked. I renamed the libraries temporarily to make sure that this was the case.

5)
Got this sorted to. I get the stats printed out even when building using make. It’s quite trivial: Don’t use a source tree w. code for several MuCs, that will confuse the import. Insert preprocessor symbols by hand. The same goes for include directories. Remove the generated startup code and include the startup code from the project. Switch the scatter file to the one comming w. the project. Done …. Almost, since I found another bug in VGDB
If I insert preprocessor symbol containing pipe – / logical or symbol like the (im)famous example from previous posts: CLOCK_SOURCE=’USE_PLL_HSE_EXTC|USE_PLL_HSI’ into the input in the GUI, the last apostrophe ie. the one after USE_PLL_HSI is removed when saving . Pt. I have to put it into stm32.mak I’ve added the project so you may inspect it. It’s just a trivial mbed blinky.

I’m starting to get a good feeling with yo product. 🙂
Sincerely
Tim Børresen

[cvrtky]

My attachment was apparently to big. Here we try again.

[cvrtky]

Bummer. Failed again.
I’ve uploaded the project to google drive. It is located in the following folder:
https://drive.google.com/drive/folders/0B3ZpZQ81OjS5NDRsUmlTT1JiQ1U/
File name is EmbeddedProject4.7z

Cheers
Tim

[support]

Hi,

Yes, we try to update most of the popular BSPs quarterly and mbed is definitely a popular one. If you would like to share some enhancements you made to it for your own use, we will gladly accept them. Simply send us a pull request via Github.

Normally if you start debugging a project that doesn’t include any register definitions, the hardware register window will display instructions on importing the SVD file. You can also use the following code from our Github repo to convert an SVD file to the VisualGDB format directly: https://github.com/sysprogs/BSPTools/blob/master/libraries/BSPGenerationTools/SVDParser.cs

With the CLOCK_SOURCE macro, please don’t use any special escaping in VisualGDB GUI, e.g.:

VisualGDB will automatically insert the apostrophes when updating the .mak file:

PREPROCESSOR_MACROS := <...> 'CLOCK_SOURCE=USE_PLL_HSE_EXTC|USE_PLL_HSI'

Attachments:

You must be logged in to view attached files.

[cvrtky]

Hello again.
Thank you for your support. I went along and purchased a license for the Custom Edition.
As I understand it, I’m entitled to do 2 installations when purchasing a personal non commercial license.
Do I need a second license key for this additional install or is my key good for 2 installations?

Sincerely
Tim Boerresen

[support]

Hi,

VisualGDB is licensed per seat (computer/user combination). As a special exception we allow installing personal VisualGDB licenses on one extra seat, however this is normally reserved for cases like reinstalling OS, switching computers, etc. You may use this extra seat to install VisualGDB on a second computer, however this would result in some downtime if you would need to reinstall your OS or replace your hard disk.

[Author]

Posts