Forum Replies Created
-
Posts
-
Hi,
Thanks, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2562.msi
Hi,
No problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2562.msi
It will honor the “Suppress CodeJumps” setting for the QuickInfo tooltips.
With the jumping popup window, it might be tricky. VS uses a rather hacky way to position the popup, so VisualGDB has to do some guessing on top of that to reposition it properly and it might not work correctly 100% of the time. If you could share a quick video showing the problem, we should be able to tell whether we could easily fix the behavior you are observing.
The second glitch might be specific to some code. Unfortunately it looks like screenshots #1 and #3 are the same. Could you please double-check it and also share the .c file where this is reproduced?
Hi,
Sorry, this is caused by the implementation details of the VS language service framework (that VisualGDB has to use in order to be compatible with 6 different VS versions), so unfortunately we won’t be able to fix it anytime soon.
Hi,
Please try pressing Alt+Tab several times see if there are any message boxes shown behind the VS window (sometimes they are shown incorrectly by VS).
If you cannot find any, please capture a VS stack trace as shown here: http://visualgdb.com/support/callstack
Hi,
Sorry for the inconvenience. As Nordic removed the support for nRF51 from their new SDKs, we had to start shipping 2 independent BSPs instead of just one, hence breaking backward compatibility. Normally we try to ensure the backward compatibility between our packages, but a lot of the BSP structure comes from the device vendor.
Hi,
We have just published a tutorial showing the stack analysis here: https://visualgdb.com/tutorials/arm/stack/static/
As a quick check, could you confirm that the “Disassembly” view in the memory explorer works correctly? If yes, we will add further diagnostic logging to the stack analyzer and should be able to pinpoint it.
Hi,
Most likely you have created a project for the nRF51 chip (not nRF52) that was deprecated and removed from the modern Nordic SDKs. We handled this by forking nRF51 support (based on the latest SDK that supports it) into a separate BSP with a different ID.
Please try locating the nrf5x.xml file in your project directory and check the exact MCU ID it mentions. Then create a new project for the same MCU with the VisualGDB project wizard and check the BSP ID it puts in the new project’s nrf5x.xml file. Finally, copy the new ID to your old project and you should be able to build/debug it again (you may need to regenerate MCU-dependent files via VisualGDB Project Properties).
Hi,
OK, thanks for sharing this. Looks like we know what is going on. Your project likely explicitly stores the ARM toolchain location and VisualGDB is unable to override it with the dummy toolchain that produces a code model. We should be able to add a workaround for this. Would you be able to attach a copy of your mbed configuration files (*.py and *.json from the project’s directory)?
Hi,
It looks like your project structure might be different from what VisualGDB expects, hence it does not manage to parse it.
VisualGDB handles advanced mbed projects by temporarily replacing the toolchain with a dummy one that pretends to build all the sources, while creating a full log of all gcc/ld invocations, so VisualGDB can reconstruct the project structure from them. Most likely something about your project setup is preventing this from working.
We should be able to update VisualGDB to support it if you could share the following files under your project directory:
- VisualGDBCache\<configuration>\CodeSenseDir\MbedCommandLines.txt
- VisualGDBCache\<configuration>\BuildCommandLines.txt
Hi,
Thanks for sharing this. We have double-checked the config files from Visual Studio itself and it looks like it also uses the same flag, so we added it to the config file that comes with VisualGDB as well. Hence you won’t need to edit the file next time you update VisualGDB.
Hi,
Just wanted to let you know that we have received more requests for better mbed support recently and were able to add a new advanced mbed project subsystem to VisualGDB.
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2553.msi (use the new mbed wizard).
We will post an official announcement for this tomorrow and a tutorial later this week.
Hi,
No problem, we have added a command to toggle the CodeJumps annotations via Edit->Advanced menu to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2552.msi
You can assign a keyboard shortcut to it via the Tools->Customize->Keyboard command.
Regarding the references, it indeed looks like some glitch on our side, however unfortunately we were not able to reproduce it on our side. Please try narrowing down a specific sequence of steps that leads to it, or simply capture a video demonstrating the problem. This should help us see what is going on and add a fix for this.
Hi,
Strange. We have rechecked all the assemblies shipped with VisualGDB and could not find any mixed-mode ones.
The error looks like the .Net runtime is failing to load the VisualGDB settings types. Could it be a corrupt .Net installation? Can you confirm that VisualGDB runs as expected on other machines in the same domain/with the same group policy?
We have also added extra logging to this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2552.msi
Please try reproducing the problem with it (enable verbose mode by adding “/v” to VisualGDB’s arguments). It should show a much more detailed exception report that should help narrow this down.
Hi,
Thanks for the detailed problem description and the screenshot. Looks like it was indeed a remnant from Cygwin-based toolchains on our side.
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.9.2552.msi
