Forum Replies Created
-
Posts
-
Yes, please try running msbuild with the -verbosity:diag switch and either attach the diagnostic log here, or send it via our support form. It should explain what is going on.
Hi,
Sorry, this is a known limitation of VisualGDB. It offers numerous debug-time tool windows that provide various insights into the state of the target and the debug session, however this only works when only one VisualGDB-based debug session is active at the same time. As a workaround, please consider splitting your solution into multiple ones.
Thanks for the update. This looks like a different issue. If the breakpoint circle is hollow inside, the code where the breakpoint is set is not a part of the debugged binary (e.g. it is not actually called from any other code and was hence discarded).
You can double-check this by inserting the following line into the functions that don’t seem to work:
asm("bkpt 255");It will trigger a breakpoint each time the line gets executed. If it doesn’t happen, the function is actually not called and using the “find references” command should help understand why this happens.
If the breakpoint does trigger and you see the “bkpt 255” instruction in Disassembly, but the source code doesn’t appear, the problem is due to missing/mismatching debug symbols. If this is the case, we can provide more detailed instructions on diagnosing it.
Hi,
Please simply set the breakpoint before starting debugging with F5 and VisualGDB will be able to handle this automatically.
You can also modify the behavior of the “Step into new instance” command (F10 instead of F5) to stop as soon the program is loaded into the MCU (i.e. at the reset handler) via VisualGDB Project Properties -> Embedded Debug Tweaking.
Normally, the sdkconfig.h file should be handled by the ESP-IDF build system itself. The only advice we could give is to try creating a project based on GNU Make instead of CMake (it uses a different set of build scripts) and if it doesn’t work either, check if the problem can be reproduced by building from command line.
If it doesn’t work from command line either, please check with Espressif – it might be a bug on their side. If it works when built manually, but fails under VisualGDB, please let us know both build command lines and we will investigate.
Thanks for the update. The behavior you described actually makes sense. The latest v5.4R3 update changed the way VisualGDB is loaded into Visual Studio. Instead of loading at startup (slowing down the Visual Studio load time), it will only fully load once you use any of its menu commands, or open a VisualGDB-compatible project.
Most likely, the project in question is modified in a way that prevents the VisualGDB loader from recognizing it and hence fully loading the VisualGDB extension. If you could attach just the .vcxproj file (or send it to our support in case it’s confidential), we should be able to see why it is not recognized and update VisualGDB to handle it properly.
Strange. Just to be 100% sure, could you please attach a screenshot and show the exact setting that is not editable, so that we could recheck everything on our side?
We did actually use LOADADDR in our tests and the new generator – this is the proper documented way to get the load address of a section (i.e. the location of the section values stored in FLASH) and it worked reliably in several different configurations.
The Embedded Memory Explorer is a part of our pre-release integration tests, so most likely the issue is caused by corrupt settings of one specific project. Please try checking if the memory explorer works for a newly created “LEDBlink project” (don’t forget to build it first) and if it does – try comparing the settings of the 2 projects. Alternatively please try building/debugging the broken project or opening VisualGDB Project Properties for it – you will likely get a more specific error message if some of the settings are corrupt.
No worries, we have closed the ticket as a duplicate, linking it to this forum thread.
BTW, we use the same internal system for handling inquiries received via forum and via the support interface, hence there is need to create both a forum post and a support ticket – all we can do in this case is to link one inquiry to the other one. Simply use the communication method that is the most convenient for you and we will try to respond to your inquiry as soon as we can.
Good to know it works. Generally, we would not move commonly used commands like this to non-intuitive locations, so if anyone else encounters missing commands, please double-check that the VisualGDB extension is properly loaded into Visual Studio as shown in this page: http://visualgdb.com/support/loadfail/
According to our records, it looks like your trial period has expired. In order to get further technical support, please consider purchasing a license.
Please note that installing VisualGDB on another PC, editing registry to affect the trial counter, or creating further forum accounts does not reset your trial period from the support point of view.
As providing quality technical support for our users requires continuous effort on our side, we do expect our users to play fair and are not able to offer any help once the original trial period expires.
Thanks for the clarification. There is already an option for this under Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Suggest names while typing.
If the option is disabled, you can invoke the suggestion menu explicitly via Edit->IntelliSense->Complete Word command (Ctrl-Space) which is standard for all Visual Studio project types.
