Forum Replies Created
-
Posts
-
Sorry, not sure what you meant. Our tutorial does show how to create a project from scratch. If something doesn’t work as it is shown in the tutorial, please double-check that you follow all the steps as described. If it still doesn’t help, please feel free to share the complete steps to reproduce the issue, including all the relevant screenshots per our problem reporting guidelines and we will look further into this.
Hi,
For all sales- and license-related inquiries, please contact our sales via our contact form.
Sorry, this looks like an issue in OpenOCD executable and not something specific to VisualGDB. Our best advice would be to try programming this device using the Eclipse-based STM32CubeIDE that also uses OpenOCD. If the STM32CubeIDE works, please try using the OpenOCD script from it with VisualGDB – you should get the same results since the underlying mechanism will be the same.
If OpenOCD doesn’t work there either, please consider using Segger J-Link. It comes with a very well-tested and fully supported replacement for OpenOCD and typically just works out-of-the-box.
Hi,
The settings on the VisualGDB side appear correct. So this is likely a bug in J-Link, or some kind incompatibility between the Segger software, firmware and hardware. If the problem can be reproduced outside VisualGDB as well, we would advise checking it with Segger support.
Another option would be to just use OpenOCD. It supports J-Link as long as you replace the regular Segger USB driver with the WinUSB one, and we have successfully used it to debug Raspberry Pi Pico. If you use the “USB Devices” view in VisualGDB instead of “Debug Methods”, it will automatically suggest installing the matching USB driver.
Normally it should work out-of-the-box. If not, please create and attach a gdb log file demonstrating the issue and we will look further into it.
Also in order for us to link your account to your company’s support profile, please either update your forum email address accordingly, or let us know your company email/key via the support form.
Hi,
It looks like your support has expired. Please kindly renew it on this page and we will try to help you find a workaround.
@donmilne, sorry about that. The previous build contained a bug that prevented the Raspberry Pi wizard from showing correctly outside the testing environment. Please try this one: [obsolete]. It also supports editing of the Pico SDK configuration, but automatic debugging is still not fully ready.
@arrow201, we will support all debug probes that are supported by OpenOCD. We have specifically tested Segger J-Link, Olimex ARM-USB-OCD-H with the SWD adapter and the regular Raspberry Pi in the bitbang mode (this will require building the OpenOCD fork on Raspberry Pi itself, but VisualGDB will do it automatically).
Update: Raspberry Pi Pico is now officially supported by VisualGDB 5.6 Beta 1. You can find a detailed tutorial here: https://visualgdb.com/tutorials/raspberry/pico/
Hi,
VisualGDB would normally regenerate the device-specific part of the project when you change some of the device-level settings (e.g. library type). You can find a detailed explanation of this mechanism for STM32 devices here: https://visualgdb.com/documentation/embedded/stm32/.
Most likely you have previously manually removed some of the VisualGDB-managed files from the project, and editing the settings via VisualGDB GUI put them back.
It is hard to say why a project referencing the .ld file twice would not open. If you could reproduce the issue on a cleanly created project and share the steps we could follow on our side, we can gladly look into it. Otherwise, it is likely triggered by a rare incompatible combination of settings that were set at some point.
You can also try using the new Advanced Embedded CMake Project Subsystem. For this project type VisualGDB has full control over the contents of Solution Explorer, so it can automatically prevent many common errors that happen with VC++-based projects.
No worries. We usually try to make sure our BSPs contain the libraries that are included in the original vendor-supplied SDKs and used by a sufficiently large number of SDK examples. This ensures that the libraries have been tested in that specific environment and will usually work seamlessly.
Integrating additional libraries would require considerable ongoing porting and testing effort, so instead of doing it on our side, we focus on providing convenient GUI so that our users could do it in their environments.
If you have a non-trivial project structure, we would advise trying out the new Advanced Embedded CMake Project Subsystem. CMake projects decouple device-level and toolchain-level settings from library-level settings, so you can very easily maintain a repository of reusable libraries compatible with multiple devices.
You can read more about Advanced Embedded CMake projects in the following pages:
These toolchains are built based on the open-source tools such as GCC and GDB. They are provided free of charge and we are not aware of anyone who would agree to support them without directly billing for the time required to investigate the issues, sorry.
Sorry, we do now know why gdb is exiting. Based on the logs you submitted, it is not caused by VisualGDB.
Thanks, we have rechecked it and made sure they are properly included in the latest 20210301 release.
Most likely, your CI setup is running VisualGDB under a different user account with a different %LOCALAPPDATA% directory. You can double-check it by adding a custom pre-build step for displaying the %LOCALAPPDATA% and %USERNAME% variables (cmd /c echo %LOCALAPPDATA%). If these are different between the manual and scripted run, please double-check the user account in the CI settings.
Thanks for the log files. This looks like the gdb executable itself exits unexpectedly. You can recheck this by killing arm-none-eabi-gdb.exe via Task Manager – VisualGDB will show the same message and same logs. The final -gdb-exit command is executed as a part of the regular cleanup sequence. In this case, GDB has already exited at that point.
If you would like to get to the bottom of it, you could try building a debug build of gdb itself, and attaching another debugger to it, but this is something to do at your own risk, sorry.
The breakpoint in main() is expected. VisualGDB sets it to support the “Step into new instance” command (starting the debug session with F10 instead of F5 to stop in main()).
No problem. You can easily add 3rd-party packages into VisualGDB by following the file structure in the %LOCALAPPDATA%\VisualGDB\EmbeddedEFPs\Profiler directory. Simply create another subdirectory containing one or more embedded frameworks described in the EFP.XML file and VisualGDB will pick them up and let you reference them from VisualGDB Project Properties.
You can use our open-source BSP Generators as a starting point.
We can also do everything for you, including research, implementation and testing via our consulting services. Feel free to reach out to our sales if you would like to get a quote.
