[support]

No problem, we will try to help you. The steps you provided should normally work, hence the issue is likely caused by some combination of settings that were not explicitly mentioned. Hence, following the generic steps on our side will very likely not reproduce the problem.

We can still help you resolve this, however we would need you to do the following additional steps on your side:

1. Locate the project generated by STM32CubeMX that you imported into VisualGDB. Open it using the Keil IDE.
2. Add the same scatter file to it. Make sure it is exactly the same as the scatter file you used with the VisualGDB project.
3. Build the project with the Keil IDE and make sure it works as expected.
4. Try comparing the memory layouts and symbols of the 2 projects using VisualGDB’s Memory Explorer (you can choose the .axf file produced by Keil as a reference).
5. If the comparison doesn’t point to a specific cause, please create a .7z archive of the VisualGDB project (including all relevant sources and the output file) and the equivalent Keil project (including all the relevant sources and the .axf file) and attach it here. If the archive is too large, please try using a file hosting service, such as Google Drive.

If we could build both projects on our side and confirm that they behave differently despite using the same sources, we should be able to update VisualGDB to replicate the output of the Keil IDE.

[support]

Hi,

This is by design. The “Fixed Stack/Heap” framework only works when using the StackAndHeap.c file provided by it and a VisualGDB-generated linker script that is compatible with the file.

The options in the GUI simply define the FIXED_STACK_SIZE and FIXED_HEAP_SIZE macros that are used by StackAndHeap.c.

If you are using your own logic for managing stack/heap, you can either specify the macros it expects manually, or update it to use the macro names used by VisualGDB.

If you would like to avoid using the startup file shipped with VisualGDB, please consider updating to the latest EFM32 BSP (v5.9.1). It adds a checkbox allowing to exclude the startup file to VisualGDB Project Properties.

[support]

Thanks for the screenshot. Looks like you are using the legacy formatter, so the clang-format settings are irrelevant.

We have double-checked the configuration you mentioned. The option you mentioned controls an extra newline between “{” and “}”. In order to control whether “{” gets on a separate line, please use the “New control blocks” option instead.

[support]

Hi,

Most likely, you are using the Linux or Embedded license that does not support custom build steps (see this page for the full list of custom features).

You can find out the used edition via Help->About VisualGDB or upgrade it at this page.

You might be seeing the Custom edition GUI on other machines because the trial there has not expired yet (all VisualGDB features are unconditionally available during the trial period, even if a valid key has been entered).

Finally, you might be able to customize the build without the VisualGDB’s GUI by tweaking the Makefile, although using the Custom Steps GUI should be usually much more convenient.

[support]

Hi,

Version 5.3 is very old, so it indeed may not work as expected with the latest VS updates. Please try updating to VisualGDB 5.5 Preview 3 (you would need to renew you key here first).

[support]

Thanks, this partially explains what is going on. TryReadInstructions() is implemented inside VisualGDB. It uses the objdump tool to disassemble the instructions at the specified address.

Most likely, something in the objdump output is preventing VisualGDB from handling this correctly. Would you be able to share the ELF file with us via our support page so that we can try reproducing the issue (please also mention the exact address that is not loaded correctly and the function that triggers it)? If not, we can provide instructions on getting the necessary information from the dump file, although it might take a few extra iterations.

[support]

Hi,

The location of the project/solution files is normally handled by VS itself (see the checkbox next to the project name/location fields when creating the project).

[support]

Thankfully, VisualGDB has much more to offer than just a shortcut for launching make.exe 🙂

Either way, thanks for the log files. Looks like the new logic for analyzing linker messages was working slower than expected for long build command lines. We have optimized it in the following build: VisualGDB-5.5.3.3470.msi

[support]

No problem. Please try right-clicking on the project node in Solution Explorer and select Add->Reference->Browse, then pick the full path to VisualGDBExtensibility.dll in the VisualGDB’s directory. This should resolve the build errors.

[support]

Hi,

No problem, we have updated the sample project resolving this. Please update your local git checkout.

[support]

Hi,

The ARM toolchain only works with barebone targets. For more information on Linux cross-toolchains please see this page: http://visualgdb.com/hwsupport/linuxboards/

• This reply was modified 5 years, 7 months ago by support.

[support]

Hi,

You can disable VisualGDB updates via a checkbox at the bottom of the Manage VisualGDB Packages window. Also VisualGDB 5.5 Preview 3 allows disabling updates for a specific version of the package.

We understand that there is likely a bug in the new BSP, however we absolutely do not control the contents of the ST’s SDKs and it is absolutely not possible for us to provide free bugfixes to a major SDK maintained by a huge company, sorry. The best we could do is if you confirm that the problem exists with a freshly created VisualGDB project but does not exist when creating a similar project with the ST’s Eclipse-based IDE. If this is the case, we can help you find the difference between the 2 projects and update the VisualGDB project to replicate the other project’s results.

[support]

Hi,

Please refer to the following page for the instructions on downloading the old packages: http://visualgdb.com/support/oldpackages/

[support]

No problem. First of all, please try right-clicking on the function entries that did not get analyzed correctly and select “View Analysis Log”. This should highlight the code paths triggering various warnings.

You can then customize the analyzer by cloning the following project: https://github.com/sysprogs/VisualGDBExtensibilityExamples/tree/master/PlatformSpecificStackAnalyzers/ARM. Simply build the ARMStackUsageAnalyzer.dll file and copy it into <VisualGDB Directory>\StackAnalyzers, replacing the version shipped with VisualGDB. You can then use another Visual Studio instance to step through ARM-specific stack analysis logic or to modify it to support project-specific cases.

The Disassembly view would show the results once you select a specific function on top of the view.

 

[support]

Hi,

The most common cause of this issue would be another dialog window opening up in the background. Due to WinForms/WPF interop issues, dialog windows sometimes appear underneath the regular VS window and are hence not visible. Please check the task list (Alt-Tab) and the VS icon in the Task Manager to see if there are any extra dialog windows (e.g. confirming some missing tools).

If it doesn’t help, please try updating to VisualGDB 5.5 Preview 3 and let us know the exact project type you are creating (Embedded/Linux/etc; CMake/MSBuild/GNU Make) and also whether the problem triggers for other project types. Also please share a screenshot and a call stack or the frozen VS instance once it freezes for about 1 minute or more.

[Author]

Posts