[support]

Hi,

This is not a real objcopy. It’s part of a tool used by VisualGDB to capture the command lines that mbed would pass to gcc, ld and objcopy, in order to reconstruct the code model.

Please use the objcopy executable from the toolchain directory instead.

[support]

Hi,

Sorry, as the Arduino workflow relies on frequently downloading numerous support packages and libraries, and also resolving dependencies between them, it will not be very usable without a reliable Internet connection anyway, hence we do not support this scenario.

[support]

Hi,

Thanks for the kind words. The STM32 package is based on the official SDKs from ST. You can find the exact SDK versions in the SDKVersions.xml file inside the BSP directory and cross-reference it with the SDK revision history from ST.

For OpenOCD packages we build snapshots of the OpenOCD source tree, since OpenOCD does not have regular release cycle. There is no official changelog, but you can infer it from git commits (sorry, it’s up to OpenOCD maintainers).

You can find very detailed VisualGDB revision history here (changes in maintenance releases, such as v5.5R3 are shown at the end of the v5.5 change list).

[support]

Hi,

Please see the following page for troubleshooting instructions: https://visualgdb.com/documentation/troubleshooting/install/

[support]

Hi,

Why did you set the Make command to arm-linux-gnueabihf-gcc.exe?

[support]

Sorry, VisualGDB cannot automatically fix every possible error in every project. It does its best in suggesting solutions to common errors, but it does not work 100%. Our best advice would be to read more about the role of system calls in embedded projects, understand what component requires them and what implementation suits your requirements the best, and then select the matching implementation as shown in our semihosting tutorial.

[support]

Hi,

Looks like you are missing the semihosting syscalls. Please see the following tutorial for details: https://visualgdb.com/tutorials/arm/semihosting/

[support]

Thanks, we have fixed it on our side and will include the fix in the next BSP release. As the issue is very minor and has an easy workaround, we will not make a separate release until we discover other issues with the current BSP, or a newer SDK is released.

You can patch it on your side by applying the following patch to %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\BSP.XML:

--- bsp.old	2020-10-12 19:57:10.832588900 -0700
+++ BSP.XML	2020-11-16 16:19:10.049551300 -0800
@@ -158561,6 +158561,7 @@
         <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/gfx/nrf_gfx.c</string>
         <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/gpiote/app_gpiote.c</string>
         <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/hardfault/hardfault_implementation.c</string>
+        <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/hardfault/nrf52/handler/hardfault_handler_gcc.c</string>
         <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/hci/hci_mem_pool.c</string>
         <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/hci/hci_slip.c</string>
         <string>$$SYS:BSP_ROOT$$/nRF5x/components/libraries/hci/hci_transport.c</string>
\ No newline at end of file

[support]

Hi,

Looks like you have created a project in a directory that contains spaces in path (VisualGDB’s project wizards do warn about it). Please use a directory without spaces instead and everything will work out-of-the-box.

[support]

Hi,

The “undefined reference” error means that a certain function has been declared, but not defined (see this tutorial for a detailed explanation). With FreeRTOS, it would happen if the heap_<N>.c file (that implements the heap functions) was not included in the project.

First of all, please try creating a FreeRTOS-based project via the regular Embedded Project Wizard, then locate the heap file in Solution Explorer, and take a note of its location under the FreeRTOS directory (you can change the heap type via VisualGDB Project Properties -> Embedded Frameworks -> Configuration).

Then, please check the .gpdsc file generated by STM32CubeMX for a reference to a similar file (heap_<N>.c). If the file is referenced, it’s a bug in our STM32CubeMX importer and we should be able to fix it if you could attach the .gpdsc and .ioc files. If the file is not referenced, it’s a bug in the STM32CubeMX generator, and you can work around it by manually adding the heap file to the project via Add->Existing Item (the menu option will not appear under the STM32CubeMX Project node in Solution Explorer, as this node’s contents are managed by STM32CubeMX).

[support]

Please try checking if the build output window contains any error messages. If the build fails due to errors, please resolve them and make sure the build succeeds before proceeding with debugging.

If you cannot find any error messages, please share a screenshot of the VisualGDB Build window and the regular Output window after building the project (not trying to launch it).

[support]

Hi,

Looks like you are trying to launch a project that has not been built. Please try building it first.

[support]

Hi,

Please make sure you use the new STM32CubeMX Project Wizard as shown in this tutorial. It will setup the necessary files automatically. If it still doesn’t work, please attach the screenshots of all the wizard steps in your setup, as well as any error messages, and we will help you understand what is going on.

[support]

Hi,

The FreeRTOS package included in the STM32 BSP is taken from the latest STM32F7 SDK at the moment of the BSP generation. Hence, once ST updates the STM32F7 SDK to include FreeRTOS 10.4.1, our BSP will include it as well.

That said, you can always fork our STM32 BSP generator and tweak it to use any versions of SDKs and frameworks of your choice.

[support]

Thanks for sharing this, it makes sense.

[Author]

Posts