Forum Replies Created
The fast semihosting works for output only, however it is backward-compatible with the regular semihosting, that works both ways. I.e. you can use the fast semihosting to output data from the device without any delays, and at the same time use the regular semihosting API to read the input from VisualGDB.
If you are looking for a fast way to send data to the device, please consider using the Test Resource Manager API.November 10, 2022 at 12:21 in reply to: How to use supplied .ioc file when importing CubeMx project? #33427
Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:
- The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
- Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. If the problem happens with a specific ioc file, please provide the steps (with full uncropped screenshots) how you create that file.
- The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.
You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.
Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.November 10, 2022 at 08:41 in reply to: How to use supplied .ioc file when importing CubeMx project? #33424
Thanks for confirming your license. The .ioc files contain settings for the STM32CubeMX generator and do not directly reference any source files/build settings or anything else that could be imported.
In order to import them into VisualGDB, you would first need to open them in STM32CubeMX, then generate an STM32CubeIDE project, and finally import the generated STM32CubeIDE project using the VisualGDB Embedded Project Wizard.
Please refer to the following tutorial for detailed troubleshooting instructions: https://visualgdb.com/tutorials/arm/import/diagnose/November 7, 2022 at 11:05 in reply to: Issue with running OpenOCD remotely on Raspberry Pi #33401
We have just retested it with the latest Raspberry Pi Bullseeye image and it worked just fine.
Please try checking if running OpenOCD on another Linux box works. It doesn’t need to connect to the actual hardware – any output from OpenOCD (e.g. showing its version) indicates that it has launched successfully.
You can also try running sshd on your Raspberry Pi in foreground mode from a physical console:C++12sudo killall sshdsshd -d
This will force sshd to log every request issued by VisualGDB, so you can double-check whether VisualGDB attempts to launch OpenOCD and what arguments it uses.November 3, 2022 at 12:59 in reply to: Issue with running OpenOCD remotely on Raspberry Pi #33387
We have tested this on our side during the release process, so the issue is likely caused by some configuration specific to your Raspberry Pi image.
Either way, you would indeed need to escape the arguments to “ssh” so that the quotes are handled correctly (although it would not affect the way VisualGDB runs commands). An easier way would be to create a script file (e.g. /usr/bin/openocd-test), make it executable and place the command line in there:C++1234#!/bin/shecho TEST123echo TEST456 > /tmp/test.txt/usr/bin/openocd <hardcoded arguments>
Then you can select this script as the OpenOCD executable in VisualGDB settings, and see if it works. Specifically, if it shows “TEST123” in the VisualGDB Output window and if it creates a /tmp/test.txt file as well.
The script will ignore the actual arguments passed to it, so you can test it on WSL by just running “ssh pi@chani /usr/bin/openocd-test”.November 3, 2022 at 12:32 in reply to: Issue with running OpenOCD remotely on Raspberry Pi #33384
Thanks for checking this. The OpenOCD view under VisualGDB output should not be blank! It looks like OpenOCD actually never gets a chance to run when launched by VisualGDB.
It could happen if you had 2 different openocd executables in different directories and 2 incompatible values of the PATH variable for the SSH command mode (used by VisualGDB) and the SSH shell mode (used by regular shells).
You can try troubleshooting it further by setting the explicit path to the OpenOCD executable in VisualGDB Project Properties. If it doesn’t help, please try launching OpenOCD via SSH by running the following command from another Linux machine (or WSL):C++1ssh [user]@[ip address of Raspberry Pi] full-path-to-openocd <command line parameters>
If it doesn’t start a valid OpenOCD session (producing output), something about the SSH configuration is interfering with it.November 3, 2022 at 08:48 in reply to: Issue with running OpenOCD remotely on Raspberry Pi #33378
If we understood you correctly, having VisualGDB launch OpenOCD on the target has no effect, but running it manually works.
If this is the case, please follow the steps below:
- Start a debug session with VisualGDB. Click “ignore” when it reports the error.
- Double-check the Debug->Windows->VisualGDB Output->OpenOCD window in Visual Studio. Does OpenOCD show any errors there? Is it still running?
- If OpenOCD appears running, can you see it on the target machine by running “sudo ps -ax”? If not, you might be running it on a different target.
- If OpenOCD exited with an error, what is the error message? Also are you doing anything different when launching it manually (e.g. running it under sudo or connecting the device differently)?
No problem, we have updated our MinGW32/MinGW64 packages based on the latest releases from MSYS2.November 2, 2022 at 16:33 in reply to: Issue with running OpenOCD remotely on Raspberry Pi #33369
No problem. Please try the following:
- Start a debug session with VisualGDB and take a note of the debug port used by OpenOCD.
- When VisualGDB reports that it cannot connect to the target, press the “ignore” button. Do not stop the debug session, so that VisualGDB keeps OpenOCD running.
- While OpenOCD launched by VisualGDB is still running, try manually running gdb and connecting to the target.
If the manually initiated connection works, please double-check your firewall settings and try disabling it, as it might be specifically blocking the Visual Studio process and gdb launched by it.
If the manually initiated connection doesn’t work, please try ending the debug session in VisualGDB and immediately running OpenOCD with the same command line (please use the complete command line including all environment variables from View->Other Windows->VisualGDB Diagnostics Console).
Please let us know your findings and we will advise you on further diagnostic steps.November 2, 2022 at 13:23 in reply to: Issue with running OpenOCD remotely on Raspberry Pi #33367
This could indicate a network/firewall issue. Please try doing the following manually:
- Run OpenOCD on Raspberry Pi
- Run GDB on Windows
- Manually run the “target remote” command in GDB.
If the connection doesn’t work, please try changing the port to a lower value (e.g. 3000).
You can change the port number used by VisualGDB by setting the PreferredGDBPort element in the .vgdbsettings/.vgdbcmake file to a non-zero value. It will override the default logic of picking a random unused port.October 31, 2022 at 13:54 in reply to: Dual Core STM32CubeMX project includes search path #33356
VisualGDB follows the project structure set by the STM32CubeMX generator, placing all files generated by it (including the main one) into the BSP library, and the user-added files directly into the executable.
As the executables and the BSP libraries are defined in different CMake targets, they have different sets of settings (executables inherit the settings from the BSP libraries) controlled by CMake statements like target_include_directories(). Editing various settings via GUI ultimately generates one or more CMake statements and has exactly the same affect as if these statements were added manually.
Based on the description you provided, you ended up with a set of target_include_directories() statements that do not match the actual targets. The easiest way to troubleshoot it would be to double-check what statements got added to CMakeLists.txt files. If they reference incorrect BSP names (see the find_bsp() statements), you can simply adjust them manually by editing the CMakeLists.txt file. If you can confirm that VisualGDB consistently generates invalid statements in some cases and can share the steps to reproduce the issue we should be able to fix it. Otherwise, simply patching the generated statement manually should work fine as well.
You can read more about CMake targets and how VisualGDB handles them here: https://visualgdb.com/documentation/projects/cmake/
As per the documentation page, running OpenOCD remotely is supported starting from the Linux edition. If you are using the lower Embedded edition, you can always upgrade it here: https://sysprogs.com/splm/mykey.
If the feature worked earlier, it was likely during the trial period which is equivalent to the highest available Ultimate edition.
Please do check the page we linked in the previous reply – it shows the exact setting for this exact behavior.
You can also try using DWARF 5. It is considerably different from DWARF4 and might work around the issue. Another thing to try would be using GDB indexes.
You can troubleshoot the slow gdb response by running the “set debug remote 1” command and checking whether the delay comes from the target answering GDB requests (e.g. OpenOCD) or gdb itself (i.e. happens between a reply and the next request).