Forum Replies Created
-
Posts
-
@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:
Thanks for renewing your license. Regarding the installation issues, please see the following page: https://visualgdb.com/documentation/troubleshooting/install/
Regarding other issues, we can gladly investigate them, however we would need to know the steps we could follow to reproduce them on our side. Please follow our problem reporting guidelines and share the steps (including all relevant screenshots) to reproduce the issues from scratch and we will look further into it. For better tracking, we would advise creating a separate forum thread for each issue.
Hi,
We generally cannot advise STM32-compatible devices that are not manufactured by ST (or for ST) to our users due to the following concerns:
- Many of the components of the ST software library are published under this license, that explicitly limits it to ST devices:
This software or any part thereof, including modifications and/or derivative works of this software, must be used and execute solely and exclusively on or in combination with a microcontroller or microprocessor device manufactured by or for STMicroelectronics
We are aware that some of the vendors provide their own software libraries, however the original ST libraries compatible with the genuine ST devices offer a wider selection of components, examples and libraries. Hence, we recommend using the original ST devices instead.
- We did a brief research on the availability of the ST-compatible devices on major distributors (DigiKey and Mouser). At the time of checking, they did not carry any of the devices we checked.
- We considered adding support for the STM32 Blue Pill board to Analyzer2Go some time ago and ran a few stress tests on some of the boards. As a result, the boards we tested stopped working. We did a brief online search involving the part number on one of the boards and found a few posts warning about the ST clones.
- Comparing Google Trends for STM32 and some of the compatible device families showed a heavy bias towards the STM32-related search inquiries. We concluded that focusing on improving the STM32 integration will make our product relevant to a larger user base, than adding support for STM32-compatible devices not manufactured by ST.
- We believe that the STM32 devices gained their popularity due to exceptionally well-designed and maintained software libraries, examples and configuration tools. As these tools are available free of charge and are funded by the sales of the genuine STM32 devices, and as an official ST partner, we believe it would be fair to advise our users to use the genuine STM32 parts.
After carefully reviewing the factors mentioned above, we decided to not officially support them. That said, VisualGDB is very flexible and offers various workarounds in case you would like to target the devices that are not supported officially:
- VisualGDB is fully integrated with the IAR and Keil compiler, so you can simply install it and pick it in the Embedded Project Wizard if you would like to target a device not directly supported by VisualGDB.
- You can also try creating a project manually as shown in this tutorial. This will also work with any device that is not directly supported by VisualGDB, but is based on a supported core (e.g. ARM).
- Many of the components of the ST software library are published under this license, that explicitly limits it to ST devices:
