[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.

[support]

Hi,

Thanks for clarifying this. Mbed projects use slightly different ways to specify stack/heap based on the version and the target. Please try locating the linker script for your target (e.g. via VisualGDB Project Properties) and check it for heap-related definitions. It might look similar to this:

    .heap (COPY):
    {
        __end__ = .;
        end = __end__;
        *(.heap*)
        __HeapLimit = .;
    } > SRAM1

In that case please locate the source file that defines symbols in the .heap or .stack sections (if you are not sure, you can find it out via the .map file) and see what affects the size of those symbols (e.g. preprocessor defines). Settings those preprocessor defines should change the amount of memory reserved for stack/heap.

If no source files define any symbols inside .stack/.heap, you can add one manually as shown below:

char __attribute__((section(".stack"))) ReservedForStack[FIXED_STACK_SIZE];
char __attribute__((section(".heap"))) FixedSizeHeap[FIXED_HEAP_SIZE];

This will reserve space for both stack and heap according to the sizes you specify.

[support]

Hi,

Sorry about that. This is a known issue that has been partially fixed in the STM32 BSP 4.5R3. Please update your BSP to that version (and also use the GNU ARM Toolchain) – it should get the correct VFP version to work.

We will address this issue in the next release of our toolchain as well.

[support]

Hi,

The first issue looks like a missing library or a source file. Please try locating a library that defines the “wifi_wps_start” function and add it to your project as described here: http://visualgdb.com/support/linkerinputs/

The second issue looks like you are trying to compile a snippet of a Plain C code in the C++ context. As this is a generic programming question not related to VisualGDB, please consider getting advice at StackOverflow instead. It has an extensive base of answers to common C/C++ issues.

[support]

Hi,

The fatfs module might not be providing hooks to replace the built-in system calls fopen() using the GCC compiler. Please review the sources of the FatFS library and check if it provides its own versions of fopen() and other similar functions that you could call directly.

[support]

Hi,

This looks like one of your CMake configuration files is corrupt. We would advise creating the project from scratch and then adding all source files to it.

[support]

Hi,

OK, we have managed to add the Android support for Advanced CMake Project Subsystem in the upcoming v5.3R8. You can download a preview build with this functionality here: http://sysprogs.com/files/tmp/VisualGDB-5.3.17.1966.msi

A detailed tutorial is available here: https://visualgdb.com/tutorials/android/cmake/

[support]

Hi,

Our ESP8266 toolchain only includes the libraries shipped with the RTOS and non-OS SDKs; if you want to use external libraries, you indeed need to download them (we recommend saving them outside the toolchain directory to avoid losing them during a toolchain update).

[support]

Hi,

VisualGDB would put the sources into AutoDownloadedSources if it doesn’t know how the Windows path corresponding to them. Could you please give an example of a file (i.e. full path) that gets opened via this mechanism and let us know your shared folder settings (a screenshot or a summary of used paths)?

Regarding “Go to Definition”. Please try locating the source file that should normally contain the definition of the symbol and check that:

• It is included in one of the open projects in Solution Explorer
• Physically present on the disk and accessible via VS
• Does not show any critical errors when opened from VS

Please also try enabling the Clang IntelliSense engine – it uses a different mechanism for locating definitions and should work better with remote projects.

[support]

Hi,

Thanks for the attached file. It does look like STM32CubeMX references a file that is not copied (and not actually needed, as removing it from the .vcxproj file fixed the problem). It also doesn’t mention the USE_FULL_LL_DRIVER macro anywhere in the gpdsc file. This could be a bug worth reporting to ST and if it’s not fixed in one of the next STM32CubeMX updates, we will consider adding logic for detecting this and automatically adding the macro and skipping the missing file.

[support]

Hi,

Please try clicking on “Debug using” and then select “USB Devices”. It should recognize your USB-to-COM bridge and let you select it there.

[support]

Hi,

STM32 devices should normally include the “Fixed stack/heap” framework. Are  you using a custom project or an mbed-based project?

[support]

Hi,

No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.17.1957.msi

It will show detailed information on toolchain selection logic via View->Other Windows->VisualGDB Diagnostics Console. Please share the output from that window and we should be able to fix this.

[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.

[support]

Hi,

The “Fixed stack and heap” is only available on BSPs with linker scripts are generated by VisualGDB. If you are using a different BSP, you would need to edit the linker script manually (the exact steps depend on the device type) and also specify the stack bounds on the Dynamic Analysis page so that VisualGDB could verify it.

[Author]

Posts