Forum Replies Created
-
Posts
-
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.
Hi,
Sorry for the delay. We have reproduced the issue on our side. VisualGDB was applying the “nrf*” filter to the boards in the custom directory similar to the way it does for the regular Zephyr boards.
We have fixed it in the following build: VisualGDB-5.6.1.4039.msi
Hi,
No problem. We have rechecked this and indeed the STM32 SDKs contain a ready-to-use version of mbedTLS. We have updated our STM32 BSP generator internally and will include it in the next STM32 BSP release.
You can also add it to the latest 2021.02 BSP by extracting the following file into the BSP directory: https://sysprogs.com/files/tmp/mbedtls.7z
Hi,
Most likely, you are using a MinGW toolchain that has not been tested with TinyEmbeddedTest. Please try using our MinGW toolchain instead.
Hi,
Based on the description you provided, OpenOCD or gdb likely exits unexpectedly and hence VisualGDB ends the debug session.
We would advise checking OpenOCD logs and GDB logs for anything that could explain what is causing the session to end. You can find more about various diagnostic logs in the following pages:
