Forum Replies Created
-
Posts
-
No problem, we can help you. Please double-check that you are building the correct configuration, since custom build steps are defined for debug/release configurations separately.
If it doesn’t help, please try enabling the verbose build mode and share the build log (from the regular VS Output window, not the VisualGDB Build window) and also the name of the .vgdbsettings file that contains the custom step.
Thanks for the input. Normally, VisualGDB would show the “this feature requires Custom edition” overlay on most Custom-only property pages during the trial. However, once the trial runs out, the extra pages will indeed be just hidden.
We will mention the Custom edition next time we update the custom step tutorial.
Hi,
Most likely, you have already installed the latest versions of the toolchains, so they will appear in the Installed view, but not in the Online view. Please try double-checking both views.
Hi,
The custom build/debug steps are supported starting from the Custom edition of VisualGDB (see our feature matrix). Most likely, you are using a lower edition that does not support them.
You can find out more about VisualGDB Custom Edition features here or upgrade your edition using the following page: https://sysprogs.com/splm/mykey
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.
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.
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).
Hi,
Please see the following page for troubleshooting instructions: https://visualgdb.com/documentation/troubleshooting/install/
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.
Hi,
Looks like you are missing the semihosting syscalls. Please see the following tutorial for details: https://visualgdb.com/tutorials/arm/semihosting/
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 fileHi,
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.
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).
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).
