Forum Replies Created
-
Posts
-
Thanks, this looks like a slightly different variation of the problem coming from the disassembly window. Please try this build: VisualGDB-5.5.104.3990.msi. If the problem persists, please attach the updated log and screenshots.
Also, in case anyone else is experiencing this, below is an explanation why it’s taking so long to pinpoint.
A recent update to Visual Studio changed the logic used by the Call Stack window so that it will sometimes try to re-query its contents while VisualGDB is already running another GDB command. This happens very rarely and intermittently, and almost never happens when a debugger is attached to the VS itself, so we have initially incorrectly concluded that VS was losing the frames reported by VisualGDB (in reality, it was sometimes re-querying them in an unsupported way that never happened with a debugger attached). We have initially updated VisualGDB to prevent VS from re-querying the frames by temporarily suspending background job processing in the main thread until the main GDB command would be completed, but it did not solve all the instances of the problem. The latest fix introduces caching instead. Now if Visual Studio queries the call stack in an unexpected way, VisualGDB will simply return the last known version of it. This may still not be a 100% solution in case VS submits a stack frame request in an unsupported context before submitting it in a regular context. As the problem is extremely intermittent and rare, it’s hard to predict whether it’s likely or not. If this happens, we will consider other workarounds as well.
Hi,
There is no advantage on building the code for Raspberry Pi Pico on a regular Raspberry Pi and it is not practical to build the code on the Pico itself. Hence VisualGDB will build the code directly on Windows using a cross-toolchain. You will be able to use a regular Raspberry Pi as a debug probe if you prefer this option.
Hi,
There is no special VisualGDB GUI for configuration-specific CMake properties, however you easily achieve this by wrapping the relevant parts of the CMakeLists file in conditional statements checking the CMAKE_BUILD_TYPE variable.
Hi,
Please refer to this page for a detailed overview of various Embedded CMake settings, including exceptions/RTTI.
Most likely, your toolchain does not support this language feature, or there is an error in the source file, or you need to select a different language standard.
Our best advice would be to try dumping the gcc command line used by VisualGDB as described here and verifying that the -std option gets passed to gcc.
Hi,
That would be normally in the project-level settings under the C/C++ -> Advanced tab. Please refer to this page for more details.
Hi,
We have already released an updated toolchain based on esp-2020r3 and the latest ESP-IDF 4.1 and 4.2 (esp32-gcc8.4.0.exe). You can install it via VisualGDB Package Manager or by downloading the file directly.
Hi,
This is why we always ask to post uncropped screenshots when reporting issues. It’s often impossible to tell what is going on without seeing the entire VS window.
Hi,
In the latest VisualGDB 5.5R4 multiple output windows have been merged in a single VisualGDB Output window (item #7 on the screenshot).
This was done because previously different output windows (e.g. semihosting or gdbserver output) would appear dynamically in front of other windows, depending on the actual output of the underlying program. Now the combined VisualGDB Output window is always shown during debug sessions and will always remember the state/location it had at the end of the previous session.
You can revert back to the old behavior using the Use Combined Output Window setting.
Hi,
Please try using the Signals button in the GDB Session window.
Hi,
Normally you should be able to open the semihosting window via a command under the Debug->Windows menu. If it doesn’t work, please try reproducing the problem on a clean project created from scratch.
If the problem persists, please let us know the steps we could follow to reproduce it and we will investigate it further.
Hi,
VisualGDB fully supports Segger J-Link via the Segger GDB stub, however we have not specifically tested it with the multi-core STM32H7 devices.
Generally, we would advise simply using ST-Link as shown in this tutorial. It involves a special build of OpenOCD maintained by ST that has been specifically designed to work with the multi-core devices. If you would like to double-check whether J-Link supports this configuration, please contact Segger support. If they can confirm that the Segger GDB stub supports the device you are targeting, VisualGDB will work with it out-of-the-box.
