Forum Replies Created
-
Posts
-
Hi,
Strange, this should normally not happen. Could you please attach a screenshot of the entire VS window (and the context menu) illustrating this? It might contain some clues explaining what is going on.
Hi,
This could happen if VisualGDB could not locate the CMake target that corresponds to the currently edited source file. We should be able to investigate this further if you could share a repro project.
Hi,
Strange, we have double-checked this on a simple “Hello, world” program and VisualGDB actually followed the regular VS formatting setting. Perhaps something else is affecting this? Could you reproduce it in a minimal source file that doesn’t contain anything else? If not, could you please share the minimum repro case?
Hi,
No worries, the exact text slightly varies between different BSP versions, so that should not be a problem. Picking the right board is important though as different boards have slightly different pinouts. Normally the board number is printed on a sticker on top of the MCU (nRF52-DK should be PCA10040).
Hi,
If those expressions work in the watch window, the gdb stub is reporting them correctly. So you should be able to right-click in the Registers window and enable other register groups (VS only enables the basic CPU registers by default).
Hi,
Yes, please contact our sales with your license key information and we will issue you a trial extension voucher.
Hi,
This would be fairly tricky as VisualGDB expects the MSBuild projects to define a few VisualGDB-specific variables that would be missing in the project if it is controlled by an external MSBuild rules. The easiest way to get VisualGDB to debug it would be via the Embedded Quick Debug mechanism.
Hi,
This looks like a problem that was recently fixed in our development branch. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2081.msi
Hi,
Thanks for checking this. Looks like it could be some configuration issue rather than a race condition then. In order to pinpoint this, please follow the steps below:
- Take a note of the module list block from the gdb log (e.g. x/16xb 0xbf1e8940)
- Start OpenOCD manually using a command line from the OpenOCD window in VisualKernel (stop the VisualKernel session first).
- Start gdb on the Linux machine manually and connect to gdb (target remote …)
- Try reading the module list block by running the x/16xb <address> command manually. Does this result in non-zero values?
If the manual setup yields non-zero block contents, please try comparing the initialization commands between the manual mode and the VisualKernel GDB session log.
If the manual setup also reproduces the problem, please try checking if other commands (e.g. bt, disassembly) work and if reading memory using the OpenOCD commands (e.g. mon mdw <address>) works. This should help us understand which part of the debugging pipeline is affected by the bug and devise a workaround.
Hi,
Thanks, this is already fixed in our development branch and will be included in the upcoming v5.4 Preview 1. Until then, editing the XML file manually is the recommended workaround.
Hi,
This would happen for environment variables that are only set for interactive shells. We actually have a detailed page describing this (and known workarounds) here: http://visualgdb.com/support/fixenv/
If it doesn’t help, please let us know and we will investigate this further.
Hi,
Yes, we removed the compactcpp library from the latest toolchain as it is no longer needed with the latest libc++ optimizations. VisualGDB would normally update your project automatically if you change any settings on the first page of VisualGDB Project Properties, but removing it manually should produce exactly the same result and is totally OK.
Hi,
Please try selecting “Show STM32CubeMX samples” on the sample selection page in the VisualGDB wizard. It will show the sample projects that came with the STM32CubeMX software libraries and might include an out-of-the-box UART example for your board.
Hi,
Sorry, we don’t have any tutorial for the STM32Cube programming tool. However you can easily program your firmware without starting a debug session by selecting Debug->Program Embedded Firmware.
H,
Thanks for the repro. It looks like your toolchain fine sets the CXX executable in a way that confuses CMake. Please try moving the compiler arguments into a separate CMAKE_CXX_FLAGS statement:
set(ENV{CXX} "arm-vgdbtest-linux-gnueabi-g++" CACHE STRING "" FORCE) set(CMAKE_CXX_FLAGS "-march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=$ENV{SDKTARGETSYSROOT}" CACHE STRING "" FORCE)
