[support]

Hi,

Thanks for the suggestion, we will try to add an option for this into the upcoming v5.4. As a current workaround, please consider using the “Save semihosting output to” option on the Embedded Debug Tweaking page of VisualGDB Project Properties.

[support]

Hi,

It’s hard to say why the projects didn’t get imported correctly, although our STM32 support package comes with pre-imported ST samples from the original SDK packages (we have tested that each of them builds out-of-the-box). Please follow this tutorial to see how to create projects based on those samples.

[support]

Hi,

Thanks for the screenshot. Looks like VisualGDB might not be able to query the registers from the stub.

Please try capturing a gdb session log as described here and attach it to this thread (or send it to our support email). Please also attach a screenshot showing the context menu you see get the Registers window – it might contain useful clues.

[support]

Hi,

This type of issue is indeed fairly tricky to diagnose. Our best advice would be to try setting breakpoints at _exit(), ExitProcess() and below main() (see the call stack with the backtrace past main option).

[support]

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.

[support]

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.

[support]

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?

[support]

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).

[support]

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).

[support]

Hi,

Yes, please contact our sales with your license key information and we will issue you a trial extension voucher.

[support]

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.

[support]

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

 

[support]

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:

1. Take a note of the module list block from the gdb log (e.g. x/16xb 0xbf1e8940)
2. Start OpenOCD manually using a command line from the OpenOCD window in VisualKernel (stop the VisualKernel session first).
3. Start gdb on the Linux machine manually and connect to gdb (target remote …)
4. 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.

[support]

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.

[support]

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.

[Author]

Posts